I had made a nice setup of Dietpi on my Pi2 installed as a partition using Pinn.
Then my SD card crashed completely.
I got a new SD card and reinstalled DietPI using the newest img available on your website (the ARM7 img only works on my PI2). On my previous setup that crashed I used PINN for multibooting but now I chose your img because this PI will be 100% DietPI now.
Then I attached my backup drive and tried to restore. Before this it warns me:
DietPi-Backup [WARNING] UUIDs of the backup and the current system differ
The file systems unique identifiers, usually used to mount the drives at boot, seem to differ between the backup and the current system.
This usually indicates that you try to restore an old backup onto a newly flashed DietPi system.
But we were able to find the boot configuration, where those UUIDs would need to be adjusted, to assure that the system will boot.
It should be hence safe to restore this backup, but if the UUIDs were used elsewhere, you might need to adjust it manually.
Do you want to restore this backup?
Cancel
Ok
I choose OK. It restore all the way, and then in the end I get an error that it wasn’t succesful. I can then scroll throiugh the log. Ind the end it has sync errors: some files/attrs were not transferred.
When I reboot and it shuts down I can see many of the services I installed on my backup system are shutting as if it installed fine, but then when it reboots I see nothing. the PI SD light just lights red and there is no video output.
Anyone knows how I can fix this? The previous SD card is dead.
I had multiple backups and they all fail and warn before restoring in the same way so I assume it is the UUID issue due to using PINN before.
Since it is deleting dropbear service I do not think you have a ssh server installed or running. It would be nice to see the whole log. But anyway, it is usually pretty easy to install from fresh and start over which would eliminate the possibility of restoring a corrupt file.
Hi, it is not easy to reinstall. I have done a massive amount of setup. I took multiple backups with the assumption that I could trust them.
I have 4 backups and all of them return the exact same warnings and end result. I would understand if I only had one backup and that was corrupted, but they can’t all be corrupted. The backup disk is fine - I tested this as well.
B.t.w. in this thread I show some images of how PINN structures the disk in a previous PINN install. It looks like this restore has some issues with identification of something. I wonder how DietPI practically does it when restoring and how this is affected by the PINN disk partition setup being different than the standard setup.
I can’t setup PINN with the exact same structure and UUID as I had before because I didn’t capture a screenshot of that and I don’t have the details. This image is from an earlier install.
Here is an image - back then I had 5 system installed on Pinn. On my new broken one I had 3 - but the UUID are obviously different and I don’t know them now as the screen crashed:
About the log I shared the top and bottom of it below. And everything else in the log is just it copying files and in the end deleting some of the old ones as part of the rsync. And there are no errors during that.
I would like to upload the entire log, but how exactly can I get it out of the system after the restore? Which folder does it save the restore log in?
These are the files from after the restore:
/etc/fstab:
# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------
#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=486M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid
#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------
#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------
#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=c7d505a9-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=82da4f22-06 /boot vfat noatime,lazytime,rw 0 2
UUID=0fb252ea-9726-4c38-881e-57b4a3f579dd /mnt/store btrfs noatime,lazytime,rw,noauto,x-systemd.automount
This is my /boot/cmdline.txt: root=PARTUUID=c7d505a9-02 rootfstype=ext4 rootwait fsck.repair=yes net.ifnames=0 logo.nologo quiet console=ttyAMA0,115200 console=tty1
B.t.w. when I restored the backup from my external USB drive I mounted it as /mnt/storage (and not /mnt/store as I see in the fstab for the last physical drive).
When I restored I used the newest image from your website for Raspberry PI Arm 7.
For the backup the installation was set it up using PINN and the image was updated to bookworm as well - newest version (3 weeks ago I think).
Not sure what kernel versions reflect that?. I upgraded using this command bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.meta/dietpi-bookworm-upgrade')
There is no fixed connection between DietPi version and kernel version. Therefore, it is difficult to say.
Ok lets check following within the backup data. Be sure this to be checked on backup folder
cat /etc/fstab
Since kernel version 6.6 the vfat partition has a new mountpoint /boot/firmware. Previously it was only /boot.
My guess is that /boot is still set in /etc/fstab in the backup. This means that the backup cannot be restored to the new images with kernel 6.6 and higher. The only solution would then be to use an old image with kernel 6.1.
Thank you for the help! I fund out that I had to replace the boot files with the ones from my original install and check that the UUIDs match in /etc/fstab and cmdline.txt.
