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/

After a certainly too long period since the last release we finally announce the new FOG 1.5.10:

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

Thank you very much to everyone devoting time to help getting this ready!!!

Find all the details in the new release notes…

This version was re-released (re-tagged) on 31st of March 2023 to patch issues with the location plugin that would cause trouble when updating from an earlier version.

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

@jmeyer said in Update to last dev (1.6.0-alpha.1182):

Updating Database

Usually that’s the part where you need to open the web browser and let it update the database schema. Did you do that?

Do you run the installer with command line options or just plain?

@brakcounty A 6.1.22 test kernel is available on Github. Be aware those kernels are untested so far. I dod not have the time to even do the simplest bootup test.

@Fog_Newb Here you go: https://github.com/FOGProject/fos/releases/tag/20230331

Be aware those kernels are untested so far. I dod not have the time to even do the simplest bootup test.

FOG 1.5.10 was kind of re-released (technically just re-tagged on Github) just now to patch issues causing trouble when updating from an earlier version with the location plugin enabled.

@george1421 All those binaries are shipped with FOG and installed by default - see the list of ipxe binaries on github.

It’s more or less a question on which binary we make the default when generating the dhcpd.conf - which obviously not everyone is using anyway.

@Sebastian-Roth said in Which pxe file to use:

Should be update the default dhcpd.conf generated by the FOG installer as well?

@george1421 What do you think?

@dimoura At the risk of repeating myself, someone needs to make a commitment to maintain the docker image. This is not going to happen if everyone keeps asking for others to do it.

@jblomquist said in Is there a way to restrict FOG menu access to specific users?:

I’d like to allow a particular user to be able to deploy an image, but not quick delete a host through the PXE menu.

Which version of FOG do you use?

The quick delete option is secured in the iPXE menu in FOG 1.5.10 (github commit).

@AlexPDX said:

i see u did not find the time to fix the M.2 NVMe problem …and the Storage Nodes being Unauthorized

No, we haven’t yet. You are very welcome to get involved and help fix this stuff.

@brakcounty said in Very slow imaging performance on XCP-NG guest vm:

Are you referring to the bzImage kernel version? If so the kernel version I’m on is 5.15.93.

Yes. Just a hint: You can find out the version of kernel binaries by running file /var/www/html/fog/service/ipxe/bzImage* (or using whatever kernel filename you want to know the version).

We are planing to bring out a fresh new 6.1.x kernel for testing in the next week. Keep an eye on https://github.com/FOGProject/fos/releases for it to come out.

No idea if that newer kernel version will solve the described issue but it’s worth a try.