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

[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/)

[Tom Elliott]

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

HDIO_GET_IDENTITY failed: Inappropriate ioctl for device

https://opensource.com/article/21/9/nvme-cli

May need to see if we have nvme-cli on the FOS systems.

Specifically you would use nvme list /dev/nvme0n1 and should provide details.

Trying to figure out what we’d need.

Maybe something like:

hdinfo=$(hdparm -i $hd 2>/dev/null || nvme id-ctrl $hd | awk  '/mn[ ]+:/ {split($0, model, ": "); modelno = model[2]} /sn[ ]+:/ {split($0, serial, ": "); serialno = serial[2]} /fr[ ]+:/ {split($0, firmware, ": "); fwrev = firmware[2]} END {gsub("^[[:space:]]+|[[:space:]]+$", "", modelno);gsub("^[[:space:]]+|[[:space:]]+$", "", fwrev);gsub("^[[:space:]]+|[[:space:]]+$","",serialno);print "model="modelno",fwrev="fwrev",serialno="serialno}')

[Tom Elliott]

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

nvme list $hd | tail -1 | awk -F" {2,}" ‘{print “model=”$4",fwrev=“$8”,serialno="$NF}’

@AlexPDX Can you try running the command:

nvme list /dev/nvme0n1 | tail -1 | awk -F" {2,}" '{print "model="$4",fwrev="$8",serialno="$NF}'

[AlexPDX]

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

nvme id-ctrl /dev/nvme0n1 | grep mn

This one worked
[Thu Mar 16 root@fogclient /]# nvme id-ctrl /dev/nvme0n1 | grep mn
mn : KINGSTON SNV2S250G
mntmt : 273
mnan : 0

[AlexPDX]

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

nvme list /dev/nvme0n1 | tail -1 | awk -F" {2,}" ‘{print “model=”$4",fwrev=“$8”,serialno="$NF}’

this returned :
model=1,fwrev=512,serialno=ELFK0S.4

And :

smartctl --info /dev/nvme0n1 | grep Model
returned:
Model Number: KINGSTON SNV2S250G

[Sebastian Roth]

@AlexPDX @george1421 @Tom-Elliott Great we got this figured out. Please let us discuss the details on github: https://github.com/FOGProject/fos/issues/72

[Tom Elliott]

@AlexPDX can you try:

nvme id-ctrl /dev/nvme0n1 | awk  '/mn[ ]+:/ {split($0, model, ": "); modelno = model[2]} /sn[ ]+:/ {split($0, serial, ": "); serialno = serial[2]} /fr[ ]+:/ {split($0, firmware, ": "); fwrev = firmware[2]} END {gsub("^[[:space:]]+|[[:space:]]+$", "", modelno);gsub("^[[:space:]]+|[[:space:]]+$", "", fwrev);gsub("^[[:space:]]+|[[:space:]]+$","",serialno);print "modelno="modelno",fwrev="fwrev",serialno="serialno}'

[AlexPDX]

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

nvme id-ctrl /dev/nvme0n1 | awk ‘/mn[ ]+:/ {split($0, model, “: “); modelno = model[2]} /sn[ ]+:/ {split($0, serial, “: “); serialno = serial[2]} /fr[ ]+:/ {split($0, firmware, “: “); fwrev = firmware[2]} END {gsub(”^[[:space:]]+|[[:space:]]+$”, “”, modelno);gsub(”^[[:space:]]+|[[:space:]]+$”, “”, fwrev);gsub(”^[[:space:]]+|[[:space:]]+$”,“”,serialno);print "modelno=“modelno”,fwrev=“fwrev”,serialno="serialno}’

modelno=KINGSTON SNV2S250G,fwrev=ELFK0S.4,serialno=50026B7685F13C1E

[AlexPDX]

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

updating to the latest release 1.5.10

…i did this and i think i messed up my server
fog_error_1.5.10.log
foginstall.log

…can someone please help me with the correct steps to update fron 1.5.9 to 1.5.10 ?

Im trying to access the Web GUI but nothing happens …just a blank page

[Sebastian Roth]

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

…can someone please help me with the correct steps to update fron 1.5.9 to 1.5.10 ?

Sorry for the late reply. From the logs it looks like it just bailed out when trying to create a symlink to the log files. I have never seen this happen before. Please issue the command rm -rf /var/log/fog (as root) and then re-run the installer.

[AlexPDX]

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

command rm -rf /var/log/fog (as root) and then re-run the installer

Ok so that did the trick, i was able to finish the installation without getting error messages, but, at the last step where i have to :

• You still need to install/update your database schema.

• This can be done by opening a web browser and going to:

  http://192.168.192.111/fog/management
  …the web page gives me the “192.168.192.111 is currently unable to handle this request. HTTP ERROR 500” error

If i press Enter in the SSL terminal, the installation finishes but i get the same error 500 when im trying to connect on the Web Page of this server
Here are the .log files (Btw, dont mind the HQ-GL.zxzxzx.zxzxzx) :
www-error.log
httpd_error.log
php-fpm_error.log
i don’t see any issues here :

[Tom Elliott]

@AlexPDX at 169, remove the , you see there.