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

Has there been a solution to this problem? I have tried many versions of FOG, but I can’t input anything on the keyboard when entering the iPEX menu.

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

There is a BIOS update for the MiniX PCs that allows the PCs to be built from FOG 1.5.4 running on CentOS 7.5.2009.

I do not know the technicalities but upgrading from verion 6 to 8, was mentioned.

@george1421 This worked! Thank you so much for your help!

@Jim-Holcomb So unfortunately i’m not readily available for a remote assist due to work requirements and duties so I apologize.

@Jim-Holcomb said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:

After upgrading to the latest FOG version, my PXE boot environment is broken. What used to work flawlessly is now a disaster. PXE clients either hang, enter a loop, or display autoexec.ipxe not found. Sometimes pressing ESC brings up a green DOS-style login prompt, then fails to chainload. Sometimes they hang on “Booting…” indefinitely.

So this “autoexec.ipxe not found” always shows. This is not an issue. It’s simply saying there’s no file called autoexec.ipxe on your /tftpboot folder. It’s NOT whatever was causing ipxe boot issues. I’m guessing this PXE boot environment was broken due to whatever was changed?

As to the selective hard drive. I’m not sure I understand what is wrong here. YOu watched it write ONLY to the /dev/nvme drive but somehow it wrote to both the sda and the nvme? Something doesn’t sound right there. Single Disk resizable and Multiple Partition Single disk shoudl only write to a single drive and be done. Do you have video of this process writing to both? I only ask because seeing this in action will help me understand where the code is flawed. To my knowledge, however, it seems more likely that at some point before you wrote to the NVME it had accidentally written to the SDA drive, then you try to figure out how to have it write to the NVME. Then, finally, it was able to write to the NVME, but now it LOOKS like it wrote to both because the SDA drive was never cleared out?

And yes, d1.mbr is absolutely correct. That’s how it initializes the disk.

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

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

@brentomp Kernel issues, see
https://forums.fogproject.org/topic/17698/fog-very-slow-to-deploy-image-lenovo-neo-50q-gen-4/14

@pierre-baylet Bonjour, j’ai eu la meme erreur lors de la mise à jour en 1.5.10. J’ai aussi un storage node déporté sur un NAS Synology. J’avais une erreur après la capture, avec un “Update database failed”.
Il faut que tu refasses les permissions sur ton dossier images/dev sur ton FTP.

Pour mon syno j’ai fait la manip suivante :
depuis mon fog en ssh :
sudo mount -t nfs @IPNAS:/volume1/images /mnt
chown -R root:users /mnt/dev
chmod g+s /mnt/dev