Best posts made by george1421

@ayy_nelson said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):

I too purchased a handful of new G8 HP Laptops.

Some things we found with this new generation of systems with this realtek network adapter. Update your FOS Linux kernel to 5.15.x series (we just discovered this) and also update your iPXE version using this method. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Right now we only have anecdotal evidence that it fixes what changed in this generation of hardware.

@jtappen TBH I can’t remember if I responded to you or another poster in a different thread, but we’ve seen an uptick of issues with these new HP generation using the realtek nics.

This issue is specific to iPXE and the HP hardware. So for uefi there are a few .efi boot loaders I want you to try.

The default is ipxe.efi this contains all of the known (at the time of compiling) nic drivers. This boot loader is much like linux where the divers are compiled into the operating system.

The second is snponly.efi. This boot loader uses the driver built into the network cards. This should have the maximum compatibility. I would suggest that you try this to see if it works for these hp computers.

The third boot loader I want you to try is realtek.efi. This boot loader has only the realtek drivers compiled into the boot loader. See if this one works.

For reference you have iPXE version [g4bd0]

Do you have a cheap unmanged switch that we can have you insert between this computer and the building network switch? I’d like to see if you can get an IP address with that cheap switch in between the computer and the building switch. We need to do this test to rule out something common.

@flareimp Ah ok. You will want to do that with a post install script. A post install script will execute just after the image is pushed to the computer and just before the cloning completes.

With the post install script the ideal is to connect to the deployed image’s hard drive, make the adjustments to the .fogsettings file. The continue on with the reset of imaging. The only thing you will need to do before you capture the image is create a script that will run within the context of the newly imaged computer to run the installer command with the -y to execute the installer. Before SystemD (i.e. SysV) I would just create a 99local file in the startup folder that would execute the first time boot up commands. That 99local script would then remove itself from the startup folder so it would only execute once. There maybe something more elegant that can be done with SystemD.

The basic concepts are laid out here. I know this post is windows centric, but the way we go about it is very similar under linux. I just haven’t had a chance to write a linux equivalent of this tutorial: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

@jonathan-cool said in Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop:

First I recommended lsblk not blkid but it did give me enough info.

That non-movable partition 4 will keep the c drive partition from expanding.

My best chance is to recreate the W10x64 21h2 UEFI image at the beginning, no ?

The easy answer for me to say is yes, you should rebuild it.

The why is a bit harder to explain but the sins of the past are now slowly dragging you into a fiery pit of hell.

1. You manually converted a mbr disk into a gpt disk, and relocated the efi partition to some other location than disk 1 partition 1. UEFI firmware will find the partition because it scans all of the partitions to locate its uefi boot partition.
2. This efi boot partition is behind the OS partition keeping it from expanding correctly because the EFI partition is not expandable or portable.
3. You have a non microsoft standard disk layout
4. You upgraded from 1909 to 21h2, that’s 5 OS generations different. In place upgrades always have strange issues (in my experience). 21h2 is a completely different OS than 1909, yes they are windows 10 but under the hood everything is different.

I think you would be best served by starting clean once again, with all of the current patches and applications for your organization. I know it will take time to recreate your golden image but I think a redo is the best answer.

NOW TO THE CAVEAT, if 21h2 is doing something different with the disk partitions and adding more windows directories its possible that even after you rebuild a clean 21h2 disk, the script may still fail.

@Backpain This looks like a normal FOG config file. It is setup exactly how you need it.

So let me ask a bit more about your network.
1, It looks like all devices (fog server, pxe booting computer) are on the same subnet. Is that correct?
2. If yes is that vlan 4 an isolated network used just for imaging or is it a general purpose vlan with many types of devices on it?
3. Is there any chance another dhcp server is responding to the pxe boot requests? Either by a dhcp-relay / helper service on your vlan router or by directly having a second dhcp server on your network?

Beyond the questions, I think our next step is to see if we can get a packet capture of the pxe booting process to see where the client is being directed and by whom. I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1673391869214

Upload the pcap to a file share site and post the link here and I’ll take a look at it. If you want to review it yourself, use wireshark to open the pcap file. Look at the dhcp OFFER packet. This will be from your dhcp server. Look at the dhcp header for the next-server and boot-file fields. They should contain data… but there are two many what-ifs here, its probably best to let me look at it

@Omar_Medhat How big is the iso image.

There are some limitations you need to be aware of.

1. Memdisk will only work in bios mode.
2. Memdisk is a 32 bit application so that limits the size of the iso image to 2GB.
3. To boot out of an in memory iso image, your system needs enough ram to contain the entire contents of the iso image AND enough free ram to run the OS from the ISO.

To the second part of the question, can you boot a .efi file via a custom menu. Probably.

Your custom menu configuration will probably look like something similar to this:
Menu Item: os.special_fw_update
Description: Firmware Update for this system
Parameters:
kernel tftp://${fog-ip}/bios_file_updater.efi
boot || goto MENU
Menu Show with: All Hosts

Where bios_file_updater.efi is the name of you unnamed update file. That file will need to be in the /tftpboot directory on the fog server.

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/9

@brian-mainake So do you have the fog location plugin installed? If yes you allocated each storage node (master or slave) to a specific location?

The last bit during fog target host registration, did you allocate the target computer to a certain location? From your explanation it sounds like either the storage node (master or slave) or the target computer is not in the same location so it goes to the master node.

@ikt_le Before you go and setup dhcp on FOG server, answer me this: Does the network where the target computers will PXE boot have an existing dhcp server? If yes is it a linux or windows 2012 or later dhcp server?

If yes on both questions then we can use that dhcp server so there is no need for FOG dhcp.

@DPR-SIO OK then you have a good chance to make this work.

so it looks like for your ftp user account your images should be in /images/dev If what you are showing me is the pwd when you are logged in using ftp.

So if you look at your storage node configuration you have /share/FOG/images Which is probably your absolute path on your NAS. From the FTP account it looks like root directory for the user account is at the /share/FOG path. SO… long story short in the storage node configuration change the FTP path from /share/FOG/images to /images and the snapins path to /snapins

Now the image Path will be the NFS path. For now don’t change that, but inspect that directory on the NAS. Do you see a subdirectory in that path with a name that looks like a mac address? If yes you have the image path set correctly. If I remember right where the image capture was failing was on the FTP login not image capture.

At the end of this workaround, you can delete any directory and contents in the /images/dev/ where the directory name appears as a mac address. That directory should only exist during an actual image capture task.

@DPR-SIO OK so to debug this, I would (from a windows computer) ftp to your NAS IP using the foguser (and password) you created on your NAS. If you get logged in key in pwd to print working directory, See if that gives you an absolute path or just your home directory.

So the error you posted is failed to open stream, so it means that directory you blanked out in red, the ftp account can not reach that folder. So start with cd /share can you get to there? do al ls to see what the content of share is. Work your way down the path. Its possible its a permission problem why you can’t get to the directory to move it. Or the base path is not correct.

@DPR-SIO Running the FOS Install script on a NAS probably will not work since the install script assumes your “NAS” is a linux computer.

Its possible to setup a NAS as a storage node as long as it has NFS and ftp capabilities. The NFS share directory and the FTP user directories need to point to the same location. In the storage node definition there is an FTP path field, that needs contain the actual path on the NAS where the files are located. The qnap and synology instructions do a good job of showing how things need to be configured. You need to make things configured in the correct location on the NAS, confirm that the ftp user can access both /images/dev and /images directory to move files.

@DPR-SIO First let me say that the FOG Project devs don’t support this configuration. They only support using FOG servers or FOG Storage nodes.

With that said you could have success using an external NAS device if the NAS can meet certain requirement. FOG uses NFS and then ftp to capture images. NFS is used to capture the image to /images/dev/<mac_address> folder and then uses FTP to move it from the read/write area to the read only area in /images. The error indicates that its failing on the FTP login and move commands.

Looking in the wiki and tutorial I see some article that might help.

https://wiki.fogproject.org/wiki/index.php?title=NAS_Storage_Node

https://forums.fogproject.org/topic/10973/add-a-nas-qnap-ts-231-as-a-storage-node-fog-v1-4

and the tutorial I wrote for synology nas (this one for you is more about the concepts and not the commands)

https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@Flyer You can do quite a lot with post install scripts to decode the hardware so if you need to make hardware specific changes in your script you can.

I have a few tutorials on this. In this example you can get the model number and system manufacturer of the computer the script is running on using dmidecode.
https://forums.fogproject.org/post/88293

Also here is a post install script for installing the proper windows drivers onto the target hardware: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection The point of this script isn’t to show you how to inject drivers, but the method to extract data to make your post install script more flexible.

This post here is just random snippets of code that look at IP address and how to get fog run time variables into your post install script. https://forums.fogproject.org/post/69725

While I agree that having a post install script per host might be a good idea, I think it would only be a very edge case and be more of a management nightmare if you had a campus with 1000s of hosts.

@Koffinny said in Issue booting PXE on clients:

It is a Tp-Link router

I have seen many soho routers not support pxe booting or have the options to set dhcp option 66 and 67. If your pxe booting computers and your FOG server is on the same subnet its probably the best solution (assuming your router doesn’t support pxe booting natively) to install DNSMASQ on the fog server to provide pxe booting info (only). DNSMASQ is kind of a swiss army knife of a tool, but supporting proxydhcp is one bit that we will use. It takes about 10 minutes to install and configure on your fog server and probably less time you’ve spent with yoru current router. Realize that dnsmasq will only give you the pxe boot information your main dhcp server will provide everything else. No changes are needed on your network unless you want to pxe boot across a router. Then there is one simple setting you need there.

I have a tutorial on how to install dnsmasq on your fog server here: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1681250221198

@kamburta The basic steps are here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

You will just need to get the right kernel parameters for booting ubuntu live. If you have a live boot CD you can get the parameters from either grub.cfg for the isolinux.cfg files. The steps for live boot are very close to the steps to boot the installer its just the kernel parameters that need to be adjusted.

@rhromyko This is probably related to the latest versions of Ubuntu and Debian, I’m a bit surprised that 22.04 has the issue though. I’m suspecting that FOS Linux doesn’t have the 1.47 version installed. Is the error happening during imaging or is it when you live boot Ubuntu?

As Tom mentioned the term “PXE OS” could be confusing the issue. Let us know exactly where in the process you are getting this error.

@tahitiju said in Multicast is very slow:

I try to deploy an image to some PCs but performance is very low (2MB/min) using multicast.
For the purpose of the test, FOG server (1Gb NIC), clients (1Gb NIC) and dhcp are connected together using a Linksys Switch ( 16 x 1Gb ports / unmanaged) .
Using unicast, performance seems normal (~1,5GB/min deploying 14 PCs).

A few things jump out at me with this. Multicasting can be very taxing on inexpensive network hardware. When you are getting 2MB/min how many systems are you multicasting to? Do you get the same performance when multcasting to 1 or 2 machines?

Multicast imaging moves at the speed of the slowest computer in the mcast group.

1,5GB/min is on the slow end of the scale. On a well managed 1GbE network, imaging to current hardware, I would expect about 6GB/min. If put your fog server on 10GbE network I would expect about 13GB/min. I’m only pointing it out that there might be something in your network infrastructure that is slowing things down.

A 1GbE network link will saturate with 3 simultaneous unicast deployments.

The FOG performance numbers displayed on the target computer are a composite number of how fast the fog server can pull the image off the disk, send it over the next, the client receiving the image, expanding it in memory and then writing it to disk. Any one component that is slow will impact the overall performance score.

@ERockZab Is secure boot enabled on the target computer? If yes turn it off and try again.

@dvorak Its not e2fsck in your fog server host OS, its in the FOS Linux OS that gets copied to the target computer during pxe booting. That needs to be updated.

@Alan-Lim Lets run through this tutorial and compare it to your settings: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node