@flareimp I didn’t want to confuse the subject so I didn’t initially include this.

When you schedule an inventory task this is the call to launch the FOS Linux client.

#!ipxe
set fog-ip 192.168.50.53
set fog-webroot fog
set boot-url https://${fog-ip}/${fog-webroot}
set storage-ip 192.168.50.53
kernel http://192.168.50.53/fog/service/ipxe/bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=https://192.168.50.53/fog/ consoleblank=0 rootfstype=ext4 mdraid=true mac=00:00:00:87:c2:09 ftp=192.168.50.53 storage=192.168.50.53:/images/dev/ storageip=192.168.50.53 osid=9 irqpoll hostname=00000087c209 mode=inventory deployed=1 mdraid=true
imgfetch http://192.168.50.53/fog/service/ipxe/init_32.xz
boot

What we are doing is simulating that call via an iPXE menu. I discarded the parameters above that shouldn’t be needed for a hardware inventory. I may have discarded too many. So I do see it passing the mac address during this invocation. Understand what we are doing is not using FOG as it was intended. It should work by YMMV.

So lets tweak the last command I gave you by adding in the mac address (there is room for this command it get it wrong if you have multiple nic adapters in the computer).

:fog.custom.inventory
kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=${boot-url}/ consoleblank=0 rootfstype=ext4 storage=${fog-ip}:/images/ storageip=${fog-ip} loglevel=4 mac=${net0/mac} mode=inventory deployed=1
imgfetch init.xz
boot|| goto MENU

@epsilon52 You are sending the wrong boot file then. Please change option 67 to ipxe.efi then it will boot.

@epsilon52 So the next question, is the target computer in bios or uefi mode?

@will FOG does not know or care about HDD or SSD drives. All it does is write the image to a disk you tell it to. If you have a computer with a SSD and HDD installed you will need to tell FOG which disk to write the image to.

@olsen Yes that is what I was thinking of. Read over that document and understand the caveats. Look at the fog forum chat bubble for a few more hints to get you a jump start.

@olsen It sounds like its hanging on the uefi startup code. After bzImage and init.xz are transmitted the next step is to boot. That is where its hanging. Its the transition between the ipxe.efi boot loader and the FOS Linux kernel. The in between problem is usually flaky uefi (firmware) on the target computer. The proper fix is a firmware update on the computer.

Since ipxe is not handing off things properly we can have you create a FOS Linux boot drive. There are some drawbacks to this approach but I’m pretty sure we can get you imaging until Lenovo provides a fix.

@sebastian-roth I don’t think its possible without interent access. (Speaking from a RHEL perspective) for the libraries and packages if there was an internal repository (which of course internet access is needed to populate) all of the distribution files could be made internally. I assume that for the Debian variants its also possible to create an off-line package repository.

The issue is downloading the precompiled binaries from the FOG. How could that be bypassed.

@epsilon52 said in I think i may be just dumb:

So when i change the boot order to allow ipv4 and ipv6 pxe boot it boots through them every time never showing me the pxe screen. then eventually getting to the windows

OK so your computer tries to pxe boots and then fails to pxe boot and windows starts. You NEVER see the FOG iPXE menu? If this is the case, then we can focus on the pxe booting process.

What specifically do you have configured for dhcp options 66 and 67? These would be values you set in your network’s dhcp server. The pxe booting computer uses the values stored in 66 and 67 to know where the FOG server is and what boot loader to download.

@epsilon52 Just to be sure we understand what is going on here.

When you change the pxe boot first in the boot order. The computer pxe boots and do you see the FOG iPXE menu?

And where its failing is after the iPXE menu times out instead of booting into windows it just reboots?

-OR-
Are you never seeing the FOG iPXE menu?
Do I understand where its failing?

@epsilon52 Ok you are missing a setting in the bios configuration. On the network tab, you need to tick the “Enable uefi network stack” (or something named similar. Its usually at the very top of the network configuration page) to be able to pxe boot in uefi mode.

Then you will be able to set the pxe booting first in the boot order if you want to do that.

@epsilon52 What is your default boot order in the firmware? Are you boot through pxe boot or is your system configured to boot into windows directly?

@flareimp said in Add Full Inventory Task to PXE Menu:

If we look at the FOG created menu for system info

:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://10.220.9.50/fog/ consoleblank=0 rootfstype=ext4 storage=10.220.9.50:/images/ storageip=10.220.9.50 nvme_core.default_ps_max_latency_us=0 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU

And we look at the custom menu I initially provided they should match exactly except for a few changed parameters. This should work. I did notice in your menu item that boot and the double pipe symbols don’t have a space between.

:fog.custom.inventory
kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=${boot-url}/ consoleblank=0 rootfstype=ext4 storage=${fog-ip}:/images/ storageip=${fog-ip} loglevel=4 mode=inventory deployed=1
imgfetch init.xz
boot|| goto MENU

The bzImage32 and init_32.xz is just an artifact of calling the menu via a browser and can be ignored.

@flareimp From a computer on the same network as your FOG server http://<fog_server_ip>/fog/service/ipxe/boot.php&mac=00:00:00:00:00:01 just replace <fog_server_ip> with the IP address of your fog server.

I guess I should also ask what version of FOG are you using?

@flareimp OK I see what it did. In the post it looks like “loglevel=4 mode=inventory deployed=1” is on a new line, but that needs to be part of the entire imgarg command. On the screen it wraps.

@flareimp Something wasn’t added right to the menu. Please call the url I mentioned before and post the results here.

@seppim The ClamAV menus and settings should have been removed since that is a very old and no longer supported feature of FOG. I understand there maybe bits left over that mention clamav, be assured it is not supported by the developers.

@flareimp Ok lets change the parameters up a bit.

Menu Item: fog.custom.inventory
Description: Custom Quick Inventory
Parameters:
kernel bzImage
imgfetch init.xz
imgargs loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=${boot-url}/ consoleblank=0 rootfstype=ext4 storage=${fog-ip}:/images/ storageip=${fog-ip} loglevel=4 mode=inventory deployed=1
boot || goto MENU
Menu Show with: All Hosts

You should paste the parameters in directly without trying to decode anything.

If it still doesn’t work what I want you to do with a browser key in the following URL http://<fog_server_ip>/fog/service/ipxe/boot.php&mac=00:00:00:00:00:01

This is the text behind the iPXE boot menu. Copy and paste that text into a post here. I want to look at how the menu is created if the above doesn’t work. The instructions I provided should not have created that error message. Maybe another error message, but not that one.

@wayne-workman said in Simplifying Deployment with Official Virtual Appliance:

Someone out there has already installed FOG on CentOS Stream.

More than slightly off topic post:

Well the end is near for the CentOS line. IBM is positioning CentOS Stream as development OS for RedHat akin to what Fedora is/was. Centos Stream will not be a stable server operating system. Support for Centos 7 will continue until June 2024. End of maintenance support for Centos 8 is Dec 2021 (effectively killing the OS).

If it was my decision I would not plan on FOG supporting CentOS Stream officially. If FOG works on it great but from an official support standpoint there is little value. Hopefully someone (group) in the opensource community will step up and create an OS that will replace Centos based on RHEL.

@shyvvana Are these two isolated network where you have no router today between the subnets and you have no default router installed on at least one of them?

@seppim To slightly expand on what Sebastian just posted.

With the multicaster there are 2 triggers to start the imaging process.

1. Number of clients
2. Timeout

With 1. If you set it to 4 clients, as soon as the 4th client connects imaging will start.

With 2. If you set it to 3 minutes. Imaging will start at 3 minutes even if all of the clients haven’t checked in yet.

2. There is no way to selectively skip a target computer when deploying to a group. You are either in or out of the group when deployment is requested.

3. Windows product key. Can you do this with FOG? Yes. Can you do this without sysprep, not easily. If you use sysprep then you can write the key into the unattend.xml file that is used during the first boot. Without sysprep you can still do something like during imaging write the key to a file on the c drive then in your golden image before capture created a scheduled task that runs at login to read that file dropped by FOG and activate the system.

4. If one of the group fails. After a timeout the others should continue on. That is what I think is the imaging flow. All should not wait forever for that lost computer to wake up.