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.

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

@yannickF It runs as the system user. In linux world this would essentially be root, yes.

Is the ZIP file containing more than just the ScriptAgent shell script?

@Sebastian-Roth I didn’t know about the 100% option - I like that!

@abulhol Any news on this?

@sebastian-roth Thanks a lot.

@sebastian-roth
Here is the photo of the error I get on first boot.:(IMG_20221216_144511881.jpg

Il have no raid configuration neither on source or destination machine.
So I don’t understant why I get errors with mdadm files.

If I edit the /etc/fstab file, I always have the error “ALERT! /dev/nvme0n1p2 does not exist”

@caroljames972022 Not enough memory can mean RAM or disk space. I guess it’s RAM (in the VM). Nevertheless we need to now more details to be able to help. Please post a picture of the error as well as the VM settings (disk and RAM).

Thank you for your answers. I’ll give it a try and let you know!

@sebastian-roth Thanks.

@george1421
Boa Noite,

Eu olhei o link que você enviou e acredito que entendi a teoria, você tem ou conhece algum tutorial ou vídeo explicativo em funcionamento ?

@brad-chamberlain If you edit the dhcp config file make sure you restart the isc-dhcp service.

The next step is to see what the dhcp server is telling the client. The easiest way is to use tcpdump to capture the dhcp process.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

You can use tcpdump on the fog server or install wireshark on the fog server if you have the Xwindows ui installed. For wireshark use the capture filter of port 67 or port 68 or port 69 or port 4011 Start tcpdump/wireshark and then pxe boot the target computer to the error. Then stop the capture.

Review the pcap with wireshark. You should see the DORA process (Discover, Offer, Request, Ack/Nak). The target computer will send out a DISCOVER packet, look at packet at dhcp option 93 this will be the target computer saying what type it is uefi or bios. Then look at the OFFER packet from the dhcp server. In there the header should be set with {next-server} and {boot-file} matching dhcp options 66 (fog server IP) and option 67 boot file name. The answer should be in the dhcp process. If you can’t spot it upload the pcap to a file sharing site and either DM me the link or post it in the thread and I’ll take a look at it.

The dhcp settings you copied from the coexistence page should be accurate.

@sebastian-roth Thank you very much for the quick reply! PhP was running on version 8.x. Downloading and running the current dev-branch now allows me to connect to the web interface. Thank you for your help!