HP Z640 - NVME PCI-E Drive

[JJ Fullmer]

Wasn’t able to boot to a live cd just yet but I tried some other stuff.

I tried changing the primary hard disk to /dev/nvme0
because I figure that may be the new /dev/sda
When I tried to image the computer I got a new error

“Erasing Current MBR/GPT Tables… The specified path is a character device!
Warning! GPT Main header not overwritten! Error is 22
Warning! MBR not overwritten! Error is 29
Corrupted partition table was erased. Everything should be fine now”

It does still get through the hardware inventory, but in either case it doesn’t pull and hard disk information.
I’m going to try /dev/nvme next to see if that works.

I also tried changing the bios sata disk mode from RAID to AHCI, but I don’t know if that effects anything on an nvme drive since it’s plugged into pci-express.

Thanks for all the help thus far.

-JJ

[george1421]

I think I would still go down the live boot path. Just get ubuntu 15 desktop iso and burn it to CD. Then boot from the CD, there is an option to try it first (or something like that). I would be interested to know what a production kernel reports. But /dev/nvme0 would be a sane name for that hard drive.

[Tom Elliott]

I think it’s related to another thread where it’s not seeing the major number properly.

[george1421]

@Tom-Elliott Is that info posted somewhere for historical/debugging reference in a non-volatile location?

[Tom Elliott]

@george1421 https://forums.fogproject.org/topic/6036/hp-stream-11-pro

[Tom Elliott]

I’m currently at an appointment so it can’t do anything to fix this right now I just wanted to ensure you all know I’m aware of the issue for right now.

[JJ Fullmer]

I looked through the other post and gave debug mode a try,
I ran lsblk and got the same disk info except it didn’t have any mount information.
But is said nvme0n1 and partition nvme0n1p1

[JJ Fullmer]

Did a debug deploy
I found that fog saw the partition name as /dev/nvme0n11 instead of what was listed in gdisk -l /dev/nvme0n1p1
tried to change the name to no avail.

[george1421]

@Arrowhead-IT Hey, just wanted to let you know this is all great information. The more details the devs have the better solution they can come up with. Its impossible to have every bit of hardware in the test lab that exists in the wild. So it is key to get support from the user community to help build a better mousetrap.

[JJ Fullmer]

@george1421 That’s what I figured, it seems an odd problem so I’m going to give all the info I can to help find the problem. And plus, these nvme drives think that they are going to become the norm and phase out sata, sas, and scsi, so I’ll do whatever I can to help get FOG working with them.

[Sebastian Roth]

@Arrowhead-IT Thanks for providing information about those devices and helping us. Can you please run another debug session and post the full output of lsblk -pno KNAME,MAJ:MIN -x KNAME? We need the exact output (especially dev names - which you already provided - AND the IDs. Just take a picture and post it here if you don’t want to bother about typing it all.

[JJ Fullmer]

@Sebastian-Roth on it

[JJ Fullmer]

@Sebastian-Roth Here ya go

I think that one possibility of the problem lies in the variable dump from fog.
It lists the partition as /dev/nvme0n11 but fdisk -l or gdisk -l lists it as /dev/nvme0n1p1

[Sebastian Roth]

@Arrowhead-IT Great! Thanks again. I am sure @Tom-Elliott will push the fix pretty soon. Should be fairly easy in your case. But I am a bit worried about these ‘mmcblk0rpmb’ device from the other thread! Tom, should we only look at minor ids smaller than 8?? Might cause issues with GPT systems??

[JJ Fullmer]

@Sebastian-Roth @Tom-Elliott Is there a timeline on when you think this issue will be fixed?

Please and thank you

[JJ Fullmer]

@Sebastian-Roth @Tom-Elliott
I updated to the latest trunk since I noticed one of the commits said that it had adjusted the way partition numbers were found. But sadly it still isn’t working. I will try making it a raw image to see if that works as a workaround like it did for the other person with this problem with the m.2 drive. The debug information lsblk and for variable dump all still have the same information.

Thanks,
-JJ

[Sebastian Roth]

@Arrowhead-IT We are working on this and try to get this fixed for mmcblk devices as well (another thread). Unfortunately those devices are even more special than your nvme drive but pretty similar naming-wise! As we are all doing this in our free time there is no timeline I can give you. We are onto it and I hope we can give you something to test in the next couple of days. So please bare with us.

[Tom Elliott]

@Arrowhead-IT i did indeed push a commit that changes how the partitions are numbered but I have not yet put those files into the init. There is a lot of work to go through with it and I don’t want to push something that will break already working imaging right now.

[Sebastian Roth]

@Arrowhead-IT Here we go. I found some time to look into this more closely!
Download init.xz/init_32.xz test files from https://drive.google.com/folderview?id=0B-bOeHjoUmyMazJLZDhGaEl5VTQ&usp=sharing and put into place in /var/www/fog/service/ipxe/ or /var/www/html/fog/service/ipxe/ (probably a good idea to rename the original files instead of just overwriting them!)

Please test and report back if capturing/deploy is working (Image type: Multiple Partition - Single Disk, Host Primary Disk: /dev/nvme0n1).

[JJ Fullmer]

Awesome! I’m giving it a try right now. And my apologies if I seemed impatient in my asking, I was just curious and getting all excited.
I currently only have one image and it is a resizable one, we’ll see what happens.

Thanks,
-JJ