Specifying the target disk works with HDD but not with NVMe.

[mashina]

I’m encountering an issue with my iPXE menu configuration when specifying the target disk for FOG image deployment. It works smoothly on computers with a traditional hard disk and Legacy BIOS. However, the same setup fails on machines equipped with NVMe SSDs and running UEFI. I suspect that either the hd parameter isn’t recognized in the case of SSDs or there’s an underlying UEFI compatibility issue.

I’ve been struggling to resolve this for quite some time now and would greatly appreciate any assistance.

Here’s the configuration for computers with HDD:

kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.1.1/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac= ftp=192.168.1.1 storage=192.168.1.1:/images/ storageip=192.168.1.1 osid=9 irqpoll chkdsk=0 img=Peruswin10 imgType=n imgPartitionType=all imgid=4 imgFormat=5 capone=1 type=down hd=/dev/sdb isdebug=yes
imgfetch init.xz
boot

And for the target computers with UEFI and SSD:

kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.1.1/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac= ftp=192.168.1.1 storage=192.168.1.1:/images/ storageip=192.168.1.1 osid=9 irqpoll chkdsk=0 img=Windows10 imgType=n imgPartitionType=all imgid=5 imgFormat=5 capone=1 type=down hd=/dev/nvme1n1 isdebug=yes
imgfetch init.xz
boot

[Tom Elliott]

@mashina This is a relatively known issue and unfortunately one that isn’t simple enough to fix at least for us.

So with SATA, orders of drives loading (though sometimes confusing with USB sticks/drives plugged in) generally loaded with the order of the channel the sata drive was plugged in (sata0 usually = /dev/sda, sata1 usually = /dev/sdb, etc…) Get’s more confusing when you include SCSI things.

With PATA, orders of drive loading was based on the channel and the placement on the ribbon:
PATA0 -> End of cable = /dev/hda
PATA0 -> Middle of cable = /dev/hdb
PATA1 -> End of cable = /dev/hdc,

etc…

With NVME you’re dealing with loads of PCI channels loading and the device presenting at a specific time.

So This boot, what was nvme0n1 next boot might be nvme1n1

There’s not really a way for us to make sure consistency on the nvme drive loadouts unfortunatley and I suspect this is what’s plaguing you right now.

[mashina]

@Tom-Elliott,

Thank you for clarifying the situation. That makes sense now that you mention it.

One issue is still puzzling me. When I’m debugging, I notice that the “hd” parameter is always passed as /dev/nvme0n1 even when I’ve configured it as /dev/nvme1n1 in the iPXE menu parameters. I understand that NVMe names might not remain consistent across boots, but shouldn’t the hd parameter at least reflect the correct path set in the iPXE menu?

Another question is: how difficult is it to create an interactive deployment process where users can choose the disk for image deployment after the boot? Given that PCI naming persists after boot, can FOG simply use the variable set by the user as the target disk? Are there any limitations that would prevent implementing such a feature?

[Tom Elliott]

@mashina hd isn’t a “true” kernel argument, and as such isn’t built as an environment variable at load up. As the OS loads, the getHardDisk function will get called and make its best guess to what drive to use.

If you want the specific disk of a host to be /dev/nvme1n1, then you should set it on the host under kernel device (or if it’s always global, set fdrive=/dev/nvme1n1 on the extra args instead of hd=/dev/nvme1n1)