@rodluz said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

That is exactly what I did, I disabled the 8169 driver from the kernel config too.

Good going. That 8125 driver was originally in the linux kernel individually but then the driver was merged into the 8169 unified driver which has not kept up with the realtek hardware changes. I was getting lost trying to integrate a third party driver into the linux kernel. I could compile it as a module and add it to the init.xz but that is not a sustainable solution. If you have it integrated into the kernel for the 8169 (1GbE) and 8125 (2.5GbE) that should cover most of the common network adapters today from realtek (outside of the 10GbE stuff, but those haven’t hit the desktops yet).
Well done!

@Eazis Will you test a new experimental kernel that @rodluz in this post
https://forums.fogproject.org/post/156904

@jack_darnellits Historically when the intel rst adapter is in raid-on mode linux can’t see the disk behind the raid controller and the sata controller presents itself as a different device depending on the raid mode. When you look at it when its in ahci mode linux will see it as a sata controller, when its in raid mode linux sees it as a different device, not a sata controller but a raid controller with a different device ID.

So that is all historical information. I’m a bit surprised that you were able to image the system in raid mode with FOG (because of historical experiences). You did the right thing by loading the intel rst driver into your golden image. My past experiences with the intel drive is that you need to make sure you have the right one. I’ve had troubles loading windows from dvd on laptops where its not seeing the drive and getting the right F6 driver seemed to be a real pita.

With all that said, what I would do is try to get into windows using recovery mode, that may mean booting from a recovery drive. Verify what you are loading into your mother image is the proper intel driver for the OS to see the network drive. Also make sure you have the dell winpe drivers loaded into the golden image too (you can use the pnputil.exe command to load drivers from the expanded cab file). Right after imaging windows first boot is in winpe mode. The real mode drivers might not be available since windows has not really started.

@rodluz said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

You are welcome to continue using the “OEM driver” kernel for now until I create a full upstream release.

What did you do here, did you fold in the realtek oem driver into the kernel build. I was looking at going this path for another open issue with a realtek 8125, where the oem driver solves a lot of the issues with the default universal drive 8169.

@olivier-bonnici said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

tar xzf linux-6.14.9.tar.gz

Ah that explains the difference. You didn’t just rebuild the kernel you jump to the next version. The FOG developers typically only use long term supported kernel. Currently the latest long term kernel is 6.12.x, you used a development kernel 6.14.x which is not EOL (just means fixes and updates will not happen in this branch).

It looks like whatever was causing the slowness was resolved in 6,14.x and later versions of the linux kernel. Thank you for the clarification.

@skyhawk3355 said in Sub 512MB RAM Devices:

ith my 384Mb computer it’ll boot to the menu but will freeze on inventory or imaging.

To just add a little clarity here. The iPXE menu is under the control of iPXE. Once you pick a menu item FOS (bzImage and init.xz) is loaded into memory and executed.

Both bzImage and init.xz are compressed images, so the size on disk is not indicative of the space consumed in RAM. Both are decompressed as they are loaded into memory. I’d have to look to verify, but I think bzImage is in the 8MB range and init.xz is in the 200mb range.

If you just consider the baselines of a standard gzip compression ratio of 1.6:1, the kernel will expand to 13MB, and the 200MB init.xz would expand to 332MB. That puts us at 345MB for just the image to be held in memory. That leaves almost no ram to execute FOS. Just to caveat this, I have not looked at what the current size of bzImage and init.xz are.

Now if you have no choice, surely look into the 32 bit version of FOS linux since it should consume less space. But with 384MB of ram, that is going to be very tight.

Second option is to remove the hard drive from the computer and image it on a system that has a bit more resources, then place the drive back into the limited computer for first boot.

Another Release(s)! 2506.9.22
https://github.com/darksidemilk/FogApi/releases/tag/2506.9.22

2506.9.19-22 are a slew of releases where I kept finding issues in broader tests right after I released each version. So apologies for the over-releasing there.

• Fixed send-fogimage to work with more use cases and utilize more parameters available to scheduled tasks like bypassbitlocker. Also simplified the parameter sets to avoid errors when using the command with different parameter sets.
• Also added links to PSGallery and chocolatey in each github release going forward.

Full Release Note History: https://fogapi.readthedocs.io/en/latest/ReleaseNotes/
Powershell Gallery Listing for this version: https://www.powershellgallery.com/packages/FogApi/2506.9.22
Chocolatey Package Listing for this version (may take 1-60 days from release to be approved by chocolatey moderators): https://community.chocolatey.org/packages/FogApi/2506.9.22

@Eazis Will you do a few things to help us try to sort this out?

Schedule a capture or deploy to this computer, but before you do tick the debug checkbox before scheduling the task. If you don’t have this computer registered with the FOG server manually register it.

Now pxe boot the target computer, it should start to image right away, but instead of imaging it will drop you to a linux console on the target computer. There will be several screens of text you will need to clear with the enter key, but at the end you will be dropped to a linux command prompt.

How I want you to key in the following.

ip a s
lspci -k -nn | grep -i net
grep -i -e firm /var/log/syslog

get a clear picture of all of the values and post it here.

The first command will show us the network adapters
The second command will show us the hardware ID of the network adapters
The last command searches /var/syslog for any message that has firmware in the name.

After you are done with this, delete the capture/deploy task from the fog server.

@Jias94 Hey no worries, I’ve created that error a few times myself so I had a good idea where to look. I’m glad you have it sorted out and can get back to imaging.

@Jias94 Where I’ve seen this before is in a custom fog menu. The menu id has a minus sign in it and ipxe is thinking its a command not an id. Somewhere around the choose command its getting hung up.

So how do you find this? Using a web browser and access the ipxe menu at http://<fog_server_ip>/fog/service/boot.php You need to replace <fog_server_ip> with the correct ip address. Since you are messing with https, you may need to change that so. You should end up with a screen full of text that makes up the ipxe menu. Looks for things you have entered that have a minus sign. If you can’t find it post the entire content of the ipxe menu here and we will take a look for you. But I would focus your attention around the choose command, one of its entries as a dash where it thinks is an internal command to the menu