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 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?
@sebastian-roth Yes, I’m thinking of disk UUIDs or the serial number.
Hi!
We have a lab of 20 or so identical PCs, all with 2 identical NVMe drives and 1 SATA drive. We’ve been using FOG since years without major issues, but this is our first setup with two identical NVMe drives. We are experiencing the issue with FOG mixing up the NVMe drives both with single disk and multi disk images. I’ve read the discussion in NVME madness, based on which there is currently no solution for this with identical NVMe drives. Are there any plans or hope for a solution?
In NVME madness it was mentioned that the disk identifiers could be used to identify the right disk, but they cannot be used for capturing since it would cause issues when deploying the image to another PC. Have you thought of implementing the usage of disk identifiers for the deployment? I’m thinking of the possibility to specify the order of drives in the Host Primary Disk field by listing all disk identifiers in the right order. I’m not worried about the drives being captured in the wrong order, I can sort that out after capturing.
