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.

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/

@kyokushin Please schedule a debug task and boot the machine again. Then when you get to the shell run the following commands:

ip a s
dhclient -v -r enp0s1
ip a s

@cyrmoon said in NBP file downloaded succesfully:

I tried to change for a older kernel in fog but nothing at all.

This issues seems to be caused by iPXE not the Linux kernel we use in FOS to do the actual imaging.

Is there a solution or it will be fixed in next versions?

FOG is open source and so we rely on people like you to test things and let us know what works and what not. We don’t have all the hardware to test on our own.

So let’s get into this and see what is actually causing the failure after “NBP file downloaded succesfully”. Before you updated from 1.5.7 did you see the FOG boot menu after the “NBP file downloaded succesfully”? I just want to make sure we hunt down the right path. I am asking because you can setup FOG to hide the menu and just run a default menu item. If that is the case we’d need to look further than iPXE…

Here is the code tree of FOG 1.5.7 iPXE binaries. Just download the iPXE binary that you are using in you DHCP server and put that in /tftpboot directory on your FOG server. See if the fujitsu esprimo g558 works correctly again.

Now I see, this is just a copy&paste from an old topic… https://forums.fogproject.org/topic/988/fog_disable_chkdsk-setting

@Bienxanh Why do you waste our time I wonder?

@Bienxanh said:

Seems like the “FOG_DISABLE_CHKDSK” setting in .32 is not set correctly…

Do you really mean FOG 0.32 or is this a joke? That version is roughly a decade old and we surely can’t backport any fixes to such an old version.

@brakcounty Over all the details about GRUB I lost sight on what this topic is all about… The USB method uses GRUB as boot loader because it can be installed into MBR on the USB to be used to boot legacy machines. As I said before, the alternative USB boot method is not part of the official FOG stuff and has not had enough attention to be fully integrated yet. Not because it’s impossible to do but because we have way to many things on the list.

Now that you use UEFI only in your setup you could skip GRUB altogether and directly boot using iPXE from the hard drive’s UEFI boot partition and should be able to use FOG exactly the way you would if it does PXE boot. For that you just grab one of the iPXE .efi binaries from your FOG server (e.g. /tftpboot/ipxe.efi) and but that on your disk’s EFI boot partition as \BOOT\EFI\BOOTX64.EFI (case doesn’t matter here as Windows will ignor it). When booting the iPXE binary will run its embedded script to get an IP from DHCP and chainload to the FOG boot menu.

@jmvela2x Thanks very much for sticking with us on this and doing the tests!

@brakcounty Don’t think there is a GPT partition layout on any of those three disks. While hd2 doesn’t even seem to have partitions at all. Maybe this is the USB key? Can you boot to Windows and post a picture of the disk management view? Shall see if it’s MBR or GPT there.

@Jamaal From the error message I would imagine that this last call is failing because an earlier query also failed and variables are not being set correctly because of the earlier error. So you need to post the full error you see!

I am not a PowerShell wiz but from what I know the read-host stuff you added should work.

@brakcounty Sorry, just updated my post again.

The windows partition I’m trying to boot from is a GPT-EFI bootable system.

On the GRUB command line run the following commands, take a picture of the screen and post that here:

set pager=1
insmod part_gpt
insmod part_msdos
ls

Is that “+1” always supposed to follow the chainloader entry?

Yes, as far as I know.

@brakcounty said in Boot FOG on client PC using a special partition?:

The ls command shows hd0 hd0,msdos hd1 hd1,msdos, hd2 hd2, msdos.

Well then you have a legacy MSDOS partition layout and can’t use the GPT stuff! Have you tried the good old MBR chainloader style yet?

     insmod part_msdos
     insmod chain
     rootnoverify (hd0,0)
     chainloader +1

Play with the numbers (at line rootnoverify) till you hit the right partition/disk.