SOLVED m.2 PCIe SSD not recognised in FOG

  • Hi guys,

    Have an interesting one here.

    Has anyone tried or been able to image to/from an m.2 PCIe SSD?

    I’ve got a new DELL XPS 13 9350 which is an upgrade from the previous model that uses a regular SSD. I’ve been able to image the DELL XPS 13 9343 without any problems (with the setting in BIOS set to Legacy).

    Anyways, I’ve not been able to get FOG to capture an image from the PCIe SSD.

    What I’ve done to the XPS is…

    Set BIOS to Legacy
    Updated to the latest BIOS from the DELL Support site.
    Installed Windows 10 from scratch wiping all existing partitions and allowing the installer to create its own partitions (2 were created).

    When it comes to PXE booting off the DELL USB NIC (Realtek RTL8153)… if I try using undionly.kkpxe, it gets stuck at loading bzImage at 0%.
    If I try to use any of the .efi pxe images, it goes through the motions until it tried to detect for a HDD but fails and says…

    Looking for Hard Disk....
    An error has been detected!
    Cannot find HDD on system
    Computer will reboot in 1 minute.

    So just seeing if anyone has had any experience with PCIe SSDs?


  • @Tom-Elliott @Arrowhead-IT @george1421 Thanks. I might stop make it work with 1.2 then!
    I did try to upgrade to 1.2 and it just broke everything so I reverted back to 1.2
    I tried setting up a new server running CentOS 7 and fog trunk but it’s not working either, just getting a blank page when trying to access the console towards the end of the install to set up the DB.
    Anyway. I’ll try and set up a trunk version again!
    Thanks for your help

  • Testers

    @onepotato NVME works on trunk for all partition types. I tested it myself 😃
    you can read more about the adventure to getting it working here…

    Or you can just trust me, it will work and follow the following instructions to upgrade your fog version

  • Moderator

    @onepotato Are you running the trunk build of 1.2.0 (a.k.a 1.3.0 beta) or just 1.2.0 stable?

    With these memory disk devices, you would be better off upgrading to the trunk build since there has been great strides taken to fix these memory disk devices.

  • Senior Developer

    @onepotato You may want to upgrade to trunk, as 1.2.0 is not very good with anything labeled other than /dev/{h,s}d* devices.

  • hello, i’m having the same issue with a Samsung SM951 PCIe NVMe as Toby777’s post below.
    The only thing that works is ‘raw image’, otherwise i’m getting the same error as Toby777.
    I tried different init.xz and init_32.xz as suggested in other posts to no avail.
    Running Fog 1.2 on CentOS 6. Any ideas? Thanks!

    @Toby777 said:

    Hi Tom,

    Got the Dell tech to replace the motherboard today.

    Latest Fog trunk now recognises the nvme SSD.

    When the Image is set to Single Disk - Resizable, it hangs at…

    * Saving original patition table......................

    When Image is set to Multiple Partition Image - Single Disk (Not Resizable), it hangs at…

    * Now FOG will attempt to upload the image using Partclone
    * Processing Hard Disk: /dev/nvme0n1

    When Image is set to Raw Image, it starts the upload…

    I’m fine with using Raw Image if that’s what works. 🙂

  • This post is deleted!

  • @Tom-Elliott Thanks Tom, have updated and performed an upload using Single Disk Resizable and it uploaded without any errors.

    I also then performed a deployment task of the Image and it was successful, windows boots up fine etc… just saw it come up with an error about changing the hostname.


  • Senior Developer

    All republished.

  • Senior Developer

    @Toby777 thank you again. I found the issue that error was spewing out and am rebuilding inits again. Give it about 10 minutes and try updating again. This is very much appreciated.

  • @Tom-Elliott Hi Tom, running that command seems to have resolved the issue and it was able to successfully upload the image to the FOG server. This is while the image was set to Multiple Partition Image - Single Disk (Not Resizable)

    When I changed it to single disk - resizable, the below error appeared…

  • Senior Developer

    @Toby777 for that, I suspect you built the image as MBR? But the original format was in GPT. I’m just guessing as the message from the command you ran earlier seems to indicate a gpt linkage failure.

    Can you run fixparts /dev/nvme0n1 and let us know the output? I’d also recommend if it states it needs repair to approve and save the changes to the disk. Then run fog.

  • @Tom-Elliott Same error unfortunately 😞

  • @Tom-Elliott ok cool… will do that now.

    The output of the previous command was…

    Invalid partition data!
  • Senior Developer

    I believe I found, and hopefully fixed, this issue. Please re update and try again when you can. Thank you.

  • Senior Developer

    @Toby777 from debug what’s the output of:

    sgdisk -b "/tmp/d1.mbr" /dev/nvme0n1

  • @Tom-Elliott Hi Tom, I updated to trunk 6084 and did the debug testing as you requested. Screen shots below…

    Image set to Single Disk - Resizable

    Image set to Multiple Partition Image - Single Disk (Not Resizable)

  • @Tom-Elliott Thanks Tom. I’m currently interstate for this week so once I’m back at our main office next week, I will perform the testing.

  • Senior Developer

    @Toby777 I believe I found the hang accidentally. I too was seeing a hang on my side but I don’t know what was causing it. I edited more of the files and retested things and it looks like all is working if you’d be willing to test again. The suggestion I’d make is to schedule the tasking as debug (choose capture like normal and check the schedule as debug) first. That way you can get the info Sebastian is requesting. To perform the tasking at the cmd prompt just type fog. This should make you step through almost every phase so if things hang you can break out. It helps me a little as well as I can more clearly find out what is hanging.

  • Senior Developer

    @Wayne-Workman Thanks for the link but I don’t think we need this as we have a 4.x kernel already running. It seams to recognize the disk and partitions as we see in the lsblk output!

    @Toby777 Would you mind another debug session? Please run the following three commands and see if this hangs:

    udevadm settle
    blockdev --rereadpt /dev/nvme0n1
    sfdisk -l /dev/nvme0n1