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

Hi there,
this Problem allready existed in this forum and has been signed solved, as the threadstarter resigned and used the EXIT-way in Fog
(https://forums.fogproject.org/topic/16762/local-grub-booting-fails-from-fog-menu-pxe-uefi/7)

For me the problem persisted, as I need the features in refind for dualbooting the systems.

Meanwhile I tried some more scenarios.
My PC’s have 2 OS’s : Windows 10 and Ubuntu

With Ubuntu 20.04 everything was fine untill one Update (still have the Image) and all version from there on show the the Kernel panic.

I tried several configs in initramfs - different compressions, I thought it is a bug

I think I followed all descriptions from all experts in the net for this Error.

But the system (as you allready know) boots fine, when booted directly

So I start to ask myself - what is the difference?

refind and booting from the memory fog-pxe presents.

is it possible, the compression gots worse?
that for some reason the initramfs gots bigger
is there a way to reduce the initramfs filesize

It is a pitty ther is not enough logging

@ITRecords Have been pretty busy with other things and forgot about this topic. Whoops.

Ok, so we have a plain disk drive here (sure virtual disk but no LVM or fake-RAID) which makes it pretty easy.

Make sure there is no FOG task (deploy or capture) running! Stop NFS daemon: systemctl stop nfs-kernel-server Unmount the partition: umount /dev/sdb1 Install an easy tool for expanding the patition: apt install cloud-guest-utils Test expanding the partition: growpart -N -v /dev/sdb 1 (note the space before the partition number) Expand partition: growpart -v /dev/sdb 1 (note the space before the partition number) Expand filesystem in partition: resize2fs /dev/sdb1 (no space before partition number) Mount partition: mount /dev/sdb1 /images Start NFS: systemctl start nfs-kernel-server

@hammerc807 For me github.com resolves to a totally different subnet. Could either be fine or a pointer to your provider doing transparent proxying?!

Try openssl s_client -showcerts -connect github.com:443 -server github.com to show the whole certificate chain.