@maxwellmw In your for service loop I don’t see ssh in the list.

in the console window of your fog server key in
firewall-cmd --permanent --zone=public --add-service=ssh

@sebastian-roth I think our only option is to handle this on the tftp server size. I think the issue is packet fragmentation over UDP. I think we can set a maximum block size for the tftp server. What we need to do is set it at -64b from the MTU. I did find an example of it here: https://askubuntu.com/questions/644031/tftpd-hpa-how-can-i-set-blksize-option but I don’t know if ubuntu uses xinetd or something else.

@pjb1983 What version number of ubuntu? 20.04?

@sebastian-roth Sure I’ll rebuild the 5.9.3 (quickest path because of the kernel patches) in about 5hrs. I’m out of the office until after lunch time Easter USA time. My build server is powered off at the moment or I could build it remotely.

I was thinking the same thing last night about the network group not being in the kernel since the network cards were added in 4.20 and our build settings for 5.x are based on 4.19.

I don’t think using the 5.10rc builds are the right thing to do at the moment.

@epsilon52 WHAT DO YOU MEAN ITS FOG’s FAULT?

If you are still unbroken lets continue.

So let me ask you. Are the target computers on the same subnet as the FOG server or are they separated from the fog server by a WAN/VPN link?

If the fog server and target computers are on the same subnet and you are still having issues please follow these instructions. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap to a file share site and either post the link here or PM me the link and I’ll take a look at it.

@will Lets try this kernel.

https://drive.google.com/file/d/1blQf70N3um0bXmr1wjzQbQk47TA97gpW/view?usp=sharing

its bzImage593RT2 the only changes is enabling that specific intel network adapter driver.

@epsilon52 Ok you are missing a setting in the bios configuration. On the network tab, you need to tick the “Enable uefi network stack” (or something named similar. Its usually at the very top of the network configuration page) to be able to pxe boot in uefi mode.

Then you will be able to set the pxe booting first in the boot order if you want to do that.

@epsilon52 Just to be sure we understand what is going on here.

When you change the pxe boot first in the boot order. The computer pxe boots and do you see the FOG iPXE menu?

And where its failing is after the iPXE menu times out instead of booting into windows it just reboots?

-OR-
Are you never seeing the FOG iPXE menu?
Do I understand where its failing?

@will FOG does not know or care about HDD or SSD drives. All it does is write the image to a disk you tell it to. If you have a computer with a SSD and HDD installed you will need to tell FOG which disk to write the image to.

@epsilon52 First let me say that I 100% agree with Sebastian, but I also know a secret for the Dells.

Using the Dell CCTK (Command and configure tool) you can instruct the bios to pxe boot on the next boot up. This is totally outside the scope of FOG and not something that FOG is capable of, but the cctk tool has the ability to update/change bios settings from inside windows. So using that thought one could create a snapin (FOG deployable program) to run the preinstalled cctk command with the proper parameters to pxe boot on the next reboot only then instruct the computer to reboot. You would deploy that task after you have created an imaging task. I have not personally do this on my campus because I have other rules, but it should be totally possible with snapins and the fog client (I don’t use either in my environment).

As I said before I require the Imaging Tech to sit in front of the computer being imaged so they are 100% certain on what computer they are imaging. Because once in the past with the fully automated process we had an Imaging Tech pick the wrong computer and reimaged (i.e. erased) a VIP’s computer.

@devrick said in Updating a registry file after deployment:

/usr/share/fog/lib/funcs.sh

To extend what Tom said…

These post install scripts are run from the context of the target computer running FOS Linux. That file contains a swiss army knife of useful scripts that is needed for both imaging as well as post install script functions. That referenced file is on the virtual hard drive that is downloaded to the target computer during the pxe booting process.

When you get to the point where you want to start debugging your post install script we can give you some additional guidance to make debugging a lot easier. But I don’t want to flood this thread with useless stuff until you are ready.

@nil Just looking at the exports line the fsid=0 and fsid=1 stanza missing from each line. Did you hand edit the exports file?

Also you can run the showmount -e 127.0.0.1 to show the nfs exports.

Also make sure the debian firewall is disabled.

@rogalskij said in Issue deploying image to new Dell Latitude 5410:

My Kernel version is 4.19.143

There is an upgrade kernel that is not LTS supported that has the drivers for 2019 and 2020 computers. Upgrade your kernel to 5.6.18 from FOG Configuration -> Kernel Download both the 32 bit and 64 bit kernels.

@tmcwl Ok the showmount command tells us what is wrong. You don’t have images2 “shared” in NFS.

A quick fix is to edit /etc/exports

Duplicate the existing lines
Change the duplicated lines to match /images2
important at the end of the duplicated lines you will see fsid=0 and fsid=1 change them to fsid=3 and fsid=4
Save the file

then run the commad sudo exportfs -a

then run sudo showmount -e 127.0.0.1 again Now you should see the two new shares.

Now try to image again.

@danieln said in Clients imaging despite recieving "Read ERROR: No such file or directory" and "ata1.00: failed command" errors:

is there an easy way to update this kernel

FOG (FOS) kernels can be downloaded from here https://fogproject.org/kernels/ download both the x64 and x32 bit kernels. Save the x64 as bzImage and the x32 ad bzImage32 (case is important). Then you can just move the files to /var/www/html/fog/service/ipxe directory on the FOG server. It probably wouldn’t hurt to rename the existing ones before you move the new kernels in. You can confirm the version of the bzImage files with file /var/www/html/fog/service/ipxe/bzImage It should print out the version of the kernel.

@sebastian-roth what I was seeing in the other thread is that ipxe was seeing one mac address and displaying that on the FOG iPXE screen with unregistered. When the OP of that thread ran through full registration and the system would reboot, the fog iPXE menu would still say unregistered. I had the OP of that thread manually register the mac displayed on the iPXE menu and then iPXE would see it as registered. We then compared what iPXE was seeing and what FOS was seeing for the mac address of the interface. iPXE and FOS showed a different mac address for the same network adapter. Booting into widows showed the same mac address that FOS linux sees. Its possible that the complete OS’ are seeing the pass through mac address, where iPXE is seeing the adapter mac since it may not have the driver to see the pass through mac (guess). But this appears now to be the second issue with these unique circumstances.

@x23piracy Here is 5.6.18RT3 which has the updated realtek drivers in them. https://drive.google.com/file/d/1O-4tvx4DywWef75qfSxLRK9M6CoDS9pd/view?usp=sharing See how well these work with that nic.

@lukekfrost the FOG install doesn’t like it when the ip address of the imaging interface is changed after FOG is installed. There are several locations where the static IP address is recorded. You linked to the wiki page, also this post addresses the same issue as you have today. https://forums.fogproject.org/topic/15112/changed-ip-reinstalling-not-an-option

My unoffical instructions are to

1. Update the hidden file /opt/fog/.fogsettings fix the IP address in there.
2. Update the IP address in /tftpboot/default.ipxe
3. Update the IP address in the web ui under fog configuration->fog settings->expand all. search for the old IP address and replace it with the new address.
4. In the fog storage node default, change the IP address in there.
5. Back in the fog server linux console, rerun the FOG installer to fix the remaining bits.

@jacob-gallant said in HP ProBook 640 G8 imaging extremely slowly:

just the ProBook 640 G8

The debugging truth table points to the probook at fault root.

So what is unique about this workstation from previous models? NVMe vs SATA? Specific NVMe disk?

If you want to debug this hardware a bit more we can do that. The issue will be with either the network stack or the disk subsystem.

Here is a link to iperf3 https://drive.google.com/file/d/1fLYGI-roYGongTVRS_4zQ7dWJ7osN4AW/view?usp=sharing

Place it in /images directory

The concept of testing is coming from this post: https://forums.fogproject.org/post/98231

the setup for testing is pretty easy, just setup a debug deployment to this computer. (tick the debug checkbox before submitting the deployment task).

Now pxe boot the target computer after a few screens of text you will be dropped to the FOS linux command prompt.

At the fos linux command prompt key in fog You will need to press enter after each breakpoint in the imaging code. After you see the first partclone copy complete press the Ctrl-C to break out of the deployment script.

The iperf command will be in /images directory on the pxe booting computer. Copy it over to the /tmp directory on the target computer cp /images/iperf3 /tmp Then run the iperf command as outlined in this post. https://forums.fogproject.org/post/98230
You will need to setup the iperf3 receiver on the FOG server and then the client on the target computer. This test will see how fast the network speed is between the target computer and the FOG server.

Once the network bits have been tested then testing the hard drive is next.

This will be a bit more complicated to test, so see if the hdparm command comes back with something in FOS Linux.

@mrawesome987 that is crazy obsecure, but I’m glad you found it.

This sounds like a perfect tip to add to the wiki @Wayne-Workman

@x23piracy OK this has nothing to do with the FOS Linux kernel since you are not that far in the process. The issue is with iPXE.

Instead of using ipxe.efi try snponly.efi to boot. The snponly uses the build in uefi network driver in the nic adapter instead of using the standard network driver built into ipxe.efi. snp is kind of akin to the ndis/undi interface in bios.