Posts made by Gerrit Anderson

There are many posts over the last few years that are unsolved pertaining to an issue when PXE booting a legacy (Generation1) HyperV VM with FOG. It appears UEFI (Generation 2) VM’s are not affected. When using a default FOG installation, a Generation 1 HyperV VM will not boot to the PXE menu, resulting in a hang on the screen below (iPXE Initialising devices…)

To solve this issue, iPXE needs to be recompiled with a few settings changed. Below are steps to recompile iPXE with settings required to make Generation 1 VM’s boot.

Step 1 - Download FOG via git into a new folder (in this case /opt/custom)

mkdir -p /opt/custom
cd /opt/custom
git clone https://github.com/fogproject/fogproject.git fogproject

Step 2 - Add the following 3 lines to /opt/custom/fogproject/src/ipxe/src/config/general.h (I added them on line 175)

#undef DOWNLOAD_PROTO_HTTPS
#undef IMAGE_TRUST_CMD
#undef CERT_CMD

Step 3 - Recompile iPXE by issuing the following commands (you may need to make buildipxe.sh executable)

cd /opt/custom/fogproject/utils/FOGiPXE
./buildipxe.sh

Step 4 - Move the new iPXE files into the tftp directory. This can be accomplished two ways.

1. Rerun the fog installation script from the new directory (/opt/custom/fogproject/bin/./installfog.sh

OR

2. Copy the files from /opt/custom/fogproject/packages/tftp to /tftpboot overwriting the previous files

You should now be able to boot a Generation 1 HyperV VM to FOG. The only change appears to lose the .png background for the menu (see below).

Credit to @george1421 for these steps. Through multiple different posts about similar issues, his replies led me to this conclusion.

This was tested on Windows Server 2019 and Windows 10 21H2 HyperV Virtual Machine Clients. This was tested on FOG 1.5.9 running Rocky Linux 8 and iPXE 1.21.1+.

@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 Here is my fstab

@sebastian-roth Results of blkid -po udev /dev/sda5 are below!

@sebastian-roth sfdisk version is 2.35.1 Below is output of sfdisk -d /dev/sda

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

@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.

@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)

@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.

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

@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

@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.

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

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.

I see that, but what should be set? Do we just put the legacy password in from previously and leave the new one blank?