Best posts made by Sebastian Roth

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/

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

@Developers @Moderators Ok, I just opened a pull request to remove the 7156 binaries. Please all keep that in mind. Might cause some minor confusion in the next weeks. But it’s good to get rid of it.

As you all can see the tests of the most recent iPXE version shows that things are back to normal again. I reported back to Michael Brown on the iPXE devel mailing list. So he’s got that in mind as well.

@Avaryan To me this sounds like a different issue. Would you mind opening a new thread on this and posting more details (FOG version, USB ID of the NIC used as shown with lsusb, …).

I’ll mark this solved/closed now. @Psycholiquid Thanks heaps for the great work on testing all the binaries and such!

@Jean-Jacques-Morda Why do you have more than one DHCP server in your network? And why do they offer different information (next-server/option 66) to the clients. This is not strange but kind of expected and it just does not make any sense to me why you would want to have this.

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-rc1-available/

@fakeblair The messages about NBP file(name) look like UEFI boot being enabled I reckon. If this is the case you need to use an EFI PXE binary (usually ipxe.efi) instead of the BIOS binary undionly.kpxe!!

Trying to get all the pros and cons of changing the current setup of using fog linux user account as we have it at the moment.

As we answer many questions just because people keep using the account and change the password I wonder what can be done to prevent from that.

@george1421 @Wayne-Workman Just moved your other posts here so we have it together in one place and not fill up the users request on how to fix his issue. Open for discussion.

@bacelo said:

ok so I checked that everything is correct with the DHCP server as it should be configed as it shows in the wiki page for Cicso…

I am not getting this. Which DHCP server config did you check? 10.1.8.1 (not being used by the client as you can see in the DHCP timeout) or 10.1.8.254 (again, what system is this? Do you have access to this device?)… What wiki are we talking about FOG wiki or Cisco wiki? URL?

We need more information to be able to help you.

@tom-elliott said in OS Support - the numbers are in:

I’m of the belief we keep centos/rhel support.
You’re right that many may not be using CentOS anymore, but I still believe it’s far more stable than even ubuntu/debian. People Seem to be using it because it is supported, but please don’t forget all the changes we have to make to our installation scripts each new release of Ubuntu/Debian.
Compared to RHEL, we rarely need to make any major adjustments it seems in my experience.
Plus, the installer seems to work for Rocky/Alma, because these are following with RHEL as well. Removing the one installation portion that seems to actually just work with limited intervention seems like a bad move. Plus it still allows the administrators to use different variants of linux.
Limiting specifically to Ubuntu/Debian would leave all of that out. Now, of course, the scripts could be cleaned up and should be, but I’m not kidding about each new Debian/Ubuntu release still has so many new issues that we still need to make up for.

I fully consent to what Tom wrote.

RHEL/CentOS/Alma/Rocky all work the same in terms of the FOG installer scripts and are much less labor-intensive than Ubuntu/Debian.

Off topic: We have started to migrate all our CentOS 8 servers at work over to Alma and it works great! Not much trouble migrating fully installed and configured server systems. Same should apply when moving to Rocky as they provide the same sort of migration scripts.

@bacelo said:

Ok I am going to format the linux and install it all over again.

But this won’t actually make PXE work for you. You need to get in contact with whoever is in charge for 10.1.8.254 and hopefully he’s willing to add options 66 and 67 for you.

@Dark000 Updating your FOG server to the latest (release candidate) version will make it work!