All my fedora backups fail to restore to the destination drive and also fail to restore properly to a spare SSD. none of the fedora backups and there's the least 8 Boots after restoration it just goes to grub rescue.
Any suggestions?? I took PC to repair shop and they said there's no issues with the drive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please upload the file clonezilla-img either here, or email it to rescuezilla@gmail.com.
If your backup image is able to verify, and restores successfully, then most likely your disk require manual incantation with the command-line to ensure that GRUB correctly points to the intended filesystem.
I will create a new backup image and try some tests.
I will be investing a very large amount of in Rescuezilla over the several few weeks to fix any bugs in the application, and also relatedly provide user support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's unlikely to be the source disk, but it always could be.
The resizing sdd2 issues is unlikely to be fatal, typically just means a manual step. umount failed could be a cause depending on where it occurs. Superblock error is definitely more likely to be an issue.
By the way, Rescuezilla images are compatible with Clonezilla, so can close Rescuezilla, open a terminal and type clonezilla and use the terminal user-interface to restore select your image and restore your disk using an alternative tool. It may behave differently (though the tool is much more difficult to use than Rescuezilla).
If you suspect the source disk, you can copy the image files to an alternative disk and try to restore again.
Please upload or email the clonezilla-img log file and I'll take a look.
Do you have the exact version of Fedora using on-hand? I'd like to make my own installation and do some experiments. I'm curious if it's a BTRFS filesystem because I've been seeing a few reports of issues with that recently, and it's had some active development within the partclone imaging tool that both Rescuezilla and Clonezilla use.. Also the clonezilla-img log file will give me some indiciations if your installation uses an "LVM" partition layout.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, I forgot to explicitly note. I looked through the clonezilla-img log file that Rescuezilla generates and the backup process reported no issues, as Rescuezilla's UI reported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed an Ultramarine Flagship 41 environment using ultramarine-flagship-41-live-anaconda-x86_64.iso into a VirtualBox 7.1 environment.
I was able to back it up using rescuezilla-2.6-64bit.oracular, then I zeroed the disk (purely for testing purposes), then I restored the image and it successfully booted.
The restore had the expected resizing/umount message associated with BTRFS (screenshot attached, sorry for the small font)
Just to add, I successfully restored my same Ultramarine Flagship 41 image (created using default settings) using latest stable Clonezilla too (clonezilla-live-3.2.2-5-amd64.iso). I'd expect same behavior with the Clonezilla version available from within Rescuezilla live environment, and I have already successfully tested the Rescuezilla frontend in comment above.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The next steps would be:
1. Confirming your restored BTRFS filesystem is accessible after restore
2. Fixing GRUB to point to the BTRFS filesystem so it boots correctly
Opening your drive using GParted, and also closing Rescuezilla and GParted and confirming it's navigatable from within Rescuezilla's file manager is what I would suggest.
If the BTRFS root filesystem is not accessible after a restore that would be a deeper problem. Hopefully there is an image you can restore that has it accessible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The DestinatIon drive is badNeeds replacing according to bios smart. would that affect any backups? if there were bad sectors and bad fIle system errors would rescuezilla back up out as well this
Last edit: Chris Deacon 2025-06-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes,
* Bad sectors on the original source disk would definitely impact things
* Bad sectors on the drive that stores backup images may also impact things.
* Bad sectors on the destination drive that you restore to could also impact things
Try restoring your best image to a disk that is known to be healthy, and optionally use the 'Rescue' option when restoring. 'Rescue' mode skips some important checks for consistency, but for backup and restore.
As mentioned, the next steps is to try and access the BTRFS root filesystem after restoring (which you already have) from Rescuezilla live manager (GParted and File Manager). and ensure the filesystem appears healthy with all the files are there.
Once that's confirmed, I'd expect it's a single command-line incantations away from GRUB understanding where the BTRFS root filesystem is
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Everything is being restored to /root Folder rather than the root of the drive. Is that the problem?
Like usr opt var etc and So on
This is to be expected: on my working Ultramarine Flagship 41 installation, I observe the same thing (screenshots attached).
This is great news, as it appears to indicate your drive was successfully restored and files are intact just fine most likely. Just some mismatch with the GRUB boot configuration.
Tomorrow (ie, 24 hours from this message), I will try and reproduce this exact error message in my VM and figure out how exact steps on how to solve it.
From what I can tell, an update-grub or similar GRUB install or update should automatically resolve it, based on the fact that your other root partition (and boot partition) are apparently fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All my fedora backups fail to restore to the destination drive and also fail to restore properly to a spare SSD. none of the fedora backups and there's the least 8 Boots after restoration it just goes to grub rescue.
Any suggestions?? I took PC to repair shop and they said there's no issues with the drive.
Which version of Fedora are you using?
Please upload the file
clonezilla-imgeither here, or email it torescuezilla@gmail.com.If your backup image is able to verify, and restores successfully, then most likely your disk require manual incantation with the command-line to ensure that GRUB correctly points to the intended filesystem.
I will create a new backup image and try some tests.
I will be investing a very large amount of in Rescuezilla over the several few weeks to fix any bugs in the application, and also relatedly provide user support.
The backup image(s) verify and the restoring process itself is reported to be successful, right?
No, restoration either says it can't resize sdd2 or umount failed. Or gives a superblock error.
Could the actual backup drive with the images be the issue?
Since it's happened restoring to two drives?
It's unlikely to be the source disk, but it always could be.
The resizing
sdd2issues is unlikely to be fatal, typically just means a manual step.umountfailed could be a cause depending on where it occurs. Superblock error is definitely more likely to be an issue.By the way, Rescuezilla images are compatible with Clonezilla, so can close Rescuezilla, open a terminal and type
clonezillaand use the terminal user-interface to restore select your image and restore your disk using an alternative tool. It may behave differently (though the tool is much more difficult to use than Rescuezilla).If you suspect the source disk, you can copy the image files to an alternative disk and try to restore again.
Please upload or email the
clonezilla-imglog file and I'll take a look.Do you have the exact version of Fedora using on-hand? I'd like to make my own installation and do some experiments. I'm curious if it's a BTRFS filesystem because I've been seeing a few reports of issues with that recently, and it's had some active development within the
partcloneimaging tool that both Rescuezilla and Clonezilla use.. Also theclonezilla-imglog file will give me some indiciations if your installation uses an "LVM" partition layout.Ultramarine Linux (Fedora 41 Based) . It was using btrfs.
Last edit: Chris Deacon 2025-06-03
attached last working system backup. I've tested 2 images using clonezilla. Says /ssd2 image is corrupt. Partclone.log shows no abnormalities
Last edit: Chris Deacon 2025-06-03
Oh, I forgot to explicitly note. I looked through the
clonezilla-imglog file that Rescuezilla generates and the backup process reported no issues, as Rescuezilla's UI reported.I registered in case you were wondering why no longer showing as anonymous
Last edit: Chris Deacon 2025-06-03
I installed an Ultramarine Flagship 41 environment using
ultramarine-flagship-41-live-anaconda-x86_64.isointo a VirtualBox 7.1 environment.I was able to back it up using
rescuezilla-2.6-64bit.oracular, then I zeroed the disk (purely for testing purposes), then I restored the image and it successfully booted.The restore had the expected resizing/umount message associated with BTRFS (screenshot attached, sorry for the small font)
Last edit: Rescuezilla 2025-06-04
Just to add, I successfully restored my same Ultramarine Flagship 41 image (created using default settings) using latest stable Clonezilla too (
clonezilla-live-3.2.2-5-amd64.iso). I'd expect same behavior with the Clonezilla version available from within Rescuezilla live environment, and I have already successfully tested the Rescuezilla frontend in comment above.The next steps would be:
1. Confirming your restored BTRFS filesystem is accessible after restore
2. Fixing GRUB to point to the BTRFS filesystem so it boots correctly
Opening your drive using GParted, and also closing Rescuezilla and GParted and confirming it's navigatable from within Rescuezilla's file manager is what I would suggest.
If the BTRFS root filesystem is not accessible after a restore that would be a deeper problem. Hopefully there is an image you can restore that has it accessible.
The DestinatIon drive is badNeeds replacing according to bios smart. would that affect any backups? if there were bad sectors and bad fIle system errors would rescuezilla back up out as well this
Last edit: Chris Deacon 2025-06-04
Yes,
* Bad sectors on the original source disk would definitely impact things
* Bad sectors on the drive that stores backup images may also impact things.
* Bad sectors on the destination drive that you restore to could also impact things
Try restoring your best image to a disk that is known to be healthy, and optionally use the 'Rescue' option when restoring. 'Rescue' mode skips some important checks for consistency, but for backup and restore.
As mentioned, the next steps is to try and access the BTRFS root filesystem after restoring (which you already have) from Rescuezilla live manager (GParted and File Manager). and ensure the filesystem appears healthy with all the files are there.
Once that's confirmed, I'd expect it's a single command-line incantations away from GRUB understanding where the BTRFS root filesystem is
Everything is being restored to /root Folder rather than the root of the drive. Is that the problem?
Like usr opt var etc and So on
Last edit: Chris Deacon 2025-06-05
This is to be expected: on my working Ultramarine Flagship 41 installation, I observe the same thing (screenshots attached).
This is great news, as it appears to indicate your drive was successfully restored and files are intact just fine most likely. Just some mismatch with the GRUB boot configuration.
Last edit: Rescuezilla 2025-06-06
I get grub error attempt to read or write outside of disk hd0
Entering grub rescue
Thanks for the error message.
Tomorrow (ie, 24 hours from this message), I will try and reproduce this exact error message in my VM and figure out how exact steps on how to solve it.
From what I can tell, an
update-grubor similar GRUB install or update should automatically resolve it, based on the fact that your other root partition (and boot partition) are apparently fine.sudo grub2-mkconfig -o /etc/grub2.cfg
sudo grub2-mkconfig -o /etc/grub2-efi.cfg
In Fedora?
Ok, I get unknown commands for the lines above
Last edit: Chris Deacon 2025-06-06