Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify

[AlexPDX]

Hello Dear Community
I have an 1.5.9 version of FOG , with bzImage Version: 5.15.19 and bzImage32 Version: 5.15.19
The issue that i’m facing is for the newest models of Mother Boards for the Hardware Inventory :

• System Manufacturer > ASUS
• System Product > System Product Name
• Hard Disk Model > (BLANK)

Also for the :

• System Manufacturer > Gigabyte Technology Co., Ltd.
• System Product > H510M S2H V2 / H510M H / H410M H V3 / H610M H DDR4
• Hard Disk Model > (BLANK)

I have no problem deploying the UEFI W10x64 image…but :
…basically any MB with Intel 11th and 12th gen CPU and M.2 nVme , FOG can’t detect the Hard Disk Model
Is there any way to make this work ?
I have around 350 hosts with DELL PC…and im planing to upgrade them…and it would be nice to know exactly what Storage Model is on what host…

[george1421]

@AlexPDX Change the disk controller mode from raid-on to ahci mode and linux will detect the drives behind the controller. This is an age old issue with intel-rst disk controllers.

[AlexPDX]

@george1421
…it dose not Work…all the BIOS setings apear to be in order…i can do DEPLOY or UPLOAD but i don’t get the NVMe model…
i will attache some photos :

[Sebastian Roth]

@AlexPDX I suggest updating to the latest release 1.5.10 or manually update your kernel.

In the other hand I think @george1421 is totally right about the AHCI mode thing.

[AlexPDX]

@Sebastian-Roth said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:

update your kernel

I did this, manual update the kernel, restart the FOG Server, inventoried another Gigabyte MB with NVMe but no luck…


I will try updating from 1.5.9 to 1.5.10 any i will be back…
About the Intel RST and Secure Boot and SATA Controler mode on AHCI > i’ve checked and double-checked all and everything is set correctly

[Sebastian Roth]

@AlexPDX Please wait before you update. Maybe I got this the wrong way. It’s just the inventory information missing in the FOG web UI??

[george1421]

@AlexPDX Lets debug this a bit more then. If you have the target computer registered in FOG, then lets setup a debug capture or deploy doesn’t matter. So schedule a deploy task but before you hit the schedule task button tick the debug checkbox.

Now pxe boot the target computer. After a few screens of text that you have to clear with the enter key you will be dropped to the fos linux command prompt.

This next section is optional but will help with debugging so that you can copy and paste info a bit easier., Key in ip a s and get the IP address of the target computer. Next key in passwd and give root a password. Make it something simple like hello, no worries it will be reset when FOS Linux reboots. Now ssh or use putty to connect to the target computer using the IP address, user id of root and password you just set. This remote console will let you copy and paste.

Now key in/paste the following info:
lspci -nn | grep -i sata
lspci -nn | grep -i raid
grep -i firm /var/syslog

Post the results here. The lspci commands will let us see what disk controller is being reported and the last will look to see if there is any missing firmware statements posted by the kernel.

[AlexPDX]

@george1421 Ok , ill do this…sorry for the late reply …i’m actually Help-desk Support in the company i work so yea…a lot of “Hello, IT, have you tried turning it OFF and ON again” …i just love FOG and makes things better 4me

ill be back after the debugging

[AlexPDX]

@Sebastian-Roth Exactly , in the web UI , hosts with SATA SDD’s , are acknowledged …hosts with NVMe SSD > not
The same Motherboard , if i attache SATA SSD and do a HW Inventory, it works fine …but if i attached the NVME M.2 SSD > the Hard Disk is BLANK just like in the attached images

[AlexPDX]

@george1421 ok so i got this :

[Thu Mar 16 root@fogclient ~]# lspci -nn | grep -i sata
00:17.0 SATA controller [0106]: Intel Corporation Device [8086:43d2] (rev 11)
[Thu Mar 16 root@fogclient ~]# lspci -nn | grep -i raid
[Thu Mar 16 root@fogclient ~]#
[Thu Mar 16 root@fogclient ~]# grep -i firm /var/syslog
grep: /var/syslog: No such file or directory

but i did found this “messages” in /var/log of it helps : messeges.txt

[george1421]

@AlexPDX From the log it looks like the nvme is detected. At the fos linux command prompt key in lsblk and post the results. That should show us the block devices (i.e. hard drives attached)

[AlexPDX]

@george1421 said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:

From the log it looks like the nvme is detected. At the fos linux command prompt key in lsblk and post the results. That should show us the block devices (i.e. hard drives attached)

[Thu Mar 16 root@fogclient /]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nbd0 43:0 0 0B 0 disk
nbd1 43:32 0 0B 0 disk
nbd2 43:64 0 0B 0 disk
nbd3 43:96 0 0B 0 disk
nbd4 43:128 0 0B 0 disk
nbd5 43:160 0 0B 0 disk
nbd6 43:192 0 0B 0 disk
nbd7 43:224 0 0B 0 disk
nvme0n1 259:0 0 232.9G 0 disk
|-nvme0n1p1 259:1 0 100M 0 part
|-nvme0n1p2 259:2 0 16M 0 part
|-nvme0n1p3 259:3 0 996M 0 part
`-nvme0n1p4 259:4 0 231.8G 0 part
nbd8 43:256 0 0B 0 disk
nbd9 43:288 0 0B 0 disk
nbd10 43:320 0 0B 0 disk
nbd11 43:352 0 0B 0 disk
nbd12 43:384 0 0B 0 disk
nbd13 43:416 0 0B 0 disk
nbd14 43:448 0 0B 0 disk
nbd15 43:480 0 0B 0 disk

[george1421]

@AlexPDX Is this output from fos linux?

the nbdX devices have me confused.

On the NVMe side we can surely see the nvme disk is there and it has 4 partitions .

Rereading your initial post, is it that FOS isn’t returning the hard disk model name, or it can’t image the computer?

ref: /dev/ndbX devices: https://medium.com/@aysadx/linux-nbd-introduction-to-linux-network-block-devices-143365f1901b

[Tom Elliott]

@george1421 From the looks of things and @AlexPDX please keep me honest:

This isn’t a problem from imaging. Simply the HDD information for the inventory isn’t present.

So while sure it’s weird that we can’t detect the drive type for the inventory, it’s not really hurting anything at the present as the Inventory is just an informational thing.

dmidecode (which I believe is what pulls all the inventory data) might just not know how to detect the specific information from that NVME either because the manufacture didn’t fill out the items that dmidecode is looking for, or is using a different language that can’t be utf decoded.

Just my thoughts.

Ultimately, there’s not really a “problem” persay. Just that the inventory can’t pull the information from this NVME device?

(I believe for HDD we use hdparm and all that jazz)

[Tom Elliott]

@Tom-Elliott This is the location of the “get hard disk” elements:

https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L1405

This is the code that stores the hd returned from above link:
https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L106

To try to get information from it.

Since nvme0n1 is the drive, you could manually attempt running:
hdparm -i /dev/nvme0n1 to see what returns in the debug prompt?

[Sebastian Roth]

@Tom-Elliott said:

dmidecode (which I believe is what pulls all the inventory data) might just not know how to detect the specific information from that NVME either because the manufacture didn’t fill out the items that dmidecode is looking for, or is using a different language that can’t be utf decoded.

Pretty sure Tom is right here. Just had a quick look at the scripts and turns out we use hdparm (code ref) which might not be able to grab the information from NVMe disks per se.

@george1421 said:

the nbdX devices have me confused.

You are right. I am wondering if we added this kernel feature when updating to a newer LTS line at some point. I don’t think we need it. Though it’s always good to make sure. So here is the github commit that introduced those features years ago when we moved from 4.5.x to kernel 4.7.x: https://github.com/FOGProject/fos/commit/b56b8d9f6356f6e702e6ff580b2c4500f27ac41f#diff-15f9b0e5270fc1caac75f8b936c3df11534ceeb08de376b7a72b38c75ff2ad1aL1122

@Tom-Elliott Do you remember if this was added for a reason? Not saying this is an issue at all. Just wondering if we might think about removing it to further slim down the kernel binaries?

[Tom Elliott]

@Sebastian-Roth Those are network block devices. I don’t remember exactly why it was added, but it seemed a necessity.

I’ll try to re-review the why.

[AlexPDX]

@Tom-Elliott said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:

Ultimately, there’s not really a “problem” persay. Just that the inventory can’t pull the information from this NVME device?

That’s exactly what my problem is…i have over 300 host managed by FOG …i use a lot of snap-ins, imaging, and specially Hardware Inventory so i know exactly what that host has in order to deploy the MBR or UEFI image, without having to physically travel to that host…only in case of hardware change (RAM, SSD or the whole PC).
And there is also an “internal managing” issue …each PC has an bar code and we do the “handover report” , so, each PC has his own bar code, but some of them are slightly different one from each other, by RAM or SSD or NVME…and i need to know that

[AlexPDX]

@Tom-Elliott said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:

hdparm -i /dev/nvme0n1

HDIO_GET_IDENTITY failed: Inappropriate ioctl for device

[Sebastian Roth]

@AlexPDX said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:

HDIO_GET_IDENTITY failed: Inappropriate ioctl for device

Yes, surely we need to use a different command to get that information, e.g. nvme id-ctrl /dev/nvme0n1 | grep mn or smartctl --info /dev/nvme0n1 | grep Model (https://sleeplessbeastie.eu/2022/03/21/how-to-display-information-about-nvme-storage-device/)