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

@dejv changed php version as you instructed, redownloaded latest version, installed and is working ok thanks a lot 😉

@Numa09 Nice find, well done!

@mdxlp Let me tell you how I debug post install scripts. At the top of the post install script I insert an echo with something notable so you can quickly identify it. And then right after insert a debugPause; command.

Now schedule a deploy task to your target computer, but before you hit the schedule task button tick the debug checkbox. Now schedule the deployment task.

PXE boot the target computer and it should drop you to a linux command prompt after a few screens of text you need to clear with the enter key. This is debug mode.

To start the debugging process in single step mode key in fog and press enter.

{sidebar} If you want to remote debug your post install script get the current ip address of the target computer with ip a s and then set root’s password on the target computer with passwd. Set it to something simple like hello. Now you can connect to the target computer using ssh or putty from a remote computer. Key in fog to start the single step imaging process {/sidebar}

The deployment script will stop at each debugPause command. Keep pressing enter until you see your echo statement you put at the beginning of the post install script. At this time if you press ctrl-c you can exit the deployment script. This will give you a command shell with all of the proper environment variables you can inspect with the set command. Running the curl command from my previous post should produce all of the fog variables.

@kroepoek85 it’s work with ubuntu live server 22.04 and then in the user-data file you write packages: ubuntu-desktop.
It work well, i can autoinstall ubuntu desktop now with fog ipxe menu.