-
-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DietPi-Backup | Add Option to Automatically Restore on First Boot #4112
Conversation
Awesome! I think we can add this to v7.0 already. |
will this work already if I do fresh installation and use this branch as target? |
Yes, since the update is performed first 🙂. |
Let's also unmount the auto-mounted drives and remove the mount points:
|
Testing procedure on an existing system:
|
Dammit that we log to |
probably a good idea to check what happen. but I can try to catch it. 🤔 |
ok I login during initial setup trying to catch what happen. Right after restore finished, some commands are missing
attached the log file. Really strange. It goes to delete entire modules and firmware 😭 |
That is very strange. Did you try it with a different backup/normal DietPi-Backup? |
I got it, it's two issues. First is the merge of /bin /lib etc. with /usr/bin /usr/lib etc. Background on this:
I just verified that the new RPi images contain this merged directories as well, which is quite new, AFAIK. For new Debian images is was the case for years already, but for RPi I see it the first time (doesn't mean something 😄). So this is what I guess happens:
The second more problematic thing: One can only restore a backup to a new image where UUIDs and PARTUUIDs do still match, as otherwise fstab and boot configs contain invalid entries. To allow more, we'd need to either manually change fstab and boot configs (including grub update etc), or, probably easier, change the UUIDs/PARTUUIDs of the current root drive partitions to match the ones from the restored backup: https://www.tecmint.com/change-uuid-of-partition-in-linux/ But now there can be F2FS, GPT partition tables etc where things become more complicated 🤔. It looks like it can only be safely used when the original image/archive that was once flashed is kept... But not practically when it's very old. It becomes quite complicated but we could loop through the drives partitions UUIDs and PARTUUIDs, check whether one of the two is present in the backups fstab (if it matches, assume that the other one does as well), otherwise check the partition table type and file system type to know whether we can adjust it, and if not print that to the user to deal with it manually. Auto-adjusting fstab and boot config is probably less save since we cannot know where else those IDs are used. Ah another practical issue: Where do we get the old IDs from? fstab contains UUIDs but usually not PARTUUIDs. For the latter we again need to check and scrape boot configs. Arrg sadly this will never work failsafe... |
uhh probably you are on the right track @MichaIng basically I have a master backup on my USB stick that I use to restore/reset the same RPi again and again. This backup will be updated time by time. Usually after larger apt package updates, to avoid long apt installations in front of a software install. Means, the initial backup was create some month ago and refreshed last time on the 12th of Feb. A restore on the current Just for reference, backup status log attached. |
I think this is something that needs to be added to dietpi-backup restore code directly, as a pre-check before restoring the backup, since users might also manually restore the backup on a new image. But I'm not sure how to effectively deal with it:
|
Okay guys, I'll port the few unrelated little fixes and enhancements to the dev branch now but won't merge this feature into the first beta. We need to handle drive ID issue first. Should be possible to have it until next week for 2nd or 3rd beta. |
Coincidence: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563746 |
+ DietPi-Backup | Do not stop services before we definitely run the backup or restore. The rsync process check still needs to be done after stopping the services, which include the rsync daemon. But do not kill a running rsync process afterwards, better error out. + DietPi-Backup | Implement a first function when restoring a backup, to check whether the backup's UUIDs match the current drive's UUIDs, so that we do not restore a system that is not booting, because the bootloader and fstab do not find the configured drives. If the UUIDs seem to not match, check whether we are able to reliably make the system bootable by adjusting known bootloader configurations. Add function to restore UUIDs, in case, but content is on ToDo for now :).
+ DietPi-Backup | Restore now obsolete functions + DietPi-Backup | Satisfy shellcheck + DietPi-Backup | Add whiptail yes/no dialogues when storing a backup to a system with different UUIDs. Default to "yes", if we did find the boot configuration method, else default to "no", which is especially relevant for non-interactive first run setups with AUTO_SETUP_BACKUP_RESTORE=1 set.
Ready for testing. |
Ok will run some test on weekends |
Tested with all boot configs, and works fine now. I'll merge it to dev branch, so it can be tested together with other recent changes. |
Status: Ready
Reference: #4066
Commit list/description: