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

@Sebastian-Roth
Last version of MINT (21.2) & FOG stable (1.5.10).
I will try another distribution.

@mardonis200 Whoops, was too quick to mark it solved. Would you please re-phrase the topic to reflect this as well.

I remember there was a topic in the forums on a similar issue. Just can’t find it right now. Try the forum search or your search engine of choice (e.g. using site:forums.fogproject.org as well).

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

@mardonis200 Please try other physical machines. As well increase the kernel log level to 7 in the FOG settings (web UI).

Hi, @Tom-Elliott

I understand your request.
I thought it was the number of times regarding the deployment

@george1421

I disabled the function in the power options the fast startup

during my deployment I added a set username and set password in the fog.deployimage.

Thanks

@dyacishyn Looks like I was wrong. The partition on the new disk does not have a filesystem on it as we see by the output of the file command. Do you remember if you missed the mkfs.ext4 /dev/sdb1 command?? I suggest you issue that command (again).

I won’t be liable for any loss of data. Formating a disk with a new filesystem will overwite whatever is on there now.

mv /images/.mntcheck /root mkfs.ext4 /dev/sdb1 mount /dev/sdb1 /images mv /root/.mntcheck /images

If this is all fine (no errors) you might just do another server reboot to make sure it’s all fine.

OK a bit more background here.

The scheduled tasks (cron style) are added to a table in the fog database. To automate the process a bit you will need to use the mysql cli commands to import the tasks into the table. If you are familiar with linux and mysql the activity is pretty easy.

The table layout is as such

MariaDB [fog]> describe scheduledTasks; +---------------+---------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------+---------------------+------+-----+---------+----------------+ | stID | int(11) | NO | PRI | NULL | auto_increment | | stName | varchar(240) | NO | | NULL | | | stDesc | longtext | NO | | NULL | | | stType | varchar(24) | NO | | NULL | | | stTaskTypeID | mediumint(9) | NO | | NULL | | | stMinute | varchar(240) | NO | | NULL | | | stHour | varchar(240) | NO | | NULL | | | stDOM | varchar(240) | NO | | NULL | | | stMonth | varchar(240) | NO | | NULL | | | stDOW | varchar(240) | NO | | NULL | | | stIsGroup | varchar(2) | NO | | 0 | | | stGroupHostID | int(11) | NO | | NULL | | | stImageID | int(11) | NO | | NULL | | | stShutDown | varchar(2) | NO | | NULL | | | stOther1 | varchar(240) | NO | | NULL | | | stOther2 | varchar(240) | NO | | NULL | | | stOther3 | varchar(240) | NO | | NULL | | | stOther4 | varchar(240) | NO | | NULL | | | stOther5 | varchar(240) | NO | | NULL | | | stDateTime | bigint(20) unsigned | NO | | 0 | | | stActive | varchar(2) | NO | | 1 | | +---------------+---------------------+------+-----+---------+----------------+ 21 rows in set (0.001 sec)

Here is a scheduled task in that table waiting for time to expire.

MariaDB [fog]> select * from scheduledTasks; +------+-------------+--------+--------+--------------+----------+--------+-------+---------+-------+-----------+---------------+-----------+------------+----------+----------+----------+----------+----------+------------+----------+ | stID | stName | stDesc | stType | stTaskTypeID | stMinute | stHour | stDOM | stMonth | stDOW | stIsGroup | stGroupHostID | stImageID | stShutDown | stOther1 | stOther2 | stOther3 | stOther4 | stOther5 | stDateTime | stActive | +------+-------------+--------+--------+--------------+----------+--------+-------+---------+-------+-----------+---------------+-----------+------------+----------+----------+----------+----------+----------+------------+----------+ | 1 | Deploy Task | | C | 1 | 45 | 12 | 12 | 5 | | | 1 | 0 | | | -1 | fog | 1 | | 0 | 1 | +------+-------------+--------+--------+--------------+----------+--------+-------+---------+-------+-----------+---------------+-----------+------------+----------+----------+----------+----------+----------+------------+----------+ 1 row in set (0.000 sec)

I didn’t check to see if I could schedule a snapin deployment task. But this might get you headed in the direction for a home brew solution.

Unfortunately, it is not working!
I am not sure where to look at for further errors.
Any ideas! But for now - happy easter!

@george1421 said in local GRUB booting fails from FOG-Menu (PXE-UEFI):

@thomGee Instead of rEFUnd lets try mode EXIT.
Prior to version 1.5.10 there was a bug in exit. I hope it was fixed in 1.5.10 (I don’t remember the change log at the moment).
I am a bit confused because FOG 1.5.10 and 1.5.9 are basically the same in this area with maybe the exception that refind was updated to the latest release.
If there is still is still a bug in EXIT, I’ll look up the patch and we will recompile ipxe with the patch.
In regards to FOG and UEFI. FOG and iPXE chain calls refind to manage booting to the hard drive. We (you) might need to make some adjustments to the refind.conf file on the fog server to correct this behavior, I don’t know what might need to be changed at the moment.
One last bit, don’t use FOG’s grub exit modes, those are only for bios based computers and will fall flat if you try to use them with uefi.

@Punti I have never seen this error before. Doing a little search engine foo I came across this topic where they talk about an issue in the GnuTLS libraries used by git and that the whole issue was magically fixed (by Github?) in the end: https://discourse.pi-hole.net/t/error-git-remote-https-died-of-signal-4/56558/17

Though on the other hand this is really strange because I did give it a try in my Ubuntu 20.04 test machine and it does not run into the same problem. Maybe this really is a temporary Github problem??