bedna

I'm not sure what armbian-config does exactly, but from what I read on a quick search about your hardware and booting from usb it seems OdroidC4 demands you having the inital boot sequence kick off from the sd-card and no way of getting around it. This guide seems to cover it without you needing to use armbian-config, because again, I don't know, but I suspect it moves everything, incl boot to your usb-device, and that won't work on your hardware.

My gut feeling was using systemd to run the script, that way root, or in this case systemd issues the commands. If it is to be run at startup just enable the service and specify `After` and `required` options. Not sure how you call the script, but you can probably play around it. https://www.freedesktop.org/software/systemd/man/systemd.service.html Bonus is you get access to journalctl that logs what is going on, extremely useful when debugging.

Good news everyone! Yesterday a new kernel update (5.15.93-sunxi64 > Linux 6.1.42-sunxi64) was pushed to my armbian on an opiPC2 and u-boot was triggered. Made tests by updating my old image instead of creating a new, then trying to boot from that image with GREAT success! I did not look deeper into what the u-boot actually did, but this time it worked at least.

Oh, My bad, I though your question "How to make a sd card bootable?" was the issue. Great that you solved that! If other people find this thread, can you explain how you solved that? Yes, I removed it because the whole sentence did not make sense to me. It seemed you misunderstood what you quoted. I even gave you an example of how I restored to sda from a backup from mmcblk0 and that that worked. What I have learned I HAVE to do to make a backup that I can restore and boot from is that I HAVE to do EXACTLY what you describe above. Not only that, I need to first resize both the backup file AND the partition on that backup, THEN resize the filesystem before backing up to it. But I am here to learn, if I do not need to do that and can somehow remove 500 lines of code in my script, I would LOVE to do that. So again, how do you restore your backups so they become bootable? A backup is NOT A BACKUP until you have restored from it Edit. I'm starting to believe this is an xy problem/question. You are looking for confirmation rather than the actual answer to your question. https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem I have a LOT of knowledge in these things, but always open to learn if I am ill informed. Edit 2 I just realized, in OP you mentions grub, that demands a second partition. If you back up a system with boot mounted on either /boot or /boot/efi, how do you backup (rsync) those so those gets restored tp a different partition?

That is exactly what the script does. Just with an extra bonus of you being able to write the img to a device and that filesystem will boot, and autoexpand if it's supported (witch armbian is). The FIRST img created obv is of the whole system, but subsequent updates on that img files ONLY rsyncs the changed files. If you only want to access the files, just mount the img file with a loop. I urge you to read the description. Edit Thought I comment on this as well: That is not true, as long as the img fits it can be written to any device. I even tried it with the script. I backed up a raspberry pi os from mmcblk0, wrote that img file to a usb that became sda and booted up from it. Worked like a charm. But that should work on any img (as long as its created with the same UUID), the os is looking for the uuid, not the device, devices can switch places between boots so they are NEVER reliable to expect to be the same.

If I may be so frank, I very recently made a post on this forum that would solve this for you. Might I offer you my piece of software to manage your backups?

A few changes introduced a bug that made armbian detect 2 partitions instead of one so If you have cloned it since op was made, you have to re clone it, the bug is now fixed. Sorry about that.

shrink-backup is a bash script for backing up your SBC:s into an img file Version 1.2 Info updated: 20 Oct, 2024. shrink-backup I made this script because I wanted a universal method of backing up my SBC:s into img files as fast as possible (with rsync), no matter what os is in use. Supports backing up root & boot (if existing) partitions. Data from other partitions will be written to root if not excluded (exception for btrfs, all existing subvolumes in /etc/fstab will be created). Please see Info section. Autoexpansion tested on Raspberry Pi os (bookworm and older), Armbian, Manjaro-arm, DietPi and ArchLinuxARM for rpi with ext4 or f2fs root partition. (Now also experimental btrfs functionality, please read further down) Full support for usage inside webmin (including "custom command" button). Latest release: shrink-backup.v1.2 Testing branch if you want to have the absolute latest version. There might be bugs. Very fast restore thanks to minimal size of img file. Can back up any device as long as root is ext4 or f2fs (experimental btrfs) Default device that will be backed up is determined by scanning what disk-device root resides on. This means that if boot is a partition, that partition must be on the same device and before the root partition. Backing up/restoring, to/from: usb-stick /dev/sdX with Raspberry pi os has been tested and works. Ie, writing an sd-card img to a usb-stick and vice versa works. Ultra-fast incremental backups to existing img files. See wiki for information about installation methods, usage and examples. Ideas and feedback is always appreciated, whether it's positive or negative. Please just keep it civil. If you find a bug or think something is missing in the script, please file a Bug report or Feature request Don't forget to ensure the script is executable. To restore a backup, simply "burn" the img file to a device using your favorite method. When booting up a restored image with autoresize active, wait until the the reboot sequence has occured. The login prompt may very well become visible before the autoresize function has rebooted. Usage: shrink-backup -h Script for creating an .img file and subsequently keeing it updated (-U), autoexpansion is enabled by default Directory where .img file is created is automatically excluded in backup ######################################################################## Usage: sudo shrink-backup [-Uatyelhz] [--fix] [--loop] [--f2fs] imagefile.img [extra space (MiB)] -U Update existing img file (rsync to existing img) Optional [extra space] extends img size of root partition -a Autoresize root partition (extra space is ignored) When used in combination with -U: Expand if partition is >=256MiB smaller than resize2fs recommended minimum Shrink if partition is >=512MiB bigger than resize2fs recommended minimum -t Use exclude.txt in same folder as script to set excluded directories One directory per line: "/dir" or "/dir/*" to only exclude contents -y Disable prompts in script (please use this option with care!) -e DO NOT expand filesystem when image is booted -l Write debug messages to logfile shrink-backup.log located in same directory as script -z Make script zoom at light-speed, only question prompts might slow it down Can be combined with -y for UNSAFE ultra mega superduper speed --fix Try to fix the img file if -a fails with a "broken pipe" error --loop [img] Loop img file and exit, works in combination with -l & -z If optional [extra space] is defined, the img file will be extended with the amount before looping NOTE that only the file gets truncated, no partitions Useful if you for example want to manually manage the partitions --f2fs Convert root filesystem on img from ext4 to f2fs Only works on new img file, not in combination with -U Will make backups of fstab & cmdline.txt to: fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak Then change ext4 to f2fs in both files and add discard to options on root partition in fstab --version Print version and exit -h --help Show this help snippet ######################################################################## Examples: sudo shrink-backup -a /path/to/backup.img (create img, resize2fs calcualtes size) sudo shrink-backup -e -y /path/to/backup.img 1024 (create img, ignore prompts, do not autoexpand, add 1024MiB extra space) sudo shrink-backup -Utl /path/to/backup.img (update img backup, use exclude.txt and write log to shrink-backup.log) sudo shrink-backup -U /path/to/backup.img 1024 (update img backup, expand img size/root partition with 1024MiB) sudo shrink-backup -Ua /path/to/backup.img (update img backup, resize2fs calculates and resizes img file if needed) sudo shrink-backup -Ua --fix /path/to/backup.img 1024 (update img backup, automatically resizes img file if needed, fix img free space) sudo shrink-backup -l --loop /path/to/backup.img 1024 (write to log file, expand IMG FILE (not partition) by 1024MiB and loop) -t (exclude.txt) The folder where the img file is created will ALWAYS be excluded in the backup. If -t option is selected, exclude.txt MUST exist (but can be empty) within the directory where the script is located or the script will exit with an error. Use one directory per line in exclude.txt. /directory/* = create directory but exclude content. /directory = exclude the directory completely. If -t is NOT selected the following folders will be excluded: /lost+found /proc/* /sys/* /dev/* /tmp/* /run/* /mnt/* /media/* /var/swap Please see info section further down. -l (Log file) Use -l to write debug info into shrink-backup.log file in the same directory as the script. -z (Zoom speed) The -z "zoom" option simply removes the one second sleep at each prompt to give the user time to read. By using the option, you save 15-25s when running the script. When used in combination with -y warnings will also be bypassed! PLEASE use with care! --fix (Broken pipe) Add --fix to your options if a backup fails during rsync with a "broken pipe" error. You can also manually add [extra space] instead of using -a to solve this. Example: sudo shrink-backup -Ua --fix /path/to/backup.img The reason it happens is because rsync normally deletes files during the backup, not creating a file-list > removing files from img before starting to copy. So if you have removed and added new data on the system you backup from, there is a risk rsync tries to copy the new data before deleting data from the img, hence completely filling the img. Using --fix makes rsync create a file-list and delete data before starting to transfer new data. This also means the backup takes a little longer. Having a "broken pipe" error during backup has in my experience never broken an img backup after either using --fix (can be used in combination with -a) or adding [extra space] while updating the backup with -U. --loop (Loop img file) Use --loop to loop an img file to your /dev. Example: sudo shrink-backup --loop /path/to/backup.img If used in combination with [extra space] the amount in MiB will be added to the IMG FILE NOT any partition. With this you can run for example run: sudo gparted /dev/loop0 (if you have a graphical interface) to manually manage the img partitions in a graphical interface with gparted. If you added [extra space] this will then show up as unpartitioned space at the end of the device where you can create partition(s) and manually copy data to by mounting the new loop partition that will become visible in lsblk. If you do this, don't forget to create or update the img with -e (disable autoexpansion) first. Autoexpansion will not work since the space will be occupied by your manually managed partition. Example: sudo shrink-backup --loop /path/to/backup.img 1024 This functionality works on any linux system, just use the script on any img file anywhere available to the computer. To remove the loop: sudo losetup -d /dev/loop0, change loop0 to the correct dev it got looped to. To remind yourself: lsblk /dev/loop* (if you forgot the location after using --mount) --f2fs (Convert ext4 into f2fs on img file) ONLY use this for CONVERTING filesystem into img file, if you already have f2fs on your root, do not use this option. The script will detect what filesystem is used on root and act accordingly. Only supported with new backups, not when using -U. Autoexpansion at boot is not supported for f2fs (there is no way of resizing a mounted f2fs filesystem, unlike with ext4) so resizing root partition have to be made manually after writing img to sd-card. Resize operations (when updating backup with -U) is not available for f2fs as of now. The script will make backups of fstab & cmdline.txt into fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak on the img. It will then change from ext4 to f2fs in fstab & cmdline.txt and add discard to the options on the root partition in fstab. Please read information about f2fs further down. Info Rsync WILL cross filesystem boundries, so make sure you exclude external drives unless you want them included in the backup. (separate /home for example) The script will ONLY create boot (if exits) and root partitions on the img file. The script will ONLY look at your root partition when calculating sizes. Not excluding other partitions will copy the data to the img root partition, not create more partitions so make sure to manually add [extra space] if you do this. Experimental btrfs is an exception to this, all subvolumes will be created. Applications used in the script: fdisk sfdisk dd parted e2fsck truncate mkfs.ext4 rsync gdisk (sgdisk is needed if the partition table is GPT, the script will inform you) ######################################################################## Image creation To create a backup img using recomended size, use the -a option and the path to the img file. Example: sudo shrink-backup -a /path/to/backup.img Theoretically the script should work on any device as long as root filesystem is ext4, f2fs or experimental btrfs. Since the script uses lsblk to crosscheck with /etc/fstab to figure out where the root resides it does not matter what device it is on. Even if you forget to disable autoexpansion on a non supported system, the backup will not fail. Order of operations - image creation Reads the block sizes of the partitions Uses dd to create the boot part of the system + a few megabytes to include the filesystem on root (this can be a partition) Removes and recreates the root partition, size depends on options used when starting the script Creates a new ext4 filesystem with the same UUID and LABEL as the system you are backing up from Uses rsync to sync both partitions (if more than one) Uses lsblk & /etc/fstab to figure out the correct disk device to back up. Reads the block sizes of the system's root (and boot if it exists) partition. Uses dd to create the boot part of the system + a few megabytes to include the filesystem on root. (this can be a partition) Uses df & resize2fs to calculate sizes by analyzing the system's root partition. (For btrfs: btrfs filesystem du + 192MiB is used instead of resize2fs) Uses truncate to resize img file. Loops the img file. Removes and recreates the root partition on the loop of the img file. Creates the root filesystem on loop of the img file with the same UUID and LABEL as the system you are backing up from. Creates a temp directory and mounts img file root partition from loop. Checks if boot partition exists, if true, checks fstab and creates directory on root and mounts accordingly from loop. Uses rsync to sync filesystems. Tries to create autoresize scripts if not disabled with -e. Unmounts and removes temp directory and file (file created for rsync log output). Added space is added on top of df reported “used space”, not the size of the partition. Added space is in MiB, so if you want to add 1GB, add 1024. The script can be instructed to set the img size by requesting recommended minimum size from e2fsck by using the -a option. This is not the absolute smallest size you can achieve bit is the “safest” way to create a “smallest possible” img file. If you do not increase the size of the filesystem you are backing up too much, you can most likely keep it updated with the update function (-U) of the script. By using -a in combination with -U the script will resize the img file if needed (not supported on f2fs). Using combination -Ua on an img that has become overfilled works, if not add --fix and retry. Please see --fix and image update sections for more information. Smallest possible image To get the absolute smallest img file possible, do NOT set -a option and set “extra space” to 0 Example: sudo shrink-backup /path/to/backup.img 0 This will instruct the script to get the used space from df and adding 128MB “wiggle room”. If you are like me, doing a lot of testing, rewriting the sd-card multiple times. The extra time it takes each time will add up pretty fast. Example: -rw-r--r-- 1 root root 3.7G Jul 22 21:27 test.img # file created with -a -rw-r--r-- 1 root root 3.3G Jul 22 22:37 test0.img # file created with 0 Disclaimer: Because of how filesystems work, df is never a true representation of what will actually fit on a created img file. Each file, no matter the size, will take up one block of the filesystem, so if you have a LOT of very small files (running docker f.ex) the “0 added space method” might fail during rsync. Increase the 0 a little bit and retry. This also means you have VERY little free space on the img file after creation. If the filesystem you back up from increases in size, an update (-U) of the img file might fail. By using -a in combination with -U the script will resize the img file if needed (not supported on f2fs). Using combination -Ua on an img that has become overfilled works, if not add --fix and retry. Please see --fix and Image update sections for more information. ######################################################################## Image update To update an existing img file simply use the -U option and the path to the img file. Example: sudo shrink-backup -U /path/to/backup.img Order or operations - image update Loops the img file. Probes the loop of the img file for information about partitions. If -a is selected, calculates sizes by comparing root sizes on system and img file by using fdisk & resize2fs. Expands filesystem on img file if needed or if manually added [extra space] is used. Creates temp directory and mounts root partition from loop. Checks if boot partition exists, if true, checks fstab and creates directory on root and mounts accordingly from loop. Uses rsync to sync filesystems. Shrinks filesystem on img file if -a was used and conditions were met in point 3. Tries to create autoresize scripts if not disabled with -e. Unmounts and removes temp directory and file (file created for rsync log output). Resizing img file when updating If -a is used in combination with -U, the script will compare the root partition on the img file to the size resize2fs recommends as minimum (or du calculations depending on filesystem). The img file root partition needs to be >=256MB smaller than resize2fs recommended minimum to be expanded. The img file root partition needs to be >=512MB bigger than resize2fs recommended minimum to be shrunk. This is to protect from unessesary resizing operations most likely not needed. If manually added [extra space] is used in combination with -U, the img file's root partition will be expanded by that amount. No checks are being performed to make sure the data you want to back up will actually fit. Only expansion is possible with this method. ######################################################################## f2fs The script will detect f2fs on root automatically and act accordingly. Do NOT USE --f2fs unless you are converting from a ext4 filesystem (on your system) into f2fs on the img file. Autoexpansion at boot is not possible with f2fs. User will have to manually expand img to cover entire storage media (f.ex sd-card) when restoring. Resizing of img root partition while updating img (-U) is not possible with f2fs as of now. User will have to create a new backup if img runs out of space. This is something I am planning to implement further down the line. btrfs ALL testing has been done on Manjaro-arm THIS IS NOT A CLONE, IT IS A BACKUP OF REQUIRED FILES FOR A BOOTABLE BTRFS SYSTEM! All options in the script should work just as on ext4. The script will detect btrfs and act accordingly. The script will treat snapshots as nested volumes, so make sure to exclude snapshots if you have any, or directories and nested volumes will be created on the img file. This can be done in exclude.txt, wildcards should work. When starting the script, the initial report window will tell you what volumes will be created. Make sure these are correct before pressing Y. As of now, top level subvolumes are checked for in /etc/fstab and mounted accordingly, mount options should be preseved (if you for example changed compression). Autoresize function works on Manjaro-arm. ---------------------------------------------------------------------------------------------------------------------------------------------------------- Thank you for using my software ❤️ A backup is not really a backup until you have restored from it.

Before I do something that breaks forum rules I'd rather ask. Can I post a link to githyb with a script I made to backup sbc:s (incl Armbian ofc)? The reason it even exists is because of when I first started using armbian and wanted something I could backup both rpi os and armbian. Can I post it here or is it prefered to keep it in the "anything" thread? Regards.

I am creating a script that can backup sd-cards running on the system, resizing it with desired value or via resize2fs calculated. I learn a lot but there are a few things I don't fully understand. When I create a backup I dd what I understand is the bootsector, ie I grab the "start" position of the partition I am backing up with fidisk and use that value and a blocksize of 512. I then add another 10mb (in bytes) just to be sure. Usually the bootsector is 8192 big, but not always (IIRC nanopi neo3;s is WAY bigger). dd bs=512 count=$DDBOOTSECTOR if=/dev/mmcblk0 of=$IMG_FILE conv=noerror,sync status=progress I then truncate the file, calculated either by resize2fs minimum calculation or via an input + file usage in df (depending of what flag I start the script with) + bootsector + yadayadayda. (if someone want me to post the script I will, but the script and calculations work, although I "force" some commands) I then loop the created img file and delete the partition on the /dev/loop0 and recreates it to cover 100%. Then format it with mkfs.ext4 copying the name and uuid from wherever I backup from. I mount the loop and rsync / rsync -ahvD --exclude={/lost+found,/proc/*,/sys/*,/dev/*,/tmp,/run/*,/mnt/*,/media/*,/var/log.hdd,/var/swap,/etc/udev/rules.d/70-persistent-net.rules,/var/lib/asterisk/astdb.sqlite3-journal} --info=progress2 --stats --delete --force --partial / $tmp_dir This seems to work, but there are probably some things that are just "accepted" not really "perfect". So questions: 1. Should I only dd the EXACT bootsector and not add the extra 10mb? The reason I ask is because if I try to delete the partition with parted, I have to do a hack in the scrip where I simulate button presses, it warns me that "the partition cant be outside of the disk" when I try to REMOVE it. Solution, I use sfdisk to remove the partition, but it prompts me to think there is something wrong going on here. If the size I create is ABOVE the resize2fs reported minimum i don't get this warning. sfdisk was the solution in this case, but still curious on this behavior. If I try to only dd the small part, it sometimes works, sometimes doesn't so I come here asking. (I might be able to do some further research but since I have other questions, why not ask) 2. Does armbian ever update the u-boot via apt? I do my next update with rscync by looping the file and mounting it. But that wont EVER cover the bootsector. 2b. If yes, do I solve this by again dd:ing ONLY the bootsector? 3. I have noticed that sudo apt update on armbian includes armhf even though running arm64. This makes the update process VERY long. dpkg --print-foreign-architectures shows armhf so i remove it with dpkg --remove-architecture armhf and then find /var/lib/apt/lists/ -type f -exec rm {} -v \; Seems to fix this but is this a bad idea? Why is the armhf even being fetched to begin with? To my memory I have not added arhmf architecture... Thanks in advance!

I think the reason it didn't work with my first tries I suspect is because I: 1. tried to mount the whole disk, not the partition. 2. Did not probe the "disk". This is the solution I found to best working for me. Backing up and mounting image: Use gnu version of ddrescue (you can back up mounted system drive with it) $ sudo apt install gddrescue -y $ sudo ddrescue -f -n /dev/mmcblk0 /path/to/backup.img GNU ddrescue 1.23 Press Ctrl-C to interrupt ipos: 15634 MB, non-trimmed: 0 B, current rate: 14352 kB/s opos: 15634 MB, non-scraped: 0 B, average rate: 19066 kB/s non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s rescued: 15634 MB, bad areas: 0, run time: 13m 39s pct rescued: 100.00%, read errors: 0, remaining time: n/a time since last successful read: n/a Finished Find out where the boot sector/partition ends/starts, ie: start(32768) x blocksize(512) = offset(16777216), and mount it (make sure you have directories to mount to, in this case sudo mkdir /mnt/loop) You can also divide the offset by 8 to make sure it's in the right position, should end up with a whole number, in this case 16777216/8=2 097 152. This tells me, even though the bootsector seems to be way bigger than needed, it probably will work. $ sudo fdisk -l /mnt/backup/nanoPiNeo3/piHole/backup.img Disk /path/to/backup.img: 14.56 GiB, 15634268160 bytes, 30535680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xb90578af Device Boot Start End Sectors Size Id Type /path/to/backup.img1 32768 30212096 30179329 14.4G 83 Linux Mount the img with a loop $ sudo mount -o loop,offset=16777216 /path/to/backup.img /mnt/loop $ ls /mnt/loop -l total 84 -rw-r--r-- 1 root root 3128 Oct 22 18:11 armbian.key lrwxrwxrwx 1 root root 7 Oct 22 08:41 bin -> usr/bin drwxr-xr-x 3 root root 4096 Nov 1 23:50 boot drwxr-xr-x 2 root root 4096 Oct 22 18:11 dev drwxr-xr-x 103 root root 4096 Nov 4 19:19 etc drwxr-xr-x 3 root root 4096 Nov 1 16:34 home lrwxrwxrwx 1 root root 7 Oct 22 08:41 lib -> usr/lib drwx------ 2 root root 16384 Oct 22 18:19 lost+found drwxr-xr-x 2 root root 4096 Oct 22 08:41 media drwxr-xr-x 5 root root 4096 Nov 4 19:19 mnt drwxr-xr-x 3 root root 4096 Nov 1 17:26 opt drwxr-xr-x 2 root root 4096 Oct 22 08:41 proc drwx------ 5 root root 4096 Nov 4 19:18 root drwxr-xr-x 3 root root 4096 Oct 22 18:21 run lrwxrwxrwx 1 root root 8 Oct 22 08:41 sbin -> usr/sbin drwxrwxr-x 2 root root 4096 Oct 22 18:11 selinux drwxr-xr-x 2 root root 4096 Oct 22 08:41 srv drwxr-xr-x 2 root root 4096 Sep 3 14:10 sys drwxrwxrwt 2 root root 4096 Oct 22 18:11 tmp drwxr-xr-x 11 root root 4096 Oct 22 08:41 usr drwxr-xr-x 13 root root 4096 Nov 1 17:23 var Now you can rsync your whole disk to keep files up to date. First create a file with paths to exclude, ie so you don't create a loop and backs the directory you are backing up to, I simply created exclude.txt in my home directory. nano ~/exclude.txt Content of my exclude.txt #directories to exclude when backing up with rsync /proc/* /sys/* /dev/* /tmp/* /run/* /mnt/* /media/* rsync to the mounted drive to update backup sudo rsync -ahv --info=progress2 --stats --delete --force --partial exclude-from=/home/$USER/exclude.txt --delete-excluded / /mnt/loop/ umount /mnt/loop so we can shrink the img file sudo umount /mnt/loop Shrinking the img file Change to superuser (sudo su) so you don't have to type sudo before each line and run following commands. I will use parted. $ sudo su $ modprobe loop $ losetup -f $ losetup /dev/loop0 /path/to/backup.img $ partprobe /dev/loop0 Check how much space is actually used, since it's a copy of my system I can just df that $ df -h /dev/mmcblk0p1 Filesystem Size Used Avail Use% Mounted on /dev/mmcblk0p1 15G 1.7G 13G 12% / Lets make the drive 2500MB, just to be a bit safer and leave space for future rscync backups in case they size increases of what you want to back up $ e2fsck -f /dev/loop0p1 e2fsck 1.46.2 (28-Feb-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information armbi_root: 49784/916864 files (0.1% non-contiguous), 502310/3772416 blocks $ resize2fs /dev/loop0p1 2500M resize2fs 1.46.2 (28-Feb-2021) resize2fs: New size smaller than minimum (659029) Nope, it didn't like that, lets try with 2600M $ resize2fs /dev/loop0p1 2600M resize2fs 1.46.2 (28-Feb-2021) Resizing the filesystem on /dev/loop0p1 to 665600 (4k) blocks. The filesystem on /dev/loop0p1 is now 665600 (4k) blocks long. Nice, it worked. Then recheck it e2fsck -f /dev/loop0p1 e2fsck 1.46.2 (28-Feb-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information armbi_root: 49784/165984 files (0.2% non-contiguous), 454731/665600 blocks Looking good. Now lets shrink the partition using parted. Since I'm not sure how to get all units in the same way I'd rather make the partition a little bigger than the filesystem and then expand the filesystem it up to the partition size, ie lets make it 2700MB. If someone could clarify this part I would be very happy $parted /dev/loop0 GNU Parted 3.4 Using /dev/loop0 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Loopback device (loopback) Disk /dev/loop0: 15.6GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 16.8MB 15.5GB 15.5GB primary ext4 (parted) resizepart 1 End? [15.5GB]? 2700MB Warning: Shrinking a partition can cause data loss, are you sure you want to continue? Yes/No? y (parted) quit Information: You may need to update /etc/fstab. Then lets resize the filesystem with resize2fs $ resize2fs /dev/loop0p1 resize2fs 1.46.2 (28-Feb-2021) Resizing the filesystem on /dev/loop0p1 to 655083 (4k) blocks. The filesystem on /dev/loop0p1 is now 655083 (4k) blocks long. And one last check before shrinking the img file $ e2fsck -f /dev/loop0p1 e2fsck 1.46.2 (28-Feb-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information armbi_root: 49784/158080 files (0.2% non-contiguous), 454235/655083 blocks Looking good. Now let's see how much we can shave off the file, we are looking for the end sector (5273437) and sector size (512), we use fdisk $ fdisk -l /dev/loop0 Disk /dev/loop0: 14.56 GiB, 15634268160 bytes, 30535680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x83f3ee4c Device Boot Start End Sectors Size Id Type /dev/loop0p1 32768 5273437 5240670 2.5G 83 Linux The calculation goes: end sector+1 and then multiply that number with the sector size (512), that gives us 5273438 x 512 = 2 700 000 256bytes, about 2,7GB We use truncate to trim the file $ truncate --size=$[(5273437+1)*512] /path/to/backup.img Lets mount the img file again and see if we can access the files $ mount /dev/loop0p1 /mnt/loop $ ls /mnt/loop -l total 84 -rw-r--r-- 1 root root 3128 Oct 22 18:11 armbian.key lrwxrwxrwx 1 root root 7 Oct 22 08:41 bin -> usr/bin drwxr-xr-x 3 root root 4096 Nov 1 23:50 boot drwxr-xr-x 2 root root 4096 Nov 1 23:50 dev drwxr-xr-x 103 root root 4096 Nov 4 19:19 etc drwxr-xr-x 3 root root 4096 Nov 1 16:34 home lrwxrwxrwx 1 root root 7 Oct 22 08:41 lib -> usr/lib drwx------ 2 root root 16384 Oct 22 18:19 lost+found drwxr-xr-x 2 root root 4096 Oct 22 08:41 media drwxr-xr-x 2 root root 4096 Nov 4 19:19 mnt drwxr-xr-x 3 root root 4096 Nov 1 17:26 opt dr-xr-xr-x 2 root root 4096 Jan 21 2016 proc drwx------ 5 root root 4096 Nov 4 19:18 root drwxr-xr-x 2 root root 4096 Nov 4 19:28 run lrwxrwxrwx 1 root root 8 Oct 22 08:41 sbin -> usr/sbin drwxrwxr-x 2 root root 4096 Oct 22 18:11 selinux drwxr-xr-x 2 root root 4096 Oct 22 08:41 srv dr-xr-xr-x 2 root root 4096 Jan 21 2016 sys drwxrwxrwt 2 root root 4096 Nov 4 20:09 tmp drwxr-xr-x 11 root root 4096 Oct 22 08:41 usr drwxr-xr-x 13 root root 4096 Nov 1 17:23 var We can also see that the file is WAY smaller than the 15GB file we started out with. $ df -h /mnt/loop/ Filesystem Size Used Avail Use% Mounted on /dev/loop0p1 2.5G 1.7G 740M 70% /mnt/loop If you want to, you can once again rsync into the img file to back up your system. Just make sure that you don't install massive amounts so the file gets filled, the file will not get bigger by itself. You have to redo these steps here but START with increasing in parted THEN resize it with e2fsck. Finally let's umount and remove the loop $ umount /mnt/loop $ losetup -d /dev/loop0 Don't forget to exit SU by simply typing $ exit You can now flash this img file to an sdcard using win32DiskImager, etcher or whatever your fav prog is. If you want it to expand the partition after you have flashed it to a new card, simply boot up with new card in board, enable armbian-resize-filesystem.service then reboot and disable it again. Your sd card will be max size. $ sudo systemctrl enable armbian-resize-filesystem.service $ sudo reboot now $ sudo systemctrl disable armbian-resize-filesystem.service If someone knows if it's possible to put a file on the sdcard that tells it to autoexpand on boot I would love to know about it. That would remove the whole reboot process when expanding the card. Hope this wall of text can help someone else.

Hi! Have limited knowledge in linux, all self learned so bear with me if I sometimes sound like an i**ot in my wording. I have used lots of different Raspberry pi's but since they are near to impossible to get your hands on I figured I'd try out some of the alternate boards. Got myself a nanoPiNeo2, orangePiZero2 and an orangePiPC2 just for the fun of it. I have tried this on the nanoPi and the opiZero2 and run into the same problems, havent even opened the opiPC2 yet but I suspect it will be the same problem on that board. Downloaded armbian for each separate board (instead of debian) because I want to use the same system on all my devices so its easier for me to learn. Got everything working as I wanted (just making a simple pihole to give away as xmas presents) but when it came to backing up, I ran into a wall. With the raspberries I use a script called image-backup located on the raspberrypi forums (awesome script made by RonR) but that obv wont work here since the rpi uses a fat32 as a boot partition. There is a flag you can run when using the script called "ubuntu", but it didn't work. Ok then, lets use win32 imager instead to just rip the card, its only 8gb, not a huge deal, I can probably even shrink the size with e2fsck and parted (as I understand it armbian autoexpands the card on mount anyway?) but I get an i/o error in win32 after a few seconds, this might actually be my computer, going to try it on another computer in a day or two, (I only have one). I tried other programs too, but none seems to work so I decided to try to dd from the mounted card. The backup directory is on a mounted cif on a windows computer if that has to do with anything? sudo dd if=/dev/mmcblk0 of=/path/to/backup/ddbackup.img bs=4M conv=sync status=progress That didn't work, I get (the numbers are bigger I just randomly took a number, the important thing is the +1 that gets added to the "normal" number in "records out", I suspect that is the boot sector?) 15874+1 records in 15875+0 records out I figured it had to do with the card being mounted so I made ANOTHER identical install on another sdcard and inserted the original sd in the usb with a card reader and doing the dd from /dev/sda instead (without it being mounted), but I get the exact same thing and when trying to flash the image and use that card, the board just never comes to life. Network port keeps flashing but nothing else. My plan was to make a backup.img file, mount that with a loop and shrink the "partition" with shrink2fs and parted. But even trying to mount the created image files gives me errors about bad superblocks etc, probably because of what I described above. Running e2fsck also gives me a TON of errors. I have tried for DAYS, searching all over the internet (figuring things out for myself is the best way to learn) but I get nowhere. Is there a simple solution to this? The only time I actually got a working .img file is if I dd a blank img file first from /dev/zero and set the file to become a size (with bs and count) where all data can fit and then rsync / into it. I can mount it with a loop (losetup) and access the files, but naturally it wont boot on the board (if I flash it to an sd card) since I read that the boot sector is "out of bonds" or whatever its called. Same error, just flashing network port. I'm at a complete loss here, I REALLY want to have an img file that the xmas gift holders get that they can just flash onto an sdcard in case of a breakdown of the software somehow. Please have pity on my soul!