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

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

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

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/

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

@george1421 While I like the idea of not having to embed the grub.cfg file into the binary - for users’ convenience to be able to edit the file - I would like to have the grub modules within the actual binary (its memdisk). It’s just my guts saying this might be more reliable if modules don’t need to be loaded separately.

@wmw509 Would be interesting to see If it reports a different platform if your pfSense also hands out the UEFI binaries as mentioned by George!

There are two more things coming to my mind. First I am wondering if there is some confusion about the wording. Host can mean different things but in the FOG world it’s used for the Client machines that PXE boot for deploymens. So I am wondering if your Ubuntu server system is your FOG server or really one of the PXE booting systems.

Second I may ask you to schedule a debug deploy task. Same as If you create a normal task but Just before you click the create button in the FOG web UI there is a checkbox for debug mode. Now PXE boot the machine in question and wait for it to give you a Linux shell. Run the ls -al /sys/firmware/efi command in there and report what it looks like.

@x23piracy said in First default domain admin login never ends when FOG (1.5.0) joins to domain (FOG Client 0.11.15):

Is it possible that this has something to do how the older FOG Client technically joins into domain or what could be the reason here?

That’s a really good question. Though I can’t give you a clear answer. There have been changes in how the fog-client attempts to join a domain but all of these code changes were before 0.11.15 was released in February 2018. Usually I tell people to update to the latest version of FOG/fog-client and try again but I suppose this is of not much help here.

You might want to study that code on github and try some search engine foo to get an idea if there are other methods to join a domain. Though it would take a lot to convince me to use a different method which has not gone through any testing yet.

When i deploy the image without letting FOG join the device to the domain i can logon the default domain administrator without any problem.

I suppose this implies manually joining the domain, right?

@Tom-Elliott said in Fog V1.5.9.29 Active Directory Defaults for OU not populating Database:

but in the edit the option is selected from the list and that applies it properly.

Do you mean when selecting it from the drop down manually or when clicking “Join Domain after deploy” to apply the default values?

@wmw509 said in Cannot exit IPXE menu and boot from hard drive?:

If I leave the non-efi boot exit setting as SANBOOT for example, no matter what my efi boot exit setting are the host will always end up hanging with a blinking cursor in the top corner. Is it possible Fog (or my settings of Fog/the host) are causing some confusion as to what method to use?

That’s interesting. We rely on iPXE determining the correct mode be it UEFI or legacy BIOS and query its platform config parameter.

To check which platform it sees on your systems you could quickly edit /tftpboot/default.ipxe and make the script look like this:

#!ipxe
show platform

Make a backup copy of the original file so you can switch forth and back quickly.

@george1421 Definitely a good point to discuss and re-think. The binary we use so far essentially is not plain GRUB but GRUB4DOS 0.4.4 - it’s from 2009 (!) but hey, there really is no later version available.

http://web.archive.org/web/20160406111907/http://diddy.boot-land.net/grub4dos/files/intro.htm

Unlike GNU GRUB, which relies on several Stage files, the Grub4dos functions are built into a single file grldr (or grub.exe if booting from DOS or Linux). grldr can be loaded via an existing operating system - e.g. via the NT loader ntldr during the Windows NT/2000/XP boot process. Alternatively grub4dos code can be written to the mbr or partition boot sector of a device.

I guess it was chosen years ago as one alternative to chainload 32 bit legacy BIOS systems as it is very flexible in its capabilities to load different operating systems from your hard disk.

We chainload GRUB4DOS from iPXE and feed it command line options to try to find and load an OS from disk.

As far as I know there is no GRUB4DOS capable to be loaded on UEFI based systems and so question is, what else can we use to chainload an OS from a hard drive on machined in UEFI mode?

Reading a bit on the web I reckon it’s possible to create GRUB2 binaries to be chainloaded from iPXE and I think I have played with grub-mkstandalone.

A quick test let me build a binary running this command on a Debian 10 UEFI install system: grub-mkstandalone --format=x86_64-efi --output=grub_x64.efi --install-modules="linux normal iso9660 memdisk search part_gpt part_msdos" --modules="linux normal iso9660 search part_gpt part_msdos" --locales="" --fonts="" --themes="" "boot/grub/grub.cfg" -v (derived from 1, 2 and 3)

For building binaries for the other platforms/modes you’d need to install Debian packages grub-efi-ia32-bin and grub-pc-bin…

@george1421 @Goll420 I have worked on the multicast tasking/finishing code just before the release of FOG 1.5.9 because there were issues when you schedule a test not via the group but by creating a named multicast session. I thought I had this all tested and working correctly but I might be wrong. I will need to get a test setup ready and see if I can replicate the issue as described.

@Tom-Elliott From what I see in the video @Greg-Plamondon is using a list of default OUs separated by | character in the FOG settings. This way you get a drop down list in the host’s AD settings tab. By the looks of things the JavaScript used to fill in the default values as well as the code to clear the fields is not able to handle a drop down list properly. It’s only able to handle a simple text field and works perfectly fine if you only use one single default OU in the FOG settings.

I think this would need a lot more JS magic to work. I am not that good with JavaScript, would you look into this Tom?

@wmw509 The refind.efi file is an older version (0.9.4). Tom added this a while ago as this seemed to be kind of a stable version. I have to say that I am not sure this one really is version 0.9.4 or perhaps a different one. You’d use that one by renaming the file. FOG serves refind_x64.efi to 64 bit architecture and refind_ia32.efi for 32 bit.

Unfortunately there does not seem to be a general solution to this. People report that version xxx of rEFInd doesn’t work with their hardware while others have no problems and vice versa. So trying to provide binaries that suit every case is probably not possible. You can download older versions and try out which one works best for you.

@Tacolover99 said in New to this:

Which I wanted but I notice that the internet was limited connected. So CMD, and found out the Thin Clint also inherited the IP Address from the other thin client. Check the original one and now that thin client is doing the same thing. Not to sure if it is DHCP problem when I cloned it.

I think you need to explain this part in more depth. Probably best if you can post some pictures so we know what you mean by “limited connected”, “inherited the IP Address”, “doing the same thing”.