Failure in Capturing an image
-
The fixes we put in place where 2 fold.
First we put in the fix to address the issue of RAW imaging not passing a partition for partprobe. This was handled by passing a variable to test if the image is raw or not. If it’s raw, the flag gets set and the function returns the disk as it was sent to the function.
Second we are using a more implicit means to return the disk when the partition information is passed.
The only real difference that I’m seeing here, is that the 0.3.12 partclone doesn’t like doing the the translation.
THis is okay, leave your post init script in place. Edit the funcs.sh file and remove the -a0 (or -a1 if this is still in place) from the file.
Download the proper inits again using:
wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xzThen you should be all set. The init’s will have the proper funcs.sh for 0.2.89 partclone as well as the changes that were in the init’s you downloaded from our dev server.
-
@Tom-Elliott
Trying this now, will attempt to see if it deploys properly. -
@Tom-Elliott said in Failure in Capturing an image:
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz
It now works completely.
Thank you very much.
-
@Tom-Elliott said in Failure in Capturing an image:
@ismith-hpu But the machine, indeed, does have an OS on the disk? I can only assume the -a0 is a part of the problem. I don’t know what the argument is doing for the 0.3.12 version of partclone.
It’s to ensure compatibility with 0.2.89 images, allowing them to be deployed with 0.3.12.
0.2.89 had a broken checksum system, so we force it disabled on 0.3.12 in order to allow those images a normal deployment. It’s also faster and slightly smaller images, certainly not complaining about that part.
It is curious that 0.3.12 doesn’t seem to work in this instance, though I wonder if a non-resizable (not raw) capture has been tried?
