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/

@george1421 said in Error deploying an existing image to SSD drive:

If you look on the fog server in /images/aiov910 directory does d1.mbr exist?

Just to add a little bit here as some of the information is being exchanged in chat as well… The d1.mbr file is there. But from what I see so far it doesn’t seem to be an issue of disk being too small. Why am I saying this? Let’s do the calculations: ( 498069504 + 2048000 ) (nvme0n1p4 start + size is also roughly the value of last-lba in the header) * 512 (byte sector size) / 1024 / 1024 / 1024 = 238.5 GB -> I can’t imagine this image being taken from a 500 GB or 1 TB disk. While you can have the partitions not filling the disk we wouldn’t see the a similar last-lba value with the disk being much larger. The source disk being 4k sector size is possible but very little likely because of first-lba being 34 and nvme0n1p1 starting at 2048.

@Jim-Holcomb So then let’s see why it actually fails on nvme0n1 as well. Please schedule another debug deploy task, step through it till you hit the error and then manually run the printed command: sgdisk -gl /images/aiov019/d1.mbr /dev/nvme0n1 -> Take a picture of the messages on screen and post here!

@Jamaal What’s your actual aim when you consider adding another storage node? Sometimes the concept of this is being misunderstood and so it’s better to talk about this before you head into it. As well I may ask you what your FOG setup looks like as of now? Installed Linux directly on hardware or in a VM?

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