Failed to set disk guid (sgdisk -U) restoreUUIDinformation

[clemens.g]

I just wanted to start a new topic about the exact same error. Since this is my first setup, I cannot say if it was also present in earlier versions. Currently I’m running the latest trunk (6150), last update today… the only thing I can contribute ist that this happens with every image I captured (Win7, Win8.1, Win10, …) and on vastly different hardware.

As mentioned before, the cloned machines actually work fine but the job never finishes and has to be cancelled manually.

Best,
Clemens

[Tom Elliott]

@clemens.g the ultimate question when did the original uploads actually occur? My guess is they happened befor 6152.

[clemens.g]

@Tom-Elliott:
Actually I did all of them today, every single one of them. So all on 6150… I might try to recapture the images in a few days from now, though.

[apathetic_admin]

@Tom-Elliott Cleared out, reimaged, and the same thing happened.

[Tom Elliott]

@apathetic_admin That is impossible.

Why?

Line 62 of the /usr/share/fog/lib/partition-funcs.sh contains the line:

[[ ! -r $file ]] && return

What this does, if the file (which in our case is the uuid filename) does not exist, it simply returns the call back to the area. This error would not show up if the file does not exist.

Can you put your system in debug, (the system you’re seeing this issue) and show me a screenshot of the file and particularly the function above for line 62?

[Tom Elliott]

@clemens.g This file should only be created if the partition layout is GPT vs. MBR. Can you get output of:

sfdisk -d /dev/sda from the system that uploaded the image (just one of them should be fine).

Also, if you are seeing this, if you delete the .uuid file, does everything work?

[Tom Elliott]

@clemens.g I just updated the inits.

The d{disknumber}.original.uuids file will now only be created if the partition layout is gpt.

While this was my intention originally, I had a spot where I was “touching” the file, but this creation of the file happened before the checks that actually store data to the file were being done. So it was possible for the uuids file to be created, albeit with no data actually in the file.

This would present the sgdisk -U error as described because there was no data to be found within it. So it was trying to set the uuid of the disk to blank which would fail as it expects a parameter to be set.

Hopefully this is all fixed now and new uploads of MBR disks will not have this issue.

As I stated earlier, if you’re running into the sgdisk -U error in restoreUUIDInformation, please delete the *.original.uuids file from the images you have.

@apathetic_admin it seems this either didn’t happen, or something else replicated the image with the uuids file back down. Just a guess.

[apathetic_admin]

@Tom-Elliott I read your post earlier, then I went and dealt with some other crap for a few hours, came back to my desk and deleted the contents of the file and then tried again. I re-read your post after I got home and realized that I did something stupid. Deleted the file, pushed an image, and it completed successfully.

[Tom Elliott]

@apathetic_admin So it is safe to solve this thread?

[clemens.g]

@Tom-Elliott
I can only test it again tomorrow but I will do so and give you feedback. Thanks for now!

[apathetic_admin]

@Tom-Elliott Yes my issue is resolved, thanks. On another thread I was able to mark it solved in Topic Tools but I didn’t have that option here.

[Tom Elliott]

@apathetic_admin You can mark it as solved now. It first needed to be “asked as a question”.

[clemens.g]

@Tom-Elliott
Works perfectly now! Thank you very much!