Testers

@sebastian-roth Yeah, today’s tests look like a mess. Though, what your saying about this GPG key. All the tests use the same OS, same patch level each day. If there was an issue with a GPG key in master branch, wouldn’t it be true that the same problem exists in dev branch? Most days, this is not the case. Most days, just master branch fail for CentOS 8 and RHEL 8.

There are ways to inject commands before installation, though the point of these tests is just to see in an automatic way if there are any issues that arise for a typical installation.

@tesparza Well we need to get a few things straight here.

I assume you are building a uefi golden image? When deploying it to a target computer (vm) is that VM in uefi mode? For the uefi firmware, if it detects a uefi boot disk it will add that boot disk into the boot manager. If it can’t locate a valid uefi boot disk, it will only display uefi pxe booting options. Remember that you can only deploy a uefi source image to a uefi target computer, the same holds true for a bios source image, it can only go to a bios based target computer.

I would start out by making sure your source and target VMs are setup the same way, bios, memory, disk and such. If they are then you can start to debug this issue by scheduling another deploy task to the target VM but before you tick the schedule task button, check the debug checkbox. Now pxe boot the target computer. After a few screens of text on the target computer you should be dropped to a fos linux command prompt. Understand where you should be is on the target computer where you just previously deployed the image, but now you are in debug mode. Key in the following command, lets see what the existing disk structure looks like lsblk

Once we know that we can debug this issue a bit more.

@sebastian-roth said in RHEL 8, CentOS 8, master branch, July 22, 2021:

Seems like the REMI GPG key changed. You need to manually run dnf update once and confirm the GPG key import.
Interesting this is not happening for the dev-branch tests.

@Sebastian-Roth I have done this. Which is why I’m bringing it up again.

@lps The location plugin is not quite that sophisticated. You assign storage nodes to the location and then the registered hosts to a location (the location field is added when the plugin is installed). That way a pxe booting target computer knows how to find its storage node.

For bulk setting the location on a group of computers, create a FOG (set) group. Assign the hosts to that FOG (set) group then use the group to assign the location to the target computers in that group.

(FWIW FOG Groups don’t work the way you might think a group works. They are more for setting a number of computers one or more values at one time. They are not persistent groups).

@lps You need to enable the plugin manager in the FOG Configuration->FOG Settings menu then install the location plugin.
https://wiki.fogproject.org/wiki/index.php/Location_Plugin

@austinjt01 said in Lenovo P52 - Stuck on iPXE 1.20.1:

Yes still stuck at the handoff to FOS.

One option you can try is to compile the latest version of iPXE. There has been some updates to iPXE since 1.5.9 has been released. There may be some value in trying the process outlined by Sebastian here: https://forums.fogproject.org/post/141618

You will need the github version of the fog installer to follow these steps.

@sebastian-roth said in boot php - denied:

@robertkwild said in boot php - denied:

the desktop in question that gets the error is a hp z640

Searching the forum I found that @JJ-Fullmer also has used HP Z640 machines some time ago. I am wondering if you have HTTPS enabled on your FOG server as well?

Holy cow that was a long time ago. That’s when we added nvme support. Good times.

Glad to hear you got it working @robertkwild sounds like it probably was the cmos/time issue.

@austinjt01 Have you tried different versions of bzImage and or init.xz?
i.e. try downloading the latest kernel from the kernel update screen in your fog gui and giving it a name like bzImage5 and then set that case sensitive name as the kernel on the fog host in question and see if it makes a difference.

Also, have you checked in the fog web task manager when it is stuck to see if it shows progress there? It’s rare, but I remember once seeing it look like it was stuck but the computer just wasn’t displaying the progress and it was actually working.

@austinjt01 Where is it stuck at? Still at the handoff to FOS? I don’t think sysprep is contributing to it working/not working. It could just be bad timing.

@austinjt01 Just because its a Lenovo, I would say to ensure your firmware is up to date.

The issue is the uefi hand off between iPXE and FOS Linux kernel. We have seen this error before on different systems. Its usually tracked to a bug in the firmware on the target computer.

You can get past/mask the issue by booting FOS Linux off of a usb stick but that approach has some drawbacks so it should be an almost last resort to image this computer step.

What version of FOG are you using?