Hey Tom, take your time and get yourself settled!

I am wondering if this is a good point too where we reach out to the community for people to join into the FOG team to help work on the code, fix issues, improve stuff here and there.

@Tutungzone Maybe there is a quick fix for this issue. It’s been some time since we updated the RAMDISK size and I guess this could fix it: Go to the FOG web UI -> FOG Configuration -> FOG Settings -> TFTP Server and set KERNEL RAMDISK SIZE to 275000. Save settings and try booting into a task again.

https://news.fogproject.org/fog-1-5-8-officially-released/

https://github.com/FOGProject/fogproject/releases/tag/1.5.8

https://news.fogproject.org/fog-1-5-9-officially-released/

@Tom-Elliott, @Developers, @Moderators
I got carried away trying to improve the current iPXE script. Now that I’ve dug into the syntax and found some interesting new stuff I want to see what you guys think about this:

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

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

: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} && isset ${next-server} && echo Duplicate option 66 (next server) from DHCP proxy and DHCP server && echo Using IP sent by DHCP proxy ${proxydhcp/next-server} && prompt --timeout 5000 || goto nextservercheck

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

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

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

Feel free to comment and improve. I’ve tested the script and tried to remember all the issues I came across in the last months but I am sure we’re not there yet.

I want to thank Tom again for this! I tried to assist and help but I just don’t know the code (and its history) as much as Tom does. He’s done all the hard work to find and fix this issue. Along the way he also fixed a couple other things as well.

@Tom-Elliott Don’t say sorry. FOG is work in progress and you are pushing things way forward!! :metal:

@TrialAndError said:

Obviously the development of FOG stopped after a long time of hard work.
It would be friendly by the developers to inform the users about that.

I am not sure what exactly you mean. This is an open source project and we have no time schedule for new releases and we don’t have a set list of features to add or bugs to resolve. We simply do what we can and like.

It’s quite bizarre to state that FOG development stopped… totally wrong!

@Wirefall Great you posted the full kernel messages listing. At first I didn’t notice any issue but looking closer I found the issue:

igb: probe of 0000:01:00.0 failed with error -2

The PCI ID perfectly matches the one you mentioned in your fist post. Didn’t take long to find several reports on this issue that came in just lately:
https://lkml.org/lkml/2016/11/24/172
https://bugzilla.suse.com/show_bug.cgi?id=1009911
https://patchwork.ozlabs.org/patch/700615/

Some say that it might possibly work if you disable PXE boot for this NIC in BIOS. I don’t think this is a great solution as FOG heavily relies on PXE booting the clients. Let’s hope that this will be fixed in the latest kernel fairly soon!

We are working towards a most stable release of the 1.5.x line of FOG and will publish release candidates of FOG 1.5.9 for this over the next weeks. We ask people to participate and help test to get the final release as good as we can.

https://news.fogproject.org/fog-1-5-9-rc2-available/

@sudburr Why not re-install the whole system from scratch?

@qpassa Ok, from what I see the DHCP config matches the IP setup and I can’t find any typo in there. Even tested the config posted on a test VM.

Maybe there is an interface linked in another config. Please run grep INTERFACE /etc/default/isc-dhcp-server and post output here.

Other than that you might also run the following commands and post output here:

systemctl restart isc-dhcp-server
journalctl -u isc-dhcp-server

On the last command you want to hit Shift-g to jump to the bottom of the log. Then copy and paste what you see. Then hit ‘Q’ to exit journalctl.

@dashwell said:

I’m attaching an image of the PCI ID’s.

Ok, NIC is 8086:15FC - haha, searching the forums I just found that we already had someone with HP ProBook 640 G8 complaining about slow speed and there are two fixes available for this issue:

1. Plug in a random USB storage device (not kidding!)
2. Enable “Storage Controller for VMD” under “System Settings” menu in the UEFI settings

Find all the details here: https://forums.fogproject.org/topic/15132/hp-probook-640-g8-imaging-extremely-slowly

@qpassa What output do you get from this command: ip a s

Please post output here.

@qpassa Run systemctl status isc-dhcp-server and post the full output here.

@exworker9to5 said in Perform Full Host Registration and Inventory - Failed:

Which Version of Linux is better for FOG? Centos, Ubuntu, or Debian?

They all work fine. It’s more a question of personal preference.

@exworker9to5 This error is specific to the hardware you try to register. Please try other machines. I am sure you won’t see the same issue.

You can either register this type of machines manually through the FOG web UI and add noapic as Host Kernel Arguments in the host’s settings.

Or you can add noapic as global kernel parameter via FOG Configuration -> FOG Settings -> General Settings -> KERNEL ARGS. Just save the settings and try registering this machine again.

Be aware that setting this as a global kernel parameter will use it for each and every host you register/capture/deploy. There might be drawbacks with other kinds of machines using it. That’s why I suggested you manually register/add the machine via the FOG web UI and adding the kernel parameter just for that single host.

@dashwell It’s very strange we don’t have anyone else in the forums report this obvious NFS error with newer kernels (5.10.x have been around for months now). Searching the web I can’t find a clear sign on what might be causing this either.

From what we have now I would think it’s a bug in the Linux kernel network driver. But first let’s make sure we are not racing down the wrong road! Please answer the following questions:

1. What is you FOG server running on? Directly on hardware or as VM (which hypervisor and what version?) or even as a container (docker, Proxmox, …)?
2. Can you deploy images to other machines (other than HP 650) without any issue?
3. Are FOG server and the HP 650 laptop on the same subnet?
4. What PCI IDs does the HP 650’s NIC have? Boot up one of the HP 650 laptops to Windows, open the device manager control and check the IDs in the NIC properties dialog (see this picture).

@fog_newb said in Error capturing Other - All disks all partitions using 1.5.9.110 and NVMe inits:

I backed up my hackintosh no problem on the 28th, just 3 days ago and was using whichever the latest dev branch was and the NVMe inits found here. https://fogproject.org/inits/init-disk-size.xz

The change we made for Host Primary Disk setting in init-disk-size.xz is in the latest dev-branch init already, plus some more changes an fixes. So using the old init-disk-size.xz is making a step backwards.

When it starts to capture the mac OS drive I get a bitmap error and am told to check var/logs/partclone.log but it is not there.

The mentioned log is only found on the machine in a debug session. So schedule another capture task but this time mark the checkbox for Debug, let the machine PXE boot till you get to the command shell. Now start the task with the command fog and step through the process. After you hit the error you get back to the command shell. Now you can inspect the log file: less /var/log/partclone.log

Take a picture of the error in the log and post that here.

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

sed -i -e 's/dnf check-update/dnf -y check-update/g' /path/to/fogproject/lib/redhat/config.

Not sure if you saw that I edited my initial post. That sed command should take care of the issue that is causing master to fail. Find the related commit that fixed the issue in dev-branch here: https://github.com/FOGProject/fogproject/commit/90caf2367d21d0594b7f16b2813a2fa94684ad78

@wkratky said in FOG Update IPXE Issues:

Yeah still no joy. I am about to the end of my rope.

Please tell us which commands you used? It’s pretty hard to read between the lines.

I just did a test install using dev-branch. It did not fail on “Downloading kernel, init and fog-client binaries”!

I could imagine old binaries still being in the fogproject tmp folder. So go to fogproject/tmp/ (or fogproject-1.5.9/tmp/ in your case) and delete all the files from that subfolder. Then re-run the FOG installer.