Can not mount Rescuezilla image on an external disk.

[Anonymous]

Hello Community. I made an image with Rescuezilla of a partition of an external disk on Linux Mint, and now I can´t mount it. I formatted it on NTFS, as it was originally. The space of the disk is 0.5 Terabyte and the image weights 200 Gb. I attach the error messages after trying to mount it.

[Rescuezilla]

The key line of the error message in this restore operation is "Failed to add #3 partition: No space left on device".

Is your destination device too small to restore your image to?

Or is it the same disk that you created a backup from?

A 500GB disk that leads to a (compressed) 200GB image with Rescuezilla is normal if your disk contained around 200GB of used space when you created the backup image.

[Anonymous]

Thanks for the answer!! It's the same disk. Firstly, I made the backup with no problems, saving the image on another external device. Then I verified it with Rescuezilla. Suddenly, the disk turned to be unreadable. The free space of the disk is 300 Gb, so there would be enough space to mount it. Maybe, I don´t know if formatting the disk in EXT4, should solve the question, but won´t be accesible for Windows file system. It is a back up of Easy To Boot Software, that works on both Operating Systems originally on NTFS. My doubt is if it depends on the type of format, or the the problem is around other cause. I tested the disk on Linux Mint, using Disk utility, and the result gave no troubles.

[Rescuezilla]

The operation you did was to restore the image back to original disk, and after a successful restore you can definitely mount the partition using the file manager. Using Rescuezilla's default settings during a restore the free space on the target disk doesn't matter, and the formatting of the filesystem on the destination disk also doesn't matter.

Because Rescuezilla's restore operation has default settings where it "overwrite the partition table" (which acts to format the disk in the same way as the source disk), followed by restoring all filesystems.

During a restore operation, Rescuezilla allows configuring to restoring filesystems without overwriting the partition table (the UI here is not as streamlined, but it is possible).

So the source image was contained "Easy2Boot"? I'm not familiar with that tool, but since that's a bootable environment it's possible that your source disk contained a partition table that's was inconsistent to begin with: it's possible (perhaps even likely) it refers to regions of your destination disk that were beyond the end of the disk.

It's possible the fdisk partition table tool is complaining about this. Please upload the sda-pt.sf text file and I can take a look to try and confirm. Please also upload the clonezilla-img log file. Alternatively send to rescuezilla at gmail and I can take a look there.

Side note: The easiest solution may be to try restoring to a larger destination disk.

[Anonymous]

It's very probable that the bottleneck is the partition table. I formatted again the disk with Disks and repeated the procedure to mount the image. At the last step, overwritting the partition table, if I don´t choose that option, I can´t continue to restore it.

How Do I upload the sda-pt.sf text file? Don´t the images I attached before contain the log file? If they don´t, would you show me how to?

The previous procedure to begin with Rescuezilla, formatting and then creating a new volume are right? Maybe, I'm skipping one or more steps, before mounting it.

[Rescuezilla]

If you untick 'overwriting partition table' Rescuezilla still allows you to restore your image, but you need to 'manually' map the partitions. For each row you will need to click the right-most column (which becomes a drop-down menu) and allows you to provide a specific destination partition for each filesystem image.

The user-interface in this advanced mode is not that clear/obvious, but it will allow you to skip the problematic partition table restore step and restore the filesystem images manually.

The sda-pt.sf (note: it could be sdb or sdc too) and the clonezilla-img files are in your backup folder. You can upload them by clicking 'Add attachments' on Sourceforce, though you probably need to create a Sourceforge account for that. Alternatively email the files to rescuezilla at gmail as mentioned above.

The images you posted above only contain the error message log for the restore. The clonezilla-img contains the entire backup log and information for all operations, and some hardware information about partition tables etc. This will allow me to confirm why the fdisk partitioning tool (that Rescuezilla uses in the same way as Clonezilla -- which millions of people use) is failing to restore on your system. The suspicion I'd like to investigate is your specific disk may have had some inconsistent partition table information because it was created with a downloaded bootable OS image, which may have assumptions of a larger disk etc that weren't repaired eg, by GParted or booting your OS, which causes the fdisk tool to be able to happy to backup your specific drive but unhappy to restore it, which is a terrible failure mode.

The previous procedure to begin with Rescuezilla, formatting and then creating a new volume are right?

In 99.9% of cases you won't need to ever manually format a disk with GParted before making a restore with Rescuezilla because the 'Overwrite partition table' checkbox is itself a quick-format.

But as mentioned above, in your case here, there appears to be an issue with your partition table backup. I recommend after the failed restore, looking at the partition table in GParted and hopefully fixing the final partition by creating a new empty one. (It's expected that they'll all show 'unknown' filesystem at that point since the filesystems aren't yet restored). Then after open Rescuezilla and use the manual partition mapping flow descibed above (with Overwrite partition table unticked). You should be able to restore all the partitions. Be extra careful the mapping of source image to destination are correct though!

[Anonymous]

Thank you very much for the answer!! I send the file in order to be analized.

EDIT by Rescuezilla: Deleted the clonezilla-img log file attachment after successful analysis below, since the user posted using an Anonymous account so can't delete it themselves and the key snippets are below.

[Rescuezilla]

I can see exactly what has went wrong. Thanks for the clonezilla-img log file!

So here's what your 2023-09-02-2211-img-rescuezilla- E2B/sdd-pt.sf contains is:

label: dos
label-id: 0x63276e3e
device: /dev/sdd
unit: sectors
sector-size: 512

/dev/sdd1 : start=        2048, size=   419837952, type=7, bootable
/dev/sdd2 : start=   419840000, size=   556929024, type=7
/dev/sdd4 : start=   281624584, size=     2348052, type=0

I mostly manually converted the above into the following (converting 512 byte sectors numbers into megabytes and confirming the partition type ID number)

/dev/sdd1 :start=1049kB  end=215GB size=215GB type=HPFS/NTFS/exFAT
/dev/sdd2 :start=215GB   end=500GB size=285GB type=HPFS/NTFS/exFAT
/dev/sdd4 :start=134GB   end=135GB size=1GB   type=None

As you can see, your sfdisk partition table is inconsistent: it contains this weird phantom 1 gigabyte /dev/sdd4 partition that for some reason resides within your first partition at position 135GB. This strange/uniquely partition entry is what is causing your restore to fail. Side note: I expect GParted may hide this inconsistency its display because I can see from the log file the parted application doesn't show it.

One workaround is to open your sdd-pt.sf file in a text editor (ideally on Linux) and remove the final /dev/sdd4 line. Then the sfdisk application that Rescuezilla uses during a clone/restore won't fail.

I'll investigate raising a bug ticket with the authors of sfdisk / util-linux and investigate adding a warning or workaround to Rescuezilla itself.

Though one thing I'm not sure about: from the logs it appears you only made a backup of the /dev/sdd1 partition. I can't tell from the logs: was this correct/intended? You choose not to backup /dev/sdd2, right?

[Anonymous]

I made the disk on Windows 11 environment. I created 2 partitions, one for E2B (Easy to Boot, it's a software used for booting ISO files, such as WinPe, Windows installations, HirensBoot. Any Iso file can be bootable with E2B. It's an additional comment about what that software does. It's a very simple way to install programs, operating systems, virus scaning, backupping and more.
The second partition contained software under Windows.
Suddenly, the whole disk begun as raw. I don't know what really happened.

Restoring the image under Windows, it worked well. I'm experimenting this problem under Linux Mint.

I just chosed to backup E2B partition only. The other partion was lost when the disk become unreadable.

Thank you for your time. I'll try to erase:

/dev/sdd4 :start=134GB end=135GB size=1GB type=None

to see if the problem persists.

[Anonymous]

I mean: The other partion was lost when the disk became unreadable.

[Anonymous]

I shoutted: ¡¡¡¡Eureka!!!!! The image could be mounted following your advice. I erased that line of thata file, and Easy To Boot works properly. You saved me dozens of hours rebuilding the disk.
Thank you very, very much!!!!!

[Ramiro Hernán González]

I registered on Sourceforge.net
How Do I associate the help link to my account?
Thanks again.

[Rescuezilla]

Hi Ramiro,

Thanks for creating a Sourceforge account. The benefits are getting email notifications when somebody responds to the thread, and being able to delete/edit your old posts and attachments.

Your previous anonymously posts will stay anonymous and won't be associated, or editable. For extra privacy, I've deleted the clonezilla-img log file that you uploaded (since you can't). There's never anything particularly sensitive in that file, just pretty standard Linux device information.

As for the problem, I'm gvery happy that deleting that weird phantom partition from the partition table file worked for you.

I don't think it was Rescuezilla that introduced this phantom partition. It was likely introduced by another partitioning tool that you used I think, possibly involving the Easy2Boot's install image. But clearly it's Rescuezilla's problem that a user was able to successfully create a backup of a disk that contains such a phantom/inconsistent partition table (and successfully verify their image), but during the restore step they receive such a confusing error message.

As mentioned, I'll followup with the creators of the sfdisk the partitioning tool Rescuezilla uses. But I will try and reproduce a disk with a similar inconsistent partition table. The problem that impacted your disk will very likely impact the case using Clonezilla too, as that program does backup and restore in almost the exact same way as Rescuezilla.

Even if there is such a phantom partition edge-case in let's say 1 in every 5000 disks (after a series of manual partitioning steps), that's obviously a problem that Rescuezilla needs to more elegantly handle.

Sorry for the long post, no actions required on your part. I'm glad we've got to the bottom of this weird issue!

Please let me know if you have any further issues -- I'm always happy to help, especially when it discovers strange edge-cases that likely impact Clonezilla too!