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.

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

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

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

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

@64bitfury Eventuelly found the time to proceed on the wiki article. Find information on your question here: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

Please let us know if the instructions are clear (and do work)! We can only improve things as much as we get feedback from users. :-)

@Silv4n Ok, unfortunately not of much help yet. Please recompile but leave out the tls, in DEBUG parameter…

make EMBED=ipxescript DEBUG=x509,validator bin/undionly.kpxe CERT=/opt/fog/snapins/ssl/CA/.fogCA.pem TRUST=/opt/fog/snapins/ssl/CA/.fogCA.pem
cp bin/undionly.kpxe /tftpboot

@Silv4n Let’s switch over to chat (chat bubble in the top right corner).

@Silv4n This is really strange. All the certificates seem perfectly fine and match the fingerprints we see in the picture you posted initially. I just did a fresh clean install here and it worked out of the box. Though this is a master server only. Let me try adding a storage node and see if that makes a difference.

@Silv4n And here is one more command:

echo -n | openssl s_client -CAfile /var/www/html/fog/management/other/ca.cert.pem -connect 10.144.1.22:443 | openssl x509  -noout -fingerprint

@Silv4n Still all good. We shall find it soon I am sure. Try these commands:

openssl x509 -noout -fingerprint -sha1 -in /var/www/html/fog/management/other/ssl/srvpublic.crt
echo -n | openssl s_client -CAfile /var/www/html/fog/management/other/ca.cert.pem -connect 10.144.1.22:443 | head

@Magiq Well if RAW works then you might try non-resizable image type as well. Suppose you have used resizable from the beginning?

We have another report on this: https://forums.fogproject.org/topic/14249/image-size-of-the-client-in-fog-does-not-match-the-size-of-the-capture-in-hard-drive

@Ben-Acheff Still waiting for you to provide the contents of d1.minimum.partitions from your image.

@rmishra1004 Thanks for reporting. We have another user but I wasn’t able to replicate the issue yet and didn’t get the information needed to find what is causing this. Cross linking the topics so we keep track of this: https://forums.fogproject.org/topic/14160/image-size-on-client-incorrect

Can you please post the contents of the text file d1.minimum.partitions here in the forums. You find that on your FOG server in /images/Win10LTS/ folder.

@Silv4n All looks fine up to here. Can you please run ls -al /tftpboot/ and post output here. From the log output we see the installer ran at Feb 21 around 11 o’clock. Just want to see if the iPXE binaries have the same timestamp.

As well I forgot one openssl command you shall run to see if the SHA1 fingerprint of the CA cert on the server matches the one we see in the picture:

openssl x509 -noout -fingerprint -sha1 -in /opt/fog/snapins/ssl/CA/.fogCA.pem
openssl x509 -noout -fingerprint -sha1 -in /var/www/html/fog/management/other/ca.cert.pem