Restoredisk when "target disk does not exist" is encountered does not work
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
I have been using clonezilla-live-3.0.2-21-amd64 with UEFI boot, and I am trying to restore an image to a disk. I have pre-seeded several options in the grub.cfg file, and I have noticed that the restore process works exactly as I desire IF the target disk is dev/sdd. This is because the image I have originally came from a disk called dev/sdd. However, if when I plug in another disk, and Debian recognizes it as some other name, such as dev/sdc or dev/sde, then the restore image does not seem to work; however, no error message is shown.
I am running the following custom-made menu option in the grub.cfg file to obtain the image using a samba server:
menuentry "Custom" --id live-custom {
search --set -f /live/vmlinuz
$linux_cmd /live/vmlinuz boot=live union=overlay username=user config components quiet loglevel=0 noswap edd=on nomodeset enforcing=0 noeject locales=en_US.UTF-8 keyboard-layouts=NONE ocs_prerun1="dhclient -v eth1" ocs_prerun2="sleep 2" ocs_prerun3="mount -t cifs -o user=<username>,password=<password> //<server>/<path>/images /home/partimag" ocs_prerun4="sleep 2" ocs_live_run="/usr/sbin/ocs-sr -g auto -e1 auto -e2 -r -j1 -j2 -ps -c -k0 -scr -p choose restoredisk <image_name> ask_user" ocs_live_extra_param="" ocs_live_batch="no" vga=788 ip= net.ifnames=0 nosplash i915.blacklist=yes radeonhd.blacklist=yes nouveau.blacklist=yes vmwgfx.enable_fbdev=1
$initrd_cmd /live/initrd.img
}</image_name></path></server></password></username>
However, I get the same behavior if I just run the default Clonezilla start option and choose all the options manually through the GUI, so I don't think the odd behavior is unique to my pre-seeded options. If Debian thinks my target disk is called sde, for example, it will tell me "Target disk sde does not exist in the image saved from disk(s) 'sdd.'" And then it will tell me it is creating a tmp Clonezilla image that is converted so it can be restored to sde. All the other steps seem to complete as normal except one. If the process goes correctly (sdd -> sdd), then I see a blue screen background with a gray box titled "restore partition from image file" with some information about the partition, size, time, etc. and a red progress bar at the bottom. However, if it has to do the tmp converted image (e.g. sdd -> sde or sdc) then it never shows that screen. But no error messages are shown, and the cloning appears to terminate successfully. But when I boot into Windows and check the disk, Windows says it cannot read the disk and that it must be formatted. Futher inspection reveals that the disk shows up in Disk Management as "RAW". (However, if the process completes correctly, then Windows can read the disk, does not ask to format, and Disk Management shows the disk as FAT instead of "RAW.")
I have tried this with a different computer to boot on, a different version of Clonezilla (clonezilla-live-2.6.4-10-amd64), and with different target disks, and I seem to get the same behavior each time.
So, I was looking for insight as to why this is occurring. It works perfectly if Debian assigns sdd to the target disk I plug in (because that matches the image) but otherwise it does not restore correctly even though it seems to think it did after making the temporary converted image.
A bit of additional information after screwing around with it more this morning:
I took the image I am trying to restore, which is on sdd, and manually changed it to be sdb, basically trying to replicate the conversion steps that Clonezilla is doing. When I then boot into Clonezilla and my target disk is recognized as sdb, then I try to restore my manually modified image, and it works correctly.
However, if I try to restore the original sdd image and let Clonezilla do the converting itself, it doesn't work correctly. Upon further inspection, the image I want to restore contains a file called "sdd1.aa". This file is not listed in the Clonezilla output as being renamed, so it appears that the Clonezilla conversion is not renaming this file to "sdb1.aa". When I do my manual image conversion, I do rename that file accordingly, and then everything works. So, it seems to be some issue where Clonezilla's automatic image conversion, for whatever reason, does not change sdd1.aa -> sdb1.aa, and, by assuming causation from correlation, this causes the image not to be restored correctly. (At least, I haven't found a counterexample where that's not the case.)
"sdd1.aa"? We normally do not have this type of file name for the partition /dev/sdd1. How did you save that? What's the file system for that partition?
Steven
That's a good question. I'm trying to restore an old legacy image that was made a long time ago using DR-DOS 5.0. The drives that are being cloned with this image are then being used to run an in-device PC/104 with a Vortex86DX-1 processor (which is meant to be like the i486, which is what this was originally run with). So, yeah, the image was made before my time and I'm not exactly sure how that process was implemented. The file system for the partition appears to be FAT16. I'm not sure if this information helps determine why the file "sdd1.aa" is included, but that's what I know.
If you can, please run:
sudo file sdd1.aa
to see what the file type is.
Steven
So, I ran sudo file sdd1.aa to see what the file type was, and this was the result:
"gzip compressed data, last modified: Tue Jul 28 18:51:16 2009..."
I thought it was interesting that it was a compressed file, so I unzipped it and then it produced a file "sdd1" with no extension. So I ran sudo file on that and got:
"PartImage file version 0.6.1 volume 0 type fat16 device /dev/sdd1, original filename stdout, not compressed"
That was also interesting. It seems that the image was made with PartImage: https://www.partimage.org/.
Doing a bit of Googling, I found a couple sources that identify this file type as a Generic multi-volume CD image which is supposedly "very rarely used":
https://www.file-extensions.org/aa-file-extension-generic-multi-volume-cd-image
https://fileinfo.com/extension/aa
So, I tried editing the image, replacing the compressed sdd1.aa file with the extracted sdd1 file to see if that would fix the issue; however, the issue did not seem to be resolved when I tried to restore my "modified" image.
In the early development of Clonezilla, we used Partimage as the file system engine. Now it's still kept as an option. However, it's not well tested and not recommended to use Partimage to save an image. Since Partimage is not developed for a long time, and we have Partclone afterwords.
For the moment, I believe you can manually run partimage to restore that image.
In the future, please use Partclone to save your image, which is the default option for Clonezilla.
Steven
Ah, okay. That would make sense. Thanks for your time assisting me with this issue!