@fogger1 The links that are provided are the init’s in the most current state we have. The good thing is now that the init’s are separated from the main elements of FOG, and changes aren’t quite as frequent as the main elements, the init’s being provided should work with any 1.5.x version of FOG and even the 1.6 as the backend “functional” pieces aren’t being modified at the same scale between the two versions. So they’re not provided for 1.5.4, they’re whatever the most current version is. The init’s are not labelled in the same fashion as our normal releases which is why it’s important for the distinction here. The init’s in the links are what are provided for 1.5.5 and 1.5.5.2 (which is the most current dev-branch version).

@Junkhacker Thanks for your assistance

@mary-montesanto said in ERROR #16 IRQPOLL:

@george1421

advice to update the Lenovo Bios? What is the client PC?

Sorry I don’t understand the question. What I’m suggesting is to update the pc bios on the lenovo computers, or at least check the installed version vs what is current from the Lenovo web site.

I know this is an old topic, just wanted to reiterate that this fixed my problem. The weird thing is that this wasn’t a problem until today. Been using Fog with the same laptops, same basic install of Windows 10 for around 1.5 years now, and today was the first time I saw this error. Went and turned off fast boot and it works great. Yay for forum search functions. 😉

Philip

@BSZAdmin hello, I have the same issue, can you please help me? How did you fix it?

@chanstag A proper dhcp/pxe boot process should be this.

PXE client - Discover DHCP Server - Offer PXE client - Request DHCP Server - ACK.

That second pcap is discover, offer 1, offer 2, discover. Meaning that the pxe client didn’t get what it needed to even get an IP address.

So a couple things I’ve gleaned from looking at the pcap.

If your dhcp server is running on your router, its not responding to the dhcp discover from the pxe booting computer. You have a non-fog created dhcp server running on the fog server. Its responding with an IP address but its not sending the boot file or next server information. The FOG created dhcp server will send the proper boot information. You have dnsmasq installed on the FOG server, and it IS responding correctly. But because there is a dhcp server also running at the same IP address the target computer is getting confused and taking the dhcp offer and not the proxy dhcp offer. Your target pxe booting computer is a uefi type BC (00007). Not really important, but dnsmasq should be sending ipxe.efi to the target computer so it can boot.

@seniorvodka There seems to be no image defined for the host…

Yes they are assigned

ftp_proxy=http://10.andsoon.:1234
same with http and https
and
noproxy=10.fog_ip

@jgiovann Great you figured this is a spanning treee thing! Seems like I was to focused on the issue might be routing problems that I didn’t notice the message udhcpc: no lease, failing.

In a real production network (where turning off spanning tree is not be allowed), is it therefore possible to re-configure the FOG server to wait longer or retry more times before it gives up the registration retry loop ?

The problem cannot be solved in the registration retry loop I think but we’d need to tell the dhcp client to wait longer. But from my point of view you should be able to solve this by setting the client ports to “port fast”. There er different names for this but what it essentially does is disable spanning tree for particular ports where you surely know there are no other switches connected but only clients. On those ports you never ever need spanning tree because single clients connected to a port can never cause a loop (which spanning tree was invented to prevent from)!

@gfontenot You didn’t happen to mention what version you were upgrading from. But in my simple mind, I would just copy the raw image files from the old FOG server to the new FOG server making sure the directory permissions and owner is set correctly on the copied files. Then from the webgui, export the image definitions into a csv file, and then import them into your new fog server. You will need to reregister all of your hosts again, but then you don’t get a bunch of legacy settings over to your new fog server. If that route doesn’t work, you can always import the DB like you did before.

@maouu Run getenforce and post output here…

Which server OS do you have?

For snapins you need to check the permissions of /opt/fog/snapins

@Paulo-Guedes Ahh, I just saw that a fix was actually added upstream in Juli this year: https://lkml.org/lkml/2018/7/23/671 (just didn’t notice it a little further down the code)

Can you confirm this is fixing your issue? Have you used one of the official FOG kernels since then? Which versions?

@pietroaretino Sorry for the late reply. We’ve lost track of this issue. Let’s see if we can work this out for you.

I’m just trying to upload a zip file of MS-Office 2016 install.

I am wondering if it’s just file size issue? I have just installed FOG 1.5.5.3 on Debian an created a couple of SnapinPacks. First smaller ones than bigger ones. All working great up to 250 MB. So I can’t replicate the issue as you describe it.

Would you mind updating to FOG 1.5.5 or even the dev-branch (currently 1.5.5.3) to see if you still see the issue? We’ve adjusted some of the php-fpm config values since then. So maybe this is fixed for you already.

Curl calls in themselves aren’t inherently insecure to my knowledge, they can be without validated input like you said. I just go with the practice of turning features off for securities sake rather than leaving it all on and running on default settings unless something we use needs to use it in which case I don’t mind turning it on unless there’s a huge security risk attached.

TL;DR I just try to keep my systems locked down until areas need to be enabled for programs, instead of leaving everything default.

@astrugatch said in Active Directory after image deployment not working.:

If I am installing FOG for the first time (as opposed to upgrading) and I enter the DNS name as part of the new installer and having the CA generate a cert with the DNS/hostname does HTTPS become the default.

Ahh, now I get you. No haven’t changed the default to be HTTPS as it would involve compiling the iPXE binaries as well. Think that is the next step. I will consider removing the iPXE binaries from the repo and simply rely on compiling them on each install altogether. iPXE code is usually fairly stable. What do you think @Tom-Elliott ?

@Sebastian-Roth Thanks! That saves a lot of space so I can upgrade from 1.5.4.

@Abuelika Not need to say sorry or even delete the post. It’s perfectly fine to ask and I think it’s great to have this here in the forums so others might find it and can help themselves as well.

@svalding Did you ever get this solved? rEFInd 0.11.4 is out and you might give it a try.

@george1421
Finally, I did the decrypter 😛
Thanks for the code!