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.

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

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

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

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

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:

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

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

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

@3mu said in Wiki errors - "Troubleshooting a multicast":

ps only gives:

[username]     18913  0.0  0.0  13136  1092 pts/0    S+   01:39   0:00 grep --color=auto udp-send

On first sight I would guess that it tries to start udp-sender but fails due to it not finding the interface dev and will quit.

@c70m83 Just to try and see why exactly those three (PC24, PC08 and PC12) seem problematic you might try to connect those to other ports on the switch where you know that other PCs work.

As George said, PXE boot does not depend on Windows or any operating system. No matter what you have installed on disk PXE does work!! So if it used to work then something within your network / DHCP setup changed!

@robo Could you possibly provide the SQL dump so I can test? Please upload to a file share and send me a private message with the link.

@anon01013 Possibly the VirtualBox VM is set to UEFI but pfSense might not provide PXE boot information for UEFI clients?

Note for everyone: As far as I see in the picture this output we see here from iPXE is NOT the one delivered from the FOG server but the one build into VirtualBox.

@mckay said in Repurpose the restart notification to work for running/delaying Snapins:

Is this documented anywhere?

Sorry no. Not because we want to keep this secret but because we don’t have enough time to document it all.

I will try to give some answers on the options but as I haven’t been the author of that code I might not know all the details either.

The parameters are given as JSON string. So action is the name of one parameter and request it’s value. As far as I understand the code this parameter is not used in this case. I just used it in the example because it’s used in the fog-client code like this as well. Testing a bit more I found that you can run it without that parameter: {"period": 60, "options": 2, "aggregatedDelayTime": 0, "message": "This is a test message."} (encoded: eyJwZXJpb2QiOiA2MCwgIm9wdGlvbnMiOiAyLCAiYWdncmVnYXRlZERlbGF5VGltZSI6IDAsICJtZXNzYWdlIjogIlRoaXMgaXMgYSB0ZXN0IG1lc3NhZ2UuIn0=)

Now with the options parameter you can switch the button label (see code here). It will show “Hide” when you set options to the value of 2 or 0 but “Cancel” when set to 1. Please don’t ask me why. It’s just the way it was coded and I can’t tell you why.

As mentioned before I have that feeling that might not get what you want to achieve using FOGShutdownGUI. I am not even sure if it’s worth investigating any further. Probably better to look forward to working-1.6 instead.

@JYost said in Fog 1.5.5 to 1.5.8 - Creating SSL Certificate - FAILED:

Creating SSL Certificate …FAILED

Please check the installer error log (/root/fogproject/bin/error_logs/) and post it here. Probably the last 15 lines will do. Don’t need the whole lot.

@3mu Thanks, updated the wiki.

@mckay If you get stuck at some point you can ask here and we should be able to help.

@robo Which commands did you use to ex- and import the database? We can’t help you without knowing what exactly you did.

@lebrun78 I just had an idea. Maybe this is caused by a problematic entry in the DHCP leases cache file?? Take a look at /var/lib/dhcpd/dhcpd.leases. Not really sure what we are looking for but you might search that file for pattern 148.60.10. to see what leases are in the store. If you find something concerning than I would stop dhcp service for a second, make a backup copy of that file, edit and remove the problematic entry and start dhcp service up again.

As you seem to have a lot if fixed addresses defined you might not even care much about the leases. In that case you could even clear the whole leases file (stop dhcp before) and see if it makes a difference.