My group currently utilizes Rescuezilla v.2.4.2 (Kinetic) on a CD/DVD and it usually works well. However lately we've had issues where after a boot disk is used several times we start witnessing an assortment of various issues. When using it to capture backups of several of the same type of computer, suddenly we are able to boot into the linux environment but are unable to open the Rescuezilla application. We've also seen it freeze with a variety of errors during the boot process and never make it to the Linux environment. Lately we've also received an error after a successful backup that states "failed to output checksum file info-img-id.txt" followed by a hash value and the name of the backup. It sometimes takes 4-5 different boot disks to capture 20 backups. We tried buying new DVDs to burn the Rescuezilla iso to (assuming a bad spindle of disks) but we've started having issues with the new disks as well. Has anything like this been reported in the past?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rescuezilla any reply to this? I see other posts since mine grtting attention but not this one. I want to make sure it isnt being overlooked as it is causing us all kinds of problems. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So the same computers that Rescuezilla v2.4.2 (Kinetic) used to work on reliably it now fails? No, I haven't seen an issue like this reported in the past.
Just to confirm, have you checksummed the ISO image that you're using to burn the DVD? On the Rescuezilla releases page there is a SHA256SUM checksum file to confirm the integrity of the ISO image. Also have you tried a different burner in addition to the different media spindle?
If yes to both, then I'd be hard pressed to see it being Rescuezilla related.
The fact that the checksum file that Rescuezilla writes out is failing now but not previously is also worrying.
In general this sounds like a hardware failure:
Bad storage cable (such as a loose or damaged SATA cables, or bad external USB drive or cable)
Failing or unreliable RAM (eg, loose RAM sticks)
But if any of the cases above (except the bad shared external USB drive), I'd expect it for maybe one computer, but not several computers that were previously working reliably.
If the issues you're seeing here was only happening on a new batch of computers (especially if they had newer, more modern hardware), then what you're seeing would likely be due to the use of an older Linux kernel not supporting newer hardware. But that doesn't sound like the case here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No worries, thanks for getting back to me. Essentially a Rescuezilla disk that worked fine on other computers doesn't function properly on others. But when we use a new boot disk (created from the same iso) it works fine. But then even that disk seems to stop working after several uses. It's almost like somehow the files on the boot disk are changing, but the disks are read only.
We haven't verified the checksum but plan to do so next week. All of this hardware is several years old (and all the same age). I agree this seems more likely to be hardware, but the issues have been very inconsistent.
I will reply with anything we find during our investigation. Let me know if you think of anything else. Thanks for your time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would definitely try the Rescuezilla Prerelease (2023-11-26) which default version is based on Ubuntu 23.10 (Mantic) rather than Ubuntu 22.10 (Kinetic). The release is stable and tested to the same level as a regular Rescuezilla release (I regret not releasing it as Rescuezilla v2.5). The extra 1 year of Linux kernel updates may improve stability on your hardware, despite it being old hardware. If so, that's a great data point to have!
If you think the optical media is somehow degrading (eg, I believe it's theoretically possible for a optical media drive to use its Blu Ray laser instead of the red DVD laser and possibly cause physical damage to the DVD), then there's a clear an obvious pathway to confirm this: checksum the Rescuezilla DVD itself periodically. You can do this from within Rescuezilla with a command such as sha256sum /dev/sr0 (the value is expected to be different from checksumming the ISO directly but will be consistent boot-to-boot).
Oh, one option I highly recommend experimenting with is booting Rescuezilla with the 'Load USB into RAM' menu option. This loads the entire contents of the DVD into RAM. This makes the RAM requirements are higher and it takes longer to boot, but the advantage is there is then no longer any dependency on the DVD itself: you can eject it if you'd like at that point.
Last edit: Rescuezilla 2024-02-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rescuezilla the hash of the iso we are using to burn the Rescuezilla disks does match the checksum on your downloads page. What's interesting is when we hashed all of the files on one of the Rescuezilla disks that we started having issues with we determined it is missing the following file path: \casper\filesystem.squashfs. We also noticed the hash is different on the following file path: \casper\initrd.lz. I'm not really sure how it's possible that the disk images are different considering we always use the same iso. What do these files do? Is it possible for the disks to work with them missing/altered?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The file \casper\filesystem.squashfs is the most fundemental file on a Rescuezilla live environment. It's an archive of the entire Rescuezilla Linux distribution filesystem. It's a big file, at 1.2GB. Just to be explicit, Rescuezilla definitely can't fit on a 700MB CD, only a DVD.
initrd.lz is another key file used in booting Rescuezilla.
I'd expect if either of these files are missing the DVD won't be able to boot.
By any chance, have you installed Rescuezilla on your systems on the hard drive as a rescue partition (https://github.com/rescuezilla/rescuezilla/wiki/Installing-Rescuezilla-as-a-rescue-partition) on any of the machines? If so, that could cause conflicts, especially if the Rescuezilla versions are different and/or with a damaged disk that's somehow missing files.
Also, I'm curious what tool are you using to burning the DVDs? It's simply writing the ISO file directly to disk, right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rescuezilla We have not installed Rescuezilla on any of these systems as a rescue partition. To create the DVDs we are simply using Windows to burn the disk image to the disk, no third party tools are being used. We are starting to wonder if this is strictly damage to the disks from poor disk drives, which would explain the inconsistency of the issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rescuezilla when I select the option to 'Load USB into RAM' while using v.2.4.2 (Kinetic) Rescuezilla loads and starts, but when I select "Restore" it sits on the "Step 1: Select Image Location" screen with the progress window stating "Identifying disk drives... Running: blkid". Do you have any idea why this would be?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
blkid is one of the commands Rescuezilla uses to scan the disks. It's possible this command is hanging internally for some reason. Less likely but still possible is this command ran and exited promptly but produced output that Rescuezilla was not able to process.
It's easy to double-check, since under-the-hood Rescuezilla is (like Clonezilla) running simply blkid, without any extra arguments and analyzing the output. I recommend closing Rescuezilla, then opening a Terminal from the desktop and running blkid. Does it give output and complete promptly?
Note: while booted with the ''Load USB into RAM' option, feel free to eject the Rescuezilla boot media.
After confirming blkid directly in a terminal, I recommend running Rescuezillla from the Terminal by typing /usr/sbin/rescuezilla. This will allow you to see the under-the-hood logging information that will either show blkid hanging somewhere due to your hardware, or perhaps an unhandled error message that may displayed in the Terminal but due to a bug may not yet be correctly detected and displayed as an error in the frontend.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also @jwade0984, have you tried my suggestion from above around using the most recent Rescuezilla Prerelease version? Because there's a significant chance your issues will be improved with the more recent Linux kernel and hardware drivers available in the Ubuntu 23.10 (Mantic) release than Rescuezilla v2.4.2 based on Ubuntu 22.10 (Kinetic).
Rescuezilla Prerelease (2023-11-26) which default version is based on Ubuntu 23.10 (Mantic) rather than Ubuntu 22.10 (Kinetic). The release is stable and tested to the same level as a regular Rescuezilla release (I regret not releasing it as Rescuezilla v2.5). The extra 1 year of Linux kernel updates may improve stability on your hardware, despite it being old hardware. If so, that's a great data point to have!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rescuezilla thanks. I'll try the troubleshooting steps for Kinetic that you suggested. I did just try the prerelease version and it seems to work better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rescuezilla attached is the output from running your steps above. It appears blkid is identifying the drives but not displaying them. There is no error message that I see but clearly the command is hanging.
From your log file, I see lsblk (a different application that Rescuezilla also uses) is working fine, but yes, it looks like blkid itself is hanging. If you can reproduce this issue in a terminal running blkid without Rescuezilla running then it's 100% an issue with that program and should probably be reported to the authors of that tool over at util-linux.
The output that blkid generates is not actually that useful for Rescuezilla's operation. On my end I will take a look at making Rescuezilla a bit more resilient to blkid failing to scan drives. Eg, by adding a timeout or an optional cancel option, and then being able to proceed with the normal Rescuezilla flow.
Remotely debugging blkid hanging (for me or the blkid authors) will probably unfortunately not be that easy. I'm not asking you to do this (and you can ignore the rest of this paragraph), but if I was debugging I'd probably first run strace blkid to get an idea of the internal Linux system call that occurs before it starts hanging (it's probably failing to process some specific piece of metadata on a specific one of your drives). But Rescuezilla doesn't have the strace debugging tool installed, so I'd first have to run apt-get update && apt-get install strace. If I still couldn't diagnose it with the output of strace, I'd potentially download the source code and compile a new version of blkid and either use a debugger or other means to identify the exact cause of the hang. Then ideally fix it and push a fix to the developers of blkid.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2025-04-28
I also am having problems with BLKID it ran all night again and then I'm in Rescuezilla and the only way out is to hold the power button down. The removable drives I have used all work with other PCs. The Rescuezilla USBs I tried also work on other PCs. I have tried everything on quite a long list and everything I have done gets up stuck on BLKID. I ran some commands in terminal that I was given & I read "access denied? Please help me. Everything was working until this BLKID thing started.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My group currently utilizes Rescuezilla v.2.4.2 (Kinetic) on a CD/DVD and it usually works well. However lately we've had issues where after a boot disk is used several times we start witnessing an assortment of various issues. When using it to capture backups of several of the same type of computer, suddenly we are able to boot into the linux environment but are unable to open the Rescuezilla application. We've also seen it freeze with a variety of errors during the boot process and never make it to the Linux environment. Lately we've also received an error after a successful backup that states "failed to output checksum file info-img-id.txt" followed by a hash value and the name of the backup. It sometimes takes 4-5 different boot disks to capture 20 backups. We tried buying new DVDs to burn the Rescuezilla iso to (assuming a bad spindle of disks) but we've started having issues with the new disks as well. Has anything like this been reported in the past?
@rescuezilla any reply to this? I see other posts since mine grtting attention but not this one. I want to make sure it isnt being overlooked as it is causing us all kinds of problems. Thanks.
Oops sorry for the lack of rapid reply.
So the same computers that Rescuezilla v2.4.2 (Kinetic) used to work on reliably it now fails? No, I haven't seen an issue like this reported in the past.
Just to confirm, have you checksummed the ISO image that you're using to burn the DVD? On the Rescuezilla releases page there is a SHA256SUM checksum file to confirm the integrity of the ISO image. Also have you tried a different burner in addition to the different media spindle?
If yes to both, then I'd be hard pressed to see it being Rescuezilla related.
The fact that the checksum file that Rescuezilla writes out is failing now but not previously is also worrying.
In general this sounds like a hardware failure:
But if any of the cases above (except the bad shared external USB drive), I'd expect it for maybe one computer, but not several computers that were previously working reliably.
If the issues you're seeing here was only happening on a new batch of computers (especially if they had newer, more modern hardware), then what you're seeing would likely be due to the use of an older Linux kernel not supporting newer hardware. But that doesn't sound like the case here.
No worries, thanks for getting back to me. Essentially a Rescuezilla disk that worked fine on other computers doesn't function properly on others. But when we use a new boot disk (created from the same iso) it works fine. But then even that disk seems to stop working after several uses. It's almost like somehow the files on the boot disk are changing, but the disks are read only.
We haven't verified the checksum but plan to do so next week. All of this hardware is several years old (and all the same age). I agree this seems more likely to be hardware, but the issues have been very inconsistent.
I will reply with anything we find during our investigation. Let me know if you think of anything else. Thanks for your time.
I would definitely try the Rescuezilla Prerelease (2023-11-26) which default version is based on Ubuntu 23.10 (Mantic) rather than Ubuntu 22.10 (Kinetic). The release is stable and tested to the same level as a regular Rescuezilla release (I regret not releasing it as Rescuezilla v2.5). The extra 1 year of Linux kernel updates may improve stability on your hardware, despite it being old hardware. If so, that's a great data point to have!
If you think the optical media is somehow degrading (eg, I believe it's theoretically possible for a optical media drive to use its Blu Ray laser instead of the red DVD laser and possibly cause physical damage to the DVD), then there's a clear an obvious pathway to confirm this: checksum the Rescuezilla DVD itself periodically. You can do this from within Rescuezilla with a command such as
sha256sum /dev/sr0(the value is expected to be different from checksumming the ISO directly but will be consistent boot-to-boot).Oh, one option I highly recommend experimenting with is booting Rescuezilla with the 'Load USB into RAM' menu option. This loads the entire contents of the DVD into RAM. This makes the RAM requirements are higher and it takes longer to boot, but the advantage is there is then no longer any dependency on the DVD itself: you can eject it if you'd like at that point.
Last edit: Rescuezilla 2024-02-19
Thanks for all the great tips. I'll give them a try. Really appreciate the product and the support.
@rescuezilla the hash of the iso we are using to burn the Rescuezilla disks does match the checksum on your downloads page. What's interesting is when we hashed all of the files on one of the Rescuezilla disks that we started having issues with we determined it is missing the following file path: \casper\filesystem.squashfs. We also noticed the hash is different on the following file path: \casper\initrd.lz. I'm not really sure how it's possible that the disk images are different considering we always use the same iso. What do these files do? Is it possible for the disks to work with them missing/altered?
Great that the hash matches.
The file
\casper\filesystem.squashfsis the most fundemental file on a Rescuezilla live environment. It's an archive of the entire Rescuezilla Linux distribution filesystem. It's a big file, at 1.2GB. Just to be explicit, Rescuezilla definitely can't fit on a 700MB CD, only a DVD.initrd.lzis another key file used in booting Rescuezilla.I'd expect if either of these files are missing the DVD won't be able to boot.
By any chance, have you installed Rescuezilla on your systems on the hard drive as a rescue partition (https://github.com/rescuezilla/rescuezilla/wiki/Installing-Rescuezilla-as-a-rescue-partition) on any of the machines? If so, that could cause conflicts, especially if the Rescuezilla versions are different and/or with a damaged disk that's somehow missing files.
Also, I'm curious what tool are you using to burning the DVDs? It's simply writing the ISO file directly to disk, right?
@rescuezilla We have not installed Rescuezilla on any of these systems as a rescue partition. To create the DVDs we are simply using Windows to burn the disk image to the disk, no third party tools are being used. We are starting to wonder if this is strictly damage to the disks from poor disk drives, which would explain the inconsistency of the issue.
@jwade0984 For sure. It's worth trying an external USB DVD drive, certainly.
@rescuezilla when I select the option to 'Load USB into RAM' while using v.2.4.2 (Kinetic) Rescuezilla loads and starts, but when I select "Restore" it sits on the "Step 1: Select Image Location" screen with the progress window stating "Identifying disk drives... Running: blkid". Do you have any idea why this would be?
blkidis one of the commands Rescuezilla uses to scan the disks. It's possible this command is hanging internally for some reason. Less likely but still possible is this command ran and exited promptly but produced output that Rescuezilla was not able to process.It's easy to double-check, since under-the-hood Rescuezilla is (like Clonezilla) running simply
blkid, without any extra arguments and analyzing the output. I recommend closing Rescuezilla, then opening a Terminal from the desktop and runningblkid. Does it give output and complete promptly?Note: while booted with the ''Load USB into RAM' option, feel free to eject the Rescuezilla boot media.
After confirming
blkiddirectly in a terminal, I recommend running Rescuezillla from the Terminal by typing/usr/sbin/rescuezilla. This will allow you to see the under-the-hood logging information that will either showblkidhanging somewhere due to your hardware, or perhaps an unhandled error message that may displayed in the Terminal but due to a bug may not yet be correctly detected and displayed as an error in the frontend.Also @jwade0984, have you tried my suggestion from above around using the most recent Rescuezilla Prerelease version? Because there's a significant chance your issues will be improved with the more recent Linux kernel and hardware drivers available in the Ubuntu 23.10 (Mantic) release than Rescuezilla v2.4.2 based on Ubuntu 22.10 (Kinetic).
@rescuezilla thanks. I'll try the troubleshooting steps for Kinetic that you suggested. I did just try the prerelease version and it seems to work better.
@rescuezilla attached is the output from running your steps above. It appears blkid is identifying the drives but not displaying them. There is no error message that I see but clearly the command is hanging.
Last edit: Joshua Wade 2024-02-29
From your log file, I see
lsblk(a different application that Rescuezilla also uses) is working fine, but yes, it looks likeblkiditself is hanging. If you can reproduce this issue in a terminal runningblkidwithout Rescuezilla running then it's 100% an issue with that program and should probably be reported to the authors of that tool over at util-linux.The output that
blkidgenerates is not actually that useful for Rescuezilla's operation. On my end I will take a look at making Rescuezilla a bit more resilient toblkidfailing to scan drives. Eg, by adding a timeout or an optional cancel option, and then being able to proceed with the normal Rescuezilla flow.Remotely debugging
blkidhanging (for me or theblkidauthors) will probably unfortunately not be that easy. I'm not asking you to do this (and you can ignore the rest of this paragraph), but if I was debugging I'd probably first runstrace blkidto get an idea of the internal Linux system call that occurs before it starts hanging (it's probably failing to process some specific piece of metadata on a specific one of your drives). But Rescuezilla doesn't have thestracedebugging tool installed, so I'd first have to runapt-get update && apt-get install strace. If I still couldn't diagnose it with the output ofstrace, I'd potentially download the source code and compile a new version ofblkidand either use a debugger or other means to identify the exact cause of the hang. Then ideally fix it and push a fix to the developers ofblkid.I also am having problems with BLKID it ran all night again and then I'm in Rescuezilla and the only way out is to hold the power button down. The removable drives I have used all work with other PCs. The Rescuezilla USBs I tried also work on other PCs. I have tried everything on quite a long list and everything I have done gets up stuck on BLKID. I ran some commands in terminal that I was given & I read "access denied? Please help me. Everything was working until this BLKID thing started.