Fog can't find /dev/sda

[Jackske1976]

Hello,

I have currently installed fog 1.6 if I request an capture, from a pc with 2 disks one is an nvme drive the other is an ssd sata drive. Only the sata drive gets an image. and /dev/sda (my windows 10 boot) is not getting imaged. if i check trough the pxe menu where you can select option 5 - show partitions, i get to see dev/sda and sdb 4. Why skipped the detection of /dev/sda on the target-computer during the quick inventory and the strangest is that it happens on all connected computers? the oldest one is from 2012 and the newest is from 2019.

I am a bit clueless over what to do next?

kind regards, Jack

My current setup :
Ubuntu server 24.04 and dnsmasq

[darksidemilk]

Usually nvme paths look more like /dev/nvmen0p1.
The detection of disks is on the FOS side, 1.6 and 1.5.10.x boot to the same kernels that run fos and do the inventory and imaging, so if that worked in 1.5.10.x it should work in 1.6.
Are you creating a 'multi-disk' image and it all worked as you expected before and the only thing that changed is 1.6?

[Jackske1976]

The problem is it was during a crash from an older version 1.5.X i did a clean install. so did i install 1.5.10 first on my computer. I did try to take a multi disk image. and the same thing happens after formatting and re-installing ubuntu.

[mastacontrola]

I suspect your nvme is setup in "RAID" mode on the bios rather than as "AHCI" which is likely why you're not seeing the nvme drive.

[Jackske1976]

I did try AHCI and it just did the same. i did try it on a different machine also AHCI in bios enabled an it using sata HDD's (6 drives) with no RAID card or something else like that but the only drive that gets found is dev/sdb. I can make an image of dev/sdb with no errors at all. So fog works so far, but i cant image dev/sda. I am going to reformat the fog server again. Install ubuntu server 24.04 once more or an different linux distro. Or is it a problem to mount that i have mounted a HDD to the /images folder with fstab and the source files copied to the new drive. if i use mount -t nfs -o vers=3 192.168.0.253:/images /mnt/test to test the read and write function that is working correct. It just stumps me

[mastacontrola]

So I don't know what you mean be /dev/sda or /dev/sdb

Unless when you're saying "NVME" == "SSD Sata Drive" /dev/sda absolutely should exist, BUT:

Serialized devices come up in the order of first powered and present... There's no guarantee that what's /dev/sdb today is the same /dev/sdb tomorrow. (This goes for any serialized device, including SCSI, NVME, etc...)

While a SCSI technically has the ability per channel (and all things in the same line channel can get consecutive names - this is highly unusual for most scenarios) this is still per Channel. If Channel 9 came up first, it gets /dev/sda, followed by the next in the line and so on and so forth.

The same problem occurs on NVME, USB, etc....

USB, SCSI, SATA (Serial ATA) will always be registered in the first come first serve order. /dev/sda this boot may be the USB, next boot may be the SATA, and the boot after that may be the SCSI.

For NVME they will always have an nvme naming scheme. /dev/nvme0n1 or something like that. In this scenario, they're still considered serialized in that the PCI slot power up order is followed. So what may be /dev/nvme0n1 this power on, may be /dev/nvme0n2 next time, and so on.

For MMC they will always have an mmc naming scheme. /dev/mmc0 and it follows similar to serialized ordering.

Sorry, not trying to give a whole lesson as I'm not an expert by any means, just trying to give context that what you keep referring to is not really meshing with things.

When you set the SATA mode to AHCI, that should work. I suspect your NVME may have a similar setting assuming it isn't controlled by the SATA side of things already.

This is why they started providing grub/fstab with UUID formats to recognize the drive because there was no guarantee that a specific drive (in multi drive setups as is much more common today) would be the same label between boots.

[Jackske1976]

My dell laptop has AHCI enabled and i have 2 sata drives one sata ssd and the other one is a sata hdd if i disconnect the sata hdd then the sata ssd is being recognised as dev/sda during inventorisation. If i reconnect the sata hdd and remove the client under fog's beautiful web interface and rerun the step to inventarise the computer then fog finds the HDD as dev/sdb and dev/sda the sata ssd is now where to be found. that applies to every computer. I have a computer with 6 drives with one raid partition on 2 drives that i know of. the other 4 drives are single disks. and fog when i inventarise only one gets found and that is dev/sdb. the other 3 are now where to be found... And I do love FOG.

[Jackske1976]

I found an fix on my issue to boot in the fog debug enviroment and i did apply the following bit of code:

On line 303 of storagenode.class.php
There is this bit of code

     return preg_grep(
        '#dev|postdownloadscripts|ssl#',
        json_decode($response[0], true),
        PREG_GREP_INVERT

I swapped with the following code below

$data = [];
if (isset($response) && is_array($response) && isset($response[0])) {
$tmp = json_decode($response[0], true);
if (is_array($tmp)) $data = $tmp;
}
return preg_grep('#dev|postdownloadscripts|ssl#', $data, PREG_GREP_INVERT);

(im sorry but it works :) I am NOT a programmer. And i dont know what exactly it does)
That gets me in the debug enviroment where i did perform a ls -l /dev/sd
That gives the following /dev/sda .. sda1 .. sda2 ..sda3 and /sdb /sdb1

So back to my question why fog or fos skipping my drives?
I Appreciate Your Help!

[Jackske1976]

I did buy a new router with option 66 and 67. And i do hope that fog works again :) thank you for the help!
And if you have the option to delete my issue I will be grateful.

[mastacontrola]

So i'm not really sure which issue to address here:

What you're describing I believe has been addressed here: https://github.com/FOGProject/fos/releases/tag/EXP_20250919.

Would you please attempt to use that file and see if your drives are ordered as expected?

I believe the issue you saw which seemed like it was skipping random devices was more likely using the "largest" drive in the list as your "primary".

[Jackske1976]

I am gonna try that in the following days, and retest FOG. Thank you for the answer.

[Jackske1976]

I did build fos with x86-x64 arch and copy the fresh build of EXP_20250919's bzImage to the correct folder. And fog is detecting the larger drive as /dev/sdb1 not as /dev/sda1 but still picking the larger drive as primary. The host primary disk setting is empty to test if I set it to /dev/sda then sda will be imaged. The only thing i bump into is that when i set the host primary disk to /dev/sda fog will capture /dev/sda drive twice with all partitions and when I restore the drives it will write twice back too. I can live with that.

[mastacontrola]

The double capture is fixed in FOS (FOGProject/fos#173): with Host Primary Disk set, the named disk was never removed from the pool of remaining disks, so it was captured a second time as the "next" disk. That is why /dev/sda came out twice.

Could you try the experimental init from https://github.com/FOGProject/fos/releases/tag/EXP_20260902-204611? Put its init.xz (and init_32.xz if you have 32-bit clients) in /var/www/html/fog/service/ipxe/ on the server, keeping a copy of the current ones, then recapture with Host Primary Disk set. Each disk should be captured once, the named one first.

The same build also stops FOS picking a USB or removable device automatically while an internal disk exists, so the SATA drive should be chosen even without Host Primary Disk if the other device was USB-attached.