Failed to set disk guid (sgdisk -U) restoreUUIDinformation

[apathetic_admin]

Some history:
We wanted to upgrade from FOG 0.32 to current and move to a new server all at the same time, so we installed the OS (Ubuntu 14.04), installed FOG via git, and then I copied the mysql database over from the old server and ran the database upgrade via the web gui. We changed the IP address while we were at it, so I changed all occurrences of the IP address in the FOG database before I imported it into MySQL and did the upgrade. I have passwords synced up and everything is generally working the way I would expect except when an image has completed writing to a workstation, an error occurs:

Failed to set disk guid (sgdisk -U) restoreUUIDinformation

After that, it waits for 60 seconds, and then reboots. If I allow it to boot to Windows everything works as I would expect after a machine was reimaged, however the task is never ended on FOG and if I PXE boot it will write the image again. I have tested several hardware configurations and I get this error for all of them.

I did a git pull about ten minutes ago, and I’m on FOG 6152 according to the version screen.

[Tom Elliott]

For the image that’s coming down what is the contents of the d1.original.uuids file?

[apathetic_admin]

@Tom-Elliott

/dev/sda 372b02d9
/dev/sda1 1:8C4A1EDF4A1EC63C 1:372b02d9-01
/dev/sda2 2:06AC20B6AC20A263 2:372b02d9-02

[Tom Elliott]

@apathetic_admin do me a favor, and yourself I suppose lol, delete the file and retry the image task.

[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!