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:

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!

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

@george1421 @zyzhang I put in the download links for init and kernel in my last post.

@3mu Thanks for letting us know you solved this and DNS server was the issue. Can you please be more specific on how this conflicted and why?

Really sounds like other people could have run into this as well and would embrace your helpful information on this.

@abulhol Give it a go and post information here or on github to further discuss things. Or you might send in a pull request on the fos repo right away.

@icescout27 said in Image Capture Error: "Failed to open stream: Permission Denied":

When I elevate to root and run the command suggested I receive the following message

No. Looks like this is not a SElinux enabled server. Ubuntu uses another security framework called AppArmor but I don’t think this is causing the issue.

Run df -h as root and post output here.

Can you please tell us more about this FOG sever? Sounds like you haven’t set it up yourself but took it over from someone. Do you know when it properly captured an image last?

Just to check the basics: Is 192.168.1.1 the IP of your FOG server?

… FOG version 1.5.9 RC2

Ahhhhh, now I see. Something has gone wrong when updating from an earlier version. In the picture we see is state the username fog. This was used in earlier versions of FOG but not with the one you are using. Please login to the web UI, go to Storage settings, edit the “Default Storage” node and set the Management Username to fogproject. As well open a root command shell on your FOG server, edit file /opt/fog/.fogsettings and adjust the line starting with username=... accordingly.

@george1421 @zyzhang I would try using latest init and kernel. Hope switching to those is not causing other issues.

@Jeffson said in PXE-E78 some computers:

What I don’t really understand is why does it work for the same model of computer with the same BIOS settings etc and for some not…

Do those that work, reliably PXE boot every time? If you answer this with yes I am sure there must be a difference between those that work and those that don’t! Or it’s some specialty within your network setup (different subnets, VLANs or firewall settings).

• Double check the BIOS settings! Are they all in legacy BIOS mode or UEFI?
• Tell us more about your network architecture. Are the hosts all connected to the very same switch, same subnet??

@Hartman4820 said in fog capture stuck at starting cmain:

starting cmain

This message is only being displayed by GRUB chainloader as far as I know. What this means is that the host your are PXE booting is using GRUB to chainload the OS from your hard drive and therefore I am sure there is no task even scheduled for this host!

You are saying “I check the Tasks and it just stops the task.”. Can you please let us know how exactly you scheduled the task and if you get to see it in the tasks list at the very beginning?

Just started a new fog server.

Which version of FOG do you use?

@icescout27 What Linux OS is this? Any chance SELinux is/got enabled?

Run getenforce as root on the command shell and post output here.

@mkeane Using USB boot. Start looking into this here: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

@george1421 @zyzhang This issue might be fixed in a later init version when we added the flock calls.