@sebastian-roth Sorry for the delay, I have some busy days behind me. I ran the debug task and lsblk on an Intel NUC with a single NVME drive. On the NUC, the results were the same, the WWN field was empty, while the name and serial were ok.

Hi, sorry for bumping this thread, I myself got carried away with other tasks.

As I read the test results, the serial should work for NVME drives on all tested systems. Does this solution have a chance to be merged into the next FOG release?

In the meantime I’m alright with using the modified init file provided by @Sebastian-Roth.

There may also be a chance that I need to capture and deploy our nvme PCs in the near future, in that case I will post the results here.

@sebastian-roth Sorry for the delay, I have some busy days behind me. I ran the debug task and lsblk on an Intel NUC with a single NVME drive. On the NUC, the results were the same, the WWN field was empty, while the name and serial were ok.

@sebastian-roth No problem, here it is:

@sebastian-roth I tested the same debug tasks with the new init. It seems that the WWN cannot be retrieved by the init, but with the serial it seems to work now.

Find another updated init binary on github that might possibly solve the issue

serial(nvme1),serial(nvme2),device-name(sata) = eui.0025385601500953,eui.0025385601500954,/dev/sda

wwn(nvme1),wwn(nvme2),device-name(sata) = S4EVNG0N600905D,S4EVNG0N600906P,/dev/sda

wwn(nvme1),serial(nvme2),device-name(sata) = S4EVNG0N600905D,eui.0025385601500954,/dev/sda

@sebastian-roth Sorry for the delay, today I had some time to test this.

Please download the updated init, place it on your FOG server, schedule a debug deploy task and boot the host up.

I tested the new init with debug tasks with the following host primary field values:

serial(nvme1),serial(nvme2),device-name(sata) = eui.0025385601500953,eui.0025385601500954,/dev/sda

wwn(nvme1),wwn(nvme2),device-name(sata) = S4EVNG0N600905D,S4EVNG0N600906P,/dev/sda

wwn(nvme1),serial(nvme2),device-name(sata) = S4EVNG0N600905D,eui.0025385601500954,/dev/sda

Just for double checking, I also checked lsblk -pdno NAME,SERIAL,WWN again:

@sebastian-roth With the replaced init file it showed Init Version 20211009 during captures/deployments. Sadly, I did not think of checking whether the init version has changed. We have FOG 1.5.9, what is the default init version of that release?

@sebastian-roth I sent you the examples with WWNs and serials in chat.

@sebastian-roth Yesterday I downloaded the init file (init_adv_primary_disk.xz) and replaced the /var/www/html/fog/service/ipxe/init.xz file with the downloaded one.

I did multiple single and multi-disk deployments (multiple partition not resizable) as well as multiple single and multi-disk captures (multiple partition not resizable). I specified the order of disks using the Host Primary Disk field (wwn(nvme),wwn(nvme),device-name(sata) ; serial(nvme),serial(nvme),device-name(sata) ; also single disk capture and deploy by specifying a single disk like serial(nvme) or wwn(nvme)).

With the new init file, the NVME drives still got picked up seemingly randomly in all tested scenarios.

When working on single NVME drives (specified with serial or WWN), the partclone progress screen always showed /dev/nvme0n1 being captured/deployed, regardless of the NVME drive being specified in FOG and the drive that was picked by FOG.

I tested both with the normal setup (2xNVME, 1xSATA) and without the SATA drive. Interestingly, when testing with (2xNVME, 1xSATA) and specifying the Host Primary Disk like WWN1,WWN2,sata_device_name (or the same with serial), the capture/deployment always started with the SATA drive and then continued with the two NVME drives.

Maybe the serial and WWN entries were found to be invalid and/or simply skipped by FOG? The WWNs and serials were correct, I double checked each of them.

@sebastian-roth No problem, I’m glad we have a fix for this now. The Host Primary Disk setting with the disks separated with commas is exactly what we wanted, so I’m enthusiastic to test the fix.

I have some time next week, so I’ll do some captures and deployments on the 13th of October and test the new init file. I’ll come back to you then with our results.

@sebastian-roth I hope you had a pleasant holiday. Any updates on this issue, or should I maybe open an issue on GitHub to track this?