@Thierry-carlotti said in iPxe boot fails : Coud not boot :Permission denied (https://ipxe.org/0216eb8f):

iPxe boot fails : Coud not boot :Permission denied (https://ipxe.org/0216eb8f)

This really sounds like secure boot is enabled keeping ipxe from loading/running.

@45lightrain Lets cover a few things that I’m aware of that might help you get to the bottom of the issue.

When you have a ProxyDHCP server and normal dhcp server on your network you will get two dhcp OFFERS. Well I guess it would be the same if you had two dhcp server you would see two offers, but that is a bit off point. You can tell if an OFFER packet is a proxy dhcp packet because dhcp option 60 will be set to PXEClient in the ProxyDHCP OFFER. That is a signal to the pxe booting client to come back and ask about pxe booting from the ProxyDHCP server. The pxe booting client will ignore the pxe boot information from the main dhcp server. A properly formed dhcp packet will have both the fields in the header {next-server} and {boot-file} filled out for the bootp booting protocol part of the protocol AND should have dhcp option 66 and 67 set for the dhcp booting protocol. Both must be filled out because its up to the pxe booting client to pick either the dhcp or bootp protocol. Your ltsp files are correct. The last one you posted has the dhcp-range… commented out, that turns off the proxydhcp feature in dnsmasq.

SO if you have a pihole server that runs dnsmasq, why are you running an external dnsmasq server. Does your pihole server have pxe boot options? I know pfsense has built in pxe boot fields you can fill out that supports dynamic (bios/uefi) boot loaders.

When trying to debug this wireshark/tcpdump is your friend that tells you what is flying down the wire. Just remember that dhcp is based on broadcast messages so you can “hear” them from any network port, and proxyDHCP like other unicast messages must be captured at the source, destination, or via a mirrored port.

@Tom-Elliott I made a mistake – Our current FOG version is actually 1.5.9 but the php version is still 7.2.24. Would that change the possibilities of a PHP upgrade ?

@limbooface Is this still an issue? If not, I’ll close this issue.

@jfernandz
No.
I capture an image to the fog server and that works. I have several images on the server that we use. When we go to deploy an image we enable PXE boot save changes and go back into the BIOS. Using the Quick boot menu select the PXE boot on the NIC that is connected to the FOG server.

From here the PXE boots fine and I am able to select Quick deployment login using the username / password. Select any of the captured images. It will go through the whole deployment process with no errors posted. When it boots we normally go back into the BIOS and disable PXE boot. Save changes and restart. It will then post Reboot and Select proper Boot Device or Insert Boot Media in selected Boot device and press a key.

If I use clonezilla and restore an older image to the PC and then use FOG Server using the same steps to deploy it will then boot into the OS correctly.

@slawa-jad I don’t think grub_is_lockdown is the issue, just the message presented.

If you’re able to load up the original machine you captured the image from, look at your /etc/fstab file.

I suspect you’ll see something to the effect of:

UUID=a2476193-12cf-4601-a38d-6c798fc42708 /boot ext4 defaults 1 2 UUID=AACD-BEFE /boot/efi vfat umask=0077,shortname=winnt 0 2

If your file.

This is where things are breaking down.

Change the UUID= portion to the actual drive name.

The boot efi part, I’m not 100% certain what to change it to, but I would suspect probably

/dev/sda1 /boot ext4 defaults 1 2 /dev/sda2 /boot/efi vfat umask=0077,shortname=winnt 0 2

This is just my guess. I would not make these changes on the “originally captured” machine but rather make it on one of the machines that you deployed to and fix it there. Once it’s fixed, I’d then suggest re-capturing the image from that “now working” machine and deploy as freely as needed.

@matthewadams12 Why do you need the Fog Server to be offline?
Maybe there’s a solution where we can isolate just the part you want to isolate. i.e. if you are trying to remove internet access where images are stored you could setup a storage node and keep that offline after initial install. The storage node would also need packages and updates to fog, but you could capture them during updates on the main server and then sneakernet them to the storage node.

Storage nodes are just what I’m using as an example. If it’s not the images stored on the server you’re trying to isolate, then there could still be another solution. You could also firewall the server with your external firewall or the os firewall to only allow access to the fog github page for update downloads and then the repo sites that download the package updates?

Just thought I’d throw out some other possibilities.

@infotc

@infotc Hey! This worked. I actually did the same thing but slightly different - you can leave the line just do php-msqlnd* if it is already installed because it is actually php-mysqlnd-ms or php-mysqlnd-ms-all-dev.

Great find though as it really helped me get this installed.

Hi all

@thomGee said:

But if someone has an idea, I‘d be thankfull too!

We encountered exactly the same issue at my place of work. A colleague of mine found out that local boot works with GRUB Version 2.06-13 as supplied by Debian “bookworm”. We were able to insert those packages into our Ubuntu. So far, it works without issues. 🙂

Hope this helps
Hermann

Which process exactly causes this problem?
I had the same problem in the past, see here: https://forums.fogproject.org/topic/15031/fogtaskscheduler-causes-always-100-cpu-usage

@mardonis200 Looks like we have at least three different topics on this issue (links see below). As far as I get this an update to iPXE was causing this issue. You might want to try iPXE binaries from FOG 1.5.9. While this is not great it’s a start.

https://forums.fogproject.org/topic/16850/problem-after-deployment-with-release-1-5-10
https://forums.fogproject.org/topic/16859/rhel-initramfs-unpacking-failed-kernel-panic-not-syncing

@wntr said in FOG DHCP server not working:

What network settings do you need on Ubuntu regarding DHCP? Normally the IPv4 settings are set to DHCP in the Networkmanager GUI.

We suggest to use a static IP for your FOG server!

You can find out the IP the server had when FOG was installed by running the following command on your FOG server console: grep ipaddress /opt/fog/.fogsettings

@Manny-Both-Hanz Did you put the files needed for this onto your USB? /boot/ipxe.krn and /boot/ipxe.efi

Both errors mentioned sound like those files are either missing or might be corrupt.

@Gcostiou Ok if you solved the problem then its done. Just be aware that you can get fog installer to work through a proxy server if needed. By default the fog installer doesn’t know about the company firewall.

@kalafina now the host where vm located can’t access the web ui too.

@Redbob ok I think I know where its falling down but we need evidence and not an opinion.

Can you get a computer on the target’s network running wireshark? If yes create a pcap of the pxe booting process with this capture filter port 67 or port 68 This will only capture the dhcp process. What we are interested in is the dhcp OFFERS from one or more dhcp servers. In one of those OFFER packets is the bad actor that is sending your pxe booting into a loop. If you can’t figure it out who the bad actor is post the pcap here and I’ll look at it. The answer will be in the pcap. Use my capture filter so we only see the dhcp process and not other random traffic on your network.

@PRK08 The root cause of the issue is that you are currently running on an unsupported/old version of ubuntu [16.04] where some of the packages from the ubuntu repository are out of date or no longer supported. This is an issue with the ubuntu repo and not specifically with FOG.