@aurfalien said in Mellanox ConnectX 3 imaging issues.:

So all good here.

Did FOS Linux have the driver enabled for that 10GbE card (i.e. were you able to image with FOG once you got past the iPXE menu)?

FWIW: For uefi mode snp.efi or snponly.efi should work if undionly.kpxe worked in bios mode. I’m saying it should because ConnectX3 is a somewhat older card (circa 2017/2018).

@Almeida BitLocker is enabled in your master ? If yes, you should disable it. Enable it only on the final computer.

We do have the BCD issue when enabling BitLocker on 24h2 image, we are running the same commands, but you are missing one.

You need to set device partition=C: for the recover from hibernate entry too. The annoying part is that its ID is dynamic.

@Tom-Elliott I fixed it by directly removing the dirty flag using Linux. sudo ntfsfix -d /dev/nvme...

We need to redo our golden image, so we will check at that time if we still get the same behavior.

Thx for the help !

@punch07 to view the /tftpboot use the command line terminal window. Now I do have to say that different distros have the directory in different locations like /var/lib/tftpboot.

@Eazis I created an experimental kernel that includes the drivers to fix this issue. Would you be willing to test it and let us know how it goes?

@george1421 Just seeing if anyone else has had issues.

Haven’t purchased the new models yet.

Was hoping to confirm they’re compatible with FOG first, so thought I’d reach out and ask around.

Thank you!

@george1421 Thanks for the insight!

I’ve tried adding Dell’s WinPE driver package to the driver store but it doesn’t seem to have helped either. Whether it’s just the wrong drivers for the specific machine, i’m not sure yet.

I’ll give it another go once we get some more Dell stock in - but thank you for the help in the meantime 🙂

@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

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!

@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