Posts made by george1421

@bobbywitt Are you having a problem or are you just seeing if others have had issues?

@skyhawk3355 I remember awhile ago I needed to create a one-off kernel for a system that had a 486 cpu. I checked but I don’t have that kernel any more.

I just recompiled the linux 6.6.85 for a 586 based CPU. I can recompile for a 486, but I don’t know if that is going to get us anything better.

Here is 6.6.85 586 version
https://drive.google.com/file/d/1GAzFjbtpDVXXCRpe6bIZ5mwySSXeDHko/view?usp=drive_link

Here is 6.6.85 586 where I stripped out some drivers like scsi, nvme, uncommon network drivers, virtualization drivers, etc. I was able to strip out over 1MB of kernel size from the previous one above. Did I through out too much?? YMMV.
https://drive.google.com/file/d/13dE7BLgofsFiNJj_Q8nLDknplRbWRqkJ/view?usp=drive_link

@Eazis said in ASUS NUC14MNK fos kernel no netwerk drivers:

So the 8125 driver was missing?

Well if you close one eye and squint with the other, you can still see it. The kernel developers consolidated all of the realtek drivers into the 8169 driver which kind of works except the driver updates lags behind the hardware by a few months. It looks like the FOG developers have a way to integrate the official realtek drivers moving forward so that should make life with the reaktek nics easier because realtek releases a new subversion of the hardware every few months.

Anyway I’m glad you have your issue sorted out and the FOG developers have a plan forward too. @rodluz (well done!)

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

@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

@Tom-Elliott said in ASUS NUC14MNK fos kernel no netwerk drivers:

I suppose we could attempt to add all of them, but we don’t know which one applies to your specific device.

Also if we booted into debug mode and after the error is presented search syslog for the key word ‘firmware’ the kernel should post anything its missing. grep -i -e firm /var/log/syslog

@Eazis Ok A little google-fu shows this is not an 8169 nic but a 8125 (2.5GbE) nic. (I personally really dislike realtek because of this BS).

So now we need to figure out how to add 8125 native nic support to the FOS kernel.

@hariskar It looks like your root partition ‘/’ has 1.8T or 1800GB of space. The command I would have run is df -h to give you usage. but assuming that debian is less that 50GB you should have plenty of space to capture a modern computer with 50GB of data. Use single disk resizable to use zstd to compress that 50GB of data down even smaller.

What error message are you getting? A screen shot of the error might help set the context of the error.

@Eazis will you check to see if the beta version 6.12.x series fixes the issue? https://github.com/FOGProject/fos/releases

If not we will need compile a special kernel with the current realtek driver installed. The linux mainstream kernel drivers typically lags current hardware.

@wamis let start by updating your fos linux kernel to something more modern. I think 6.8.86 may be the latest. FOG Settings->Kernel->update kernel. FOG 1.5.7 is old. Lets see if we can update the kernel without needing to update fog.

@Eazis said in ASUS NUC14MNK fos kernel no netwerk drivers:

ASUS NUC14MNK.

Using either windows or linux can we get the hardware ID of that nic. In windows its under the device manager and the hardware ID. It should be two series of hex numbers. Under linux you would use lspci -nn | grep -i net in this form the code we need looks like [8088:14dc] (made up number). That will tell us if there is a driver in the linux kernel for that.

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

A friend of mine have added the correct driver into the bzimage file

Can you explain this in a bit more detail? Lets see if we can help everyone do better, please.

@jack_darnellits Are you able to get IP addresses on vlan 1? If yes then dhcp is working. Your dhcp server may be doing a directed broadcast (not common) its kind of like a unicast message directly between the dhcp server and target computer. Normally dhcp servers use broadcast messages which can be detected by a monitoring computer running tcpdump/wireshark.

You may have to put the pxe booting computer on a mirrored port to see this communications.

Or as an alternative use / install dnsmasq on your fog server to give pxe booting information (only) to the computers. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

We will typically recommend dnsmasq when you have an uneditable dhcp server or a soho router/dhcp server that will not play nice.