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.

Updated to version 1.3. Please see Shrink-backup github for full information. Release notes: New options: -q|--quiet mode. Mute rsync output --no-color mode. No colorization in script --rsync. User will get presented with the rsync line that will be ran and can modify it --chroot option to access an image in a chroot environment (systemd-nspawn) to for example update/install packages or rebuild initramfs. Only works from the system you created the img Autoexpansion for operating systems: Kali-arm Ubuntu-server-arm (Ubuntu autoexpands by default, but that can be disabled with -e option) UI tweaks Removed check for .img extension while using --loop so it works on other img formats (for example .iso) Changed the dd line to use conv=fsync instead of sync and added a sync operation after dd is done to try to mitigate the "can not set loop paths" problem that some users experience User confirmation now require to also press enter after y/n Added /snap/* in exclude.txt and to be excluded as default if not using the exclude file Implemented a lock file that makes it impossible for boot partition to become unmounted during shrink-backup Nested btrfs subvolumes can now be added & removed in an update (-U) New way of excluding subvolumes for btrfs (exclude_btrfs.txt or shrink-backup_btrfs.conf depending on how you installed, see README for information) --fix now also adds option --fsync to rsync If you have made changes to exclude.txt and you used git to install, git pull will fail due to conflicts. The easiest way to resolve this is to make notes of the paths you added, then: git reset --hard git pull Then add your edited paths back into exclude.txt at the end of the file again. -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Short description: shrink-backup is a bash script for backing up your SBC:s into an img file Version 1.3 Info updated: 2 Aug, 2025. 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. shrink-backup is a very fast utility for backing up your SBC:s into minimal bootable img files for easy restore with autoexpansion at boot. Can backup any device with or without a boot partition as long as the filesystem is ext4, f2fs or btrfs (with subvolumes). Supports backing up root & boot (if existing) partitions. Data from other partitions will be written to root if not excluded. For btrfs, all existing top level 5 subvolumes in /etc/fstab will be created with new backups, nested subvolumes will be created and can also be removed/added in an update of the backup img. Please read Info section for more information. Autoexpansion tested & supported on following operating systems: - Raspberry Pi OS (bookworm and older) - Armbian - Manjaro-arm - DietPi - ArchLinux-arm - Kali-arm - Ubuntu-server-arm (Ubuntu autoexpands by default, but that can be disabled with -e option) Autoexpansion does not work on f2fs due to filesystem limitations. Other operating systems will most likely work too, but autoexpansion will not. The script will report the operating system as "unknown" but that does not mean the script will fail. Feel free to make a feature request if you use an operating system not on this list. Full functionality for usage inside webmin (including "custom command" button). Latest release: shrink-backup.v1.3 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. 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. The script considers everything on the device before root as the bootsector. 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 To restore a backup, simply "burn" the img file to a device using your favorite method. When booting a restored image with autoresize active, on some operating systems a reboot will occur after resizing is made (you will be informed at the end of the script if your operating system is affected by this), please wait until the the reboot sequence has occurred. 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 Disable autoexpansion of root 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 -q --quiet Do not print rsync copy process --no-color Run script without color formatted text --fix Try to fix the img file if -a fails with a "broken pipe" error Will activate rsync options --delete-before & --fsync --rsync Define custom rsync line manually. Will print rsync line for user to edit --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 --chroot Use systemd-nspawn. Loop img file, mount to temp directory, enter chroot environment and drop to shell This will let you make changes in a chroot environment directly on the img file For example update with package manager or rebuild initramfs The script will keep running in the background --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) Thank you for using shrink-backup ❤️❤️ 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!