@mdxlp You may need to add this code to your fog post install script to load in all of the variables that fog has to offer into your post install script.

if [[ ! -z $mac ]]; then
    curl -A "" -Lkso /tmp/hinfo.sh ${web}/service/hostinfo.php -d "mac=$mac" 
    if [[ -f /tmp/hinfo.sh ]]; then
        . /tmp/hinfo.sh
    fi
fi

This basically makes a call to the fog server to collect the host info for that specific mac address. then it loads the hinfo.sh script created by the php program.

FOG is linux based, and linux can not step into the windows realm, so there is no equivalent linux command for netdom that is windows only.

@SebastianWolf What version of FOG are you running?
Second bit is have you tried to rebuild ipxe with the latest source code: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1687483137078 sometimes it does take the iPXE developers (not related to the fog project developers) a little bit of time to support really new kit. So there may be updates to iPXE after the FOG developers released the latest version. So lets start with iPXE rebuild if you are never seeing the iPXE banner on these computers.

If iPXE is failing for you we do have a method to usb boot into FOG, you lose some capabilities but it will image correctly once you register the target computer with FOG. So you guys are not dead in the water if iPXE doesn’t support your hardware just yet.

@C-Franklin Manually register this target computer. You will need the mac address of the target computer then add a new host with that mac address. Now schedule a deployment, but before you hit the submit button tick the debug check box then submit the job.

Now pxe boot the target computer, it should go into imaging right away (I want to see if iPXE is detecting the mac address). If it goes into imaging after several screens of text tat you need to clear with the enter key you will be dropped the FOS Linux command prompt you may still see the no viable mac address error, but that’s OK for now.

Once at the FOS linux command prompt I want you to key in the following commands. After the last command it keyed in take a clear picture of the screen and post the results to this thread.

uname -a
lspci -nn | grep -i net
grep -i firmware /var/log/syslog

I can never remember of its /var/log/syslog or /var/log/messages so YMMV.

On this target computer find one of the same model that has windows installed. In the device manager check this nic and collect the hardware ID of the nic. We will need the vendor and device IDs in case the lspci command doesn’t return anything usable.

@rhromyko said in new version e2fsck ?:

I get the error message when I try to create an Ubuntu 23.04 image

Sorry to ask the question again, but your response can be read a few different ways. I think I understand what you are doing with FOG but I want to be sure.

1. You are using FOG to PXE boot into some live image of ubuntu?
2. You are either capturing or deploying a golden image from a source computer. You are getting this e2fsck error wile imaging a computer (using fog as it was designed for system cloning) with FOG.

Remember here we are trying to understand where the error is by your words explaining what you are doing at the time the error is made.

@rhromyko This is probably related to the latest versions of Ubuntu and Debian, I’m a bit surprised that 22.04 has the issue though. I’m suspecting that FOS Linux doesn’t have the 1.47 version installed. Is the error happening during imaging or is it when you live boot Ubuntu?

As Tom mentioned the term “PXE OS” could be confusing the issue. Let us know exactly where in the process you are getting this error.

@Enigma Well it look like I forgot to hit submit earlier when I responded. Looks like the dhcp server is up and running and listening on port 67. So that is the first half of getting things to boot.

I think the next step is to configure the fog server to capture a pxe boot packet to see if there are any other actors involved. Here are the steps needed to configure tcpdump on the fog server to capture the pxe booting process.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1687300270627

Other things I’ve seen cause pxe booting issues.
If dhcp snooping is enabled on your network to only allow dhcp packets to get to the defined dhcp server and that dhcp server is not the FOG server.
If you have more than one dhcp server on your subnet and the other dhcp server responds before the fog server.
You have a proxy dhcp server configured on your network
Your fog server is running as a VM on a vm host server that doesn’t have the promiscuous network mode enabled.

Most of these questions will be answered with the pcap. Once you collect the pcap upload it to a file share site and share it as public read only. Then either post the link here or use the fog forum chat and DM me the link. I will take a look and let you know what we found.

@Enigma ok on the fog server linux console. Key in the following command netstat -an | grep :67 That should return a line like 0.0.0.0:67 This will show if the dhcp server is running on the fog server. You can also run this command ps aux| grep dhcp to see if the isc-dhcp server is running in memory. Lets confirm that dhcp is functioning on the fog server

@Florent for the 64 bit versions of uefi, you would replace ipxe.efi with snp.efi or snponly.efi in the config file and then restart the dns server.

The difference between snp.efi and snponly.efi is that the snponly.efi will only init the network interface where the snponly.efi was downloaded from, where the snp.efi will init (and try to boot from) all interfaces in the target computer.

@smazzola What version of FOG are you using?
What version of the FOS Linux “Kernel” are you running?
What error are you getting on the target computer? Can you get a screen shot of the error to provide context?

@Enigma Your post is missing enough info to help.

Is 192.168.107.x an isolated network?
Is there an existing dhcp server on this subnet?
What error are you getting on the client computer?

@wass Since all of the boot loaders you mentioned are bios boot loaders and you are seeing the no configuration methods succeeded it sounds like the computer is in bios mode. Its strange that iPXE and bios mode computers are not able to configure the interface. For bios the boot loaders undionly.kpxe or ipxe.kpxe should work on 99.8% of all computers. Does this computer have multiple nic cards?

@plegrand Since bookworm just was released the developers haven’t had a chance to fully vet the deployment. Unless you have a compelling reason to upgrade, I would hold off if this server is in your production environment. Sometimes walking on the bleeding edge, you could end up with red stuff all over the place.

With the FOG Project and it being summer, the developers are taking it easy for now to spend time with their families.

@Kusa555 So this system just stays at the initializing devices and never leaves? This is rare for undi (bios) mode. The undionly.kpxe boot loader is correct since your computer is in bios mode.

It looks like that hardware was released in 2010 so it should be well supported by FOG.

Check to see if there is a bios (firmware) update for this computer. This issue is specifically between iPXE, bios, and the hardware. Technically FOG hasn’t started in the screen shot.

The last thing I can think of is if this computer has any abnormal add in cards (like networking) where iPXE might have an issue configuring them.

@mdxlp No worries my french is terrible, and my english is not much better

So we have an example of a post install script for windows, what it does is search through all of the partitions on the deployment disk looking for the windows folder or file. Once that key or flag file is found it knows its the “C Drive”. You should be able to use the same concept with your task. Look for a directory or specific file (like “/etc/hostname”) to know you found the correct partition. From there you can then cat/echo the FOG hostname variable into that file.

Here is the windows focused solution
https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Look at the fog.custominstall script. That script locates the partition with the windows directory on it.

This tutorial has the fog variables avaialble for the post install script
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/18?_=1686319619362

$hostname is the name assigned to the computer in the FOG web ui

@jeremyvdv If you have a windows dhcp server AND you need to pxe boot both bios and uefi based computers you might want to review this wiki page to setup dhcp profiles so your dhcp server sends the proper boot file name based on the target computer: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@jgibson60 Will you provide screen shots or better explanation of what your error is. Your post leaves a lot of missing details.

Do you get to the FOG iPXE menu?
Do you get an error message from FOS Linux (after the fog banner is displayed)?

@louis-tasse ok the first error is because you did not schedule the task first in the FOG ui. The “NULL” message indicates that there was no task found on the server. This fact is noted in the caveats in the tutorial.

@WT_101 said in RHEL Initramfs unpacking failed: & Kernel panic - not syncing::

snp.efi from Fogproject 1.5.7 & 1.5.8

Unless you are using SANBOOT or EXIT (exit) modes, snp.efi or iPXE for that matter is not responsible for booting a uefi computer. The responsibility for booting uefi computers is handed over to rEFInd. I might suspect that refind version changed between 1.5.8 and 1.5,10.

So do you mean to say if you take snp.efi from fog 1.5.7 or .8 and copy it over to FOG 1.5.10 install you can boot rhel 9?

If you were to recompile iPXE with the very latest code doe it boot rhel 9 correctly (assuming that iPXE is at fault here)?

@Jamaal We are not using the 5530s on our campus so I can only guess its a driver issue, or missing driver issue. The windows “getting devices ready” part is where the drivers are being loaded, its possible that the windows built in drivers are conflicting with the hardware where the real 5530 dprivers are needed to make things work. The drivers being loaded in the setupcomplete.cmd may arrive to late or not at all if the computer never made it to run the setupcomplete.cmd file.

@louis-tasse said in Using FOG without PXE - FOG client on USB key:

if you can provide a starter image for network USB booting that would be awesome.

The instructions for creating the FOS linux boot drive is here: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image Look at the FOG forum chat for an additional hint.

In regards to what RipAU mentioned that method will also work, you gain the ability of multicast imaging and quick deploy image if you boot using iPXE. As was mentioned you just need to update the boot time script with the IP address of your fog server. FOG has the needed tools built in to compile ipxe, there is no need for the rom-o-matic site that seems to have been retired. I have a tutorial here on how to recompile ipxe on the fog server: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe I would run through the script the first time to compile everything. Now comes the part to integrate what RipAU mentioned. In the based directory where you cloned the fogproject github site (typically /root/fogproject or /opt/fogproject depending on whos instructions you used) There will be a src/ipxe directory. In that directory tere will be a src and src-efi directory, these are the source files used to create FOG’s version of iPXE. If you go into each of those directories there will be a file called ipxescript That is where the startup script for iPXE is.

#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcpnet2
isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
echo Received DHCP answer on interface net2 && goto proxycheck

:dhcpall
dhcp && goto proxycheck || goto dhcperror

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

:nextservercheck
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:chainloadfailed
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:netboot
chain tftp://${next-server}/default.ipxe || goto chainloadfailed

Remove the following lines from that script

isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

:nextservercheck
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

now change the very last line

chain tftp://${next-server}/default.ipxe || goto chainloadfailed

Replacing ${next-server} with the IP address of your fog server. Do this for both the fogproject/src/src and fogproject/src/src-ipxe ipxescript files.

Now recompile iPXE and move the updated files to the /tftpboot directory as instructed in the previously linked tutorial.