<![CDATA[Centos 7 UUID not updated during imaging - will not boot]]>SERVER
FOG Version: 1.5.9
OS: centos 7.9

CLIENT
OS: centos 7.9

DESCRIPTION
When we image our centos 7.9 system, which is using UEFI boot and UUID in /etc/sftab, the pc being imaged shows a kernel panic and displays that the UUID for “/dev/disk/by-uuid/(uuid here) does not exist”. Does FOG not change the UUID to match the new system when it finishes imaging? I found an article from 2017 that shows this issue was fixed for a swap UUID.

]]>http://forums.fogproject.org/topic/15325/centos-7-uuid-not-updated-during-imaging-will-not-bootRSS for NodeSat, 10 Oct 2026 11:41:33 GMTWed, 14 Apr 2021 14:34:52 GMT60<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Tue, 20 Apr 2021 06:30:06 GMT]]>@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.

]]>http://forums.fogproject.org/post/142569http://forums.fogproject.org/post/142569Tue, 20 Apr 2021 06:30:06 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Mon, 19 Apr 2021 13:03:46 GMT]]>@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.

Pimage_no_boot.png

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
Pimage_Pmachine.png

Virtual Machine
Pimage_Vmachine.png

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…

]]>http://forums.fogproject.org/post/142555http://forums.fogproject.org/post/142555Mon, 19 Apr 2021 13:03:46 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Sat, 17 Apr 2021 15:34:23 GMT]]>@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.

]]>http://forums.fogproject.org/post/142549http://forums.fogproject.org/post/142549Sat, 17 Apr 2021 15:34:23 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 18:23:55 GMT]]>@sebastian-roth Here is my fstab

centos4.png

]]>http://forums.fogproject.org/post/142548http://forums.fogproject.org/post/142548Fri, 16 Apr 2021 18:23:55 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 18:19:35 GMT]]>@Gerrit-Anderson Please tell us which UUID do you see in the CentOS /etc/fstab for this master VM machine?

]]>http://forums.fogproject.org/post/142547http://forums.fogproject.org/post/142547Fri, 16 Apr 2021 18:19:35 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:34:56 GMT]]>@sebastian-roth Results of blkid -po udev /dev/sda5 are below!

centos3.png

]]>http://forums.fogproject.org/post/142546http://forums.fogproject.org/post/142546Fri, 16 Apr 2021 17:34:56 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:31:25 GMT]]>@Gerrit-Anderson Ok, those seem to match the ones we see in d1.patitions so it’s not something that is being messed up when capturing the UUIDs but looks like the IDs read/set by sfdisk are not the ones used by CentOS.

While in the FOS debug command mode, run blkid -po udev /dev/sda5, take a picture and post that here.

]]>http://forums.fogproject.org/post/142545http://forums.fogproject.org/post/142545Fri, 16 Apr 2021 17:31:25 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:19:20 GMT]]>@sebastian-roth sfdisk version is 2.35.1 Below is output of sfdisk -d /dev/sda

centos2.png

]]>http://forums.fogproject.org/post/142544http://forums.fogproject.org/post/142544Fri, 16 Apr 2021 17:19:20 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:13:39 GMT]]>@gerrit-anderson said in Centos 7 UUID not updated during imaging - will not boot:

The sfdisk that I am using must be what ships with CentOS 7… I also ran this command on my FOG server, and its the same version, but that is also running CentOS 7.

Ahhh, now we are talking!! What I am asking you to do is, schedule a debug capture task and PXE boot the machine into it. Then you get to a command shell and run the sfdisk -d /dev/sda command there.

]]>http://forums.fogproject.org/post/142543http://forums.fogproject.org/post/142543Fri, 16 Apr 2021 17:13:39 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:13:01 GMT]]>@sebastian-roth Ahhh, no. I will do that now. I did not do this in the FOG debug shell. This was all done within CentOS. I apologize… Doing this now!

]]>http://forums.fogproject.org/post/142542http://forums.fogproject.org/post/142542Fri, 16 Apr 2021 17:13:01 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:10:55 GMT]]>@sebastian-roth I may not be understanding this fully, but I ran this command on my master image. That shouldn’t have any impact on anything related to FOG right? The sfdisk that I am using must be what ships with CentOS 7… I also ran this command on my FOG server, and its the same version, but that is also running CentOS 7.

]]>http://forums.fogproject.org/post/142541http://forums.fogproject.org/post/142541Fri, 16 Apr 2021 17:10:55 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:09:44 GMT]]>@Gerrit-Anderson Just checked on the official FOS init used with FOG 1.5.9. Version of sfdisk/util-linux is 2.35.1. No idea where you got yours from.

Sure you run this in the FOG debug command shell? Scheduling a debug capture task and PXE boot the machine into it?!

]]>http://forums.fogproject.org/post/142540http://forums.fogproject.org/post/142540Fri, 16 Apr 2021 17:09:44 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 17:11:00 GMT]]>@gerrit-anderson said in Centos 7 UUID not updated during imaging - will not boot:

The sfdisk version is sfdisk from util-linux 2.23.2

Hmm, this version is really old. We are at 2.35.1 at the moment and 2.23.x was used in buildroot back in 2013. I don’t think we had our FOS image build with such an old version at any point really. For GPT support you need 2.26.x at least I read in the man page. I have no idea how you can have a FOS init with this old versioned sfdisk command.

I suggest you download the latest inits from our server and try with those:

sudo -i
cd /var/www/fog/service/ipxe/
mv init.xz init.xz.old
mv init_32.xz init_32.xz.old
wget https://fogproject.org/inits/init.xz
wget https://fogproject.org/inits/init_32.xz
chown fogproject:apache init*
]]>http://forums.fogproject.org/post/142539http://forums.fogproject.org/post/142539Fri, 16 Apr 2021 17:11:00 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 15:46:41 GMT]]>@sebastian-roth The sfdisk version is sfdisk from util-linux 2.23.2

Yes, FOG 1.5.9 most recent download, CentOS 7.9 (latest version 7)

]]>http://forums.fogproject.org/post/142538http://forums.fogproject.org/post/142538Fri, 16 Apr 2021 15:46:41 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 15:28:50 GMT]]>@gerrit-anderson said in Centos 7 UUID not updated during imaging - will not boot:

These were ran in the debug shell.

Can’t get my head around this. You say your FOG server is 1.5.9. Do you use a custom FOS init?

Please run sfdisk --version in the debug shell and post version here.

]]>http://forums.fogproject.org/post/142537http://forums.fogproject.org/post/142537Fri, 16 Apr 2021 15:28:50 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Fri, 16 Apr 2021 12:21:12 GMT]]>@sebastian-roth So it looks like sfdisk may not support gpt? I ran a couple more commands, not sure if this shows exactly what you are looking for… These were ran in the debug shell.

centos.png

]]>http://forums.fogproject.org/post/142531http://forums.fogproject.org/post/142531Fri, 16 Apr 2021 12:21:12 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Thu, 15 Apr 2021 19:58:19 GMT]]>@gerrit-anderson said in Centos 7 UUID not updated during imaging - will not boot:

/dev/sda1 : start= 1, size=209715199, Id=ee

Looks like the CentOS 7 sfdisk command is not able to read GPT partition layout. This is just the protective MBR entry.

Can you please schedule a debug capture task for the master, boot it up and when you get to the shell run sfdisk -d /dev/sda again. Take a picture and post here.

]]>http://forums.fogproject.org/post/142526http://forums.fogproject.org/post/142526Thu, 15 Apr 2021 19:58:19 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Thu, 15 Apr 2021 18:29:53 GMT]]>@sebastian-roth To add more troubleshooting steps:

Master Image created on HyperV as a Gen 2 (UEFI) VM:
HyperV to HyperV works fine, even to different hosts
HyperV to AMD PC (UEFI) doesn’t boot, missing disk message
HyperV to Intel PC (UEFI) doesn’t boot, missing disk message

Master Image created on AMD PC (UEFI):
AMD PC to AMD PC works fine
AMD PC to Intel PC (UEFI) works fine
AMD PC to HyperV doesn’t boot, missing disk message

It seems to be an issue with the virtual machine from what I can tell… For the time being, I will keep two images, one for VM’s and one for physical machines… I would like to have an end result of one image working on HyperV and Intel/AMD based desktops. If you have any other troubleshooting steps I can try, I am willing to give them a shot.

I appreciate the help so far!

]]>http://forums.fogproject.org/post/142523http://forums.fogproject.org/post/142523Thu, 15 Apr 2021 18:29:53 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Thu, 15 Apr 2021 12:00:38 GMT]]>@sebastian-roth The output from sfdisk -d /dev/sda is below:

# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=        1, size=209715199, Id=ee
/dev/sda2 : start=        0, size=        0, Id= 0
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0
]]>http://forums.fogproject.org/post/142510http://forums.fogproject.org/post/142510Thu, 15 Apr 2021 12:00:38 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Wed, 14 Apr 2021 19:53:45 GMT]]>@Gerrit-Anderson Can you please run sfdisk -d /dev/sda on the master and post output here?

]]>http://forums.fogproject.org/post/142496http://forums.fogproject.org/post/142496Wed, 14 Apr 2021 19:53:45 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Wed, 14 Apr 2021 16:09:35 GMT]]>@sebastian-roth Update - This master image was created on a Gen 2 HyperV VM. Not sure if that could be causing an issue…? Seems like if I send the image to any of my HyperV hosts, it works perfect. UUID’s are exactly the same as the master, image boots and operates normally. When I send the image to a desktop is the only time I have this issue.

]]>http://forums.fogproject.org/post/142489http://forums.fogproject.org/post/142489Wed, 14 Apr 2021 16:09:35 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Wed, 14 Apr 2021 15:41:52 GMT]]>@sebastian-roth Thank you for the reply. I have the contents of the d1.partitions file below.

label: gpt
label-id: 3F338E38-6A09-4FCE-92B1-B465C0ED8E35
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 209715166
sector-size: 512

/dev/sda1 : start=        2048, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=3DD480BD-6B22-4812-B5E1-2310A243D7F2, name="EFI System Partition"
/dev/sda2 : start=      411648, size=     2097152, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=D8C4A9F7-60A1-4B79-874D-55BE7824CE32
/dev/sda3 : start=     2508800, size=    62914560, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=68E3E8A9-3938-4489-9A05-B2257D5934C6
/dev/sda4 : start=    65423360, size=    16517120, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=36DB8CD8-56C2-4CEF-8652-3640AE9E19AF
/dev/sda5 : start=    81940480, size=   127772672, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F056C997-2D96-4DDF-98D3-5E4BD44C1378

None of the UUID’s listed in this file match the UUID’s of the original image master. I can confirm that once the client gets imaged, it starts to boot CentOS and then goes to the emergency shell stating “/dev/disk/by-uuid/ (uuid here) does not exist” The UUID it shows matches the UUID from /sda5 on my master.

Any help is appreciated!

]]>http://forums.fogproject.org/post/142482http://forums.fogproject.org/post/142482Wed, 14 Apr 2021 15:41:52 GMT<![CDATA[Reply to Centos 7 UUID not updated during imaging - will not boot on Wed, 14 Apr 2021 15:17:42 GMT]]>@Gerrit-Anderson The FOS inits do read the UUID from the source partition table and apply those to the destination system.

Please post the contents of the text file d1.partitions for this particular image. You find that on your FOG server in /images/#IMAGENAME#/d1.partitions

]]>http://forums.fogproject.org/post/142479http://forums.fogproject.org/post/142479Wed, 14 Apr 2021 15:17:42 GMT