Centos 7 UUID not updated during imaging - will not boot

[Gerrit Anderson]

@sebastian-roth Here is my fstab

[Sebastian Roth]

@Gerrit-Anderson I have not looked into the UUID stuff in a long time, obviously. The /dev/disk/by-uuid/... and /etc/fstab are both using the filesystem UUID. What we capture in d1.partitions are partition UUIDs - which are different to FS UUIDs!

So we need to look at partclone (used to clone the actual filesystem data) to see if it’s messing up the filesystem UUIDs or not. In general partclone is meant to clone everything including the filesystem UUID. So it really shouldn’t mess with it as far as I know (ref).

Please schedule a debug deploy task on a physical machine (as you said this doesn’t happen when deploying to a VM). PXE boot that machine and when you get to the command shell start the deployment using the command fog. You step through the whole process by pressing ENTER every so often and when it’s all done you will get back to a command shell. Here I need you to run the command blkid, take a picture and post that here.

If you are keen, do the same debug deploy but on a VM. Step though the process and run blkid in the end.

[Gerrit Anderson]

@sebastian-roth Looks like the mystery continues… Below are results!

Creating the master image on a physical machine allows me to sent to any other physical machine, doesn’t need to be like models. Sending the master image built on the physical machine to a HyperV VM causes the same issue as from a HyperV master image to a physical machine. The message is below, warning that the UUID doesn’t exist and cannot boot.

When running debug deploy tasks, below are the results for the physical machine and virtual machine UUID’s respectively. They look identical… This makes me wonder why CentOS doesnt think the disk UUID exists…

Physical Machine

Virtual Machine

The physical machine boots fine, virtual machine tries to boot and then goes to emergency mode.

From what I can tell, FOG is handling the UUID’s correctly…

[Sebastian Roth]

@gerrit-anderson said in Centos 7 UUID not updated during imaging - will not boot:

From what I can tell, FOG is handling the UUID’s correctly…

Would say so too from what we discovered so far. It’s interesting you can capture/deploy from/to VM<->VM and machine<->machine but not “across”.

For further debugging I suggest to dig into the dracut emergency shell/mode more. First run ls -al /dev/disk/by-uuid/ on the dracut command prompt and post a picture of that here. As well you might also follow the instrcutions printed, run journalctl and look through the log for hints on why it fails booting. Also take a look at the file /run/initramfs/rdsosreport.txt mentioned. Feel free to share the file here and I’ll take a look as well.

Edit:
Searching the web I found this: https://unix.stackexchange.com/questions/183859/initramfs-uuid-problems-after-cloning

Sounds like the initramfs might be generated differently on your VM and bare metal install. Both are missing a driver for the other one. If that turns out to be true you need to find out which one is missing and manually regenerate initramfs with dracut e.g. on your VM before capturing the image to be deployed to hardware.