Dell 3510 with USB-C

  • I’m having trouble capturing an image of Dell Precision 3510 with USB-C. These have nvme SSDs. We have Dell 3510’s without USB-C that I got working in FOG 1.2 with the newest kernel downloadable through the menu. The image type was Multiple Partition - Single Disk.

    The newer 3510s have USB-C and the BIOS cannot be downgraded to match the prior 3510s we have.

    I decided to upgrade to the trunk version of FOG (Ubuntu 14.04.4 LTS) and as I’ve read it works better with nvme disks. When trying to capture an image I get the following screen. Changing the image type doesn’t seem to help.


  • Could it be that was a RAW image deployment error vs a multiple partition image deployment? Yes, imaging is going well.
    We had to downgrade the TPM from 2.0 to 1.2, since we are not doing UEFI.

  • Developer

    @JBeene said:

    Got the following message:

    In that picture I see Args passed: /dev/nvme0n while it should be nvme0n1 I guess?!? Bu you are saying things are working now?

  • Image looks to be working now. Read up on the new Fog Client before I recorded my sysprep. I really appreciate all the help!

    I’ve ran into dirty partition issues before. I should’ve known I should go over the initial Dell partitions with badger blood and napalm before I build my image.

  • 3510nosysprep is the image name.

    Ran the debug and did a fixpart. It said it found remnants from a prior partition, I removed that, and then selected A for MBR option. It seems to have not wrecked data on the drive and booted back into the Audit Mode for Windows 10.

    Recorded image using Multiple Partition - Single Disk No resize. Since there was no errors with that, I then put that image on another machine. It also booted up into Audit mode. I’ll run my sysprep file then record the image again and see how it works. Thank you for the help so far.

  • Senior Developer

    @JBeene What does the file look like on your server?

    Is it in /images/3510nosysprep or is simply a file named /images/3510nosysprep?

  • Moderator

    @JBeene Then on the one that failed to image. Schedule another deployment, but on the task setup window select the check mark for debug deployment. Start to image the broken target. After a bunch of text on the screen it should drop you to a command prompt on the target computer. This is the debug console.

    Now follow Wayne’s post about the fixparts command. Test to see if this fixes the disk structure on the broken target computer. After running the fixpart command key in fog and press enter. You will have to press enter after each fog step, but see if you can get all the way through imaging. If not we’ll probably need you to boot into the debug console again to run some disk inspection commands.

  • @george1421 I have several for testing, until I get the image built.

  • Recorded RAW image and then tried putting it on another laptop of exact specs.

    Going to do a debug capture next.

    Got the following message:

  • Senior Developer

    @george1421 I think @Wayne-Workman is right.

    If we need to be 100% safe, maybe try uploading a separate image under “raw” type and then try fixparts?

  • Moderator

    @Wayne-Workman The concern with fixparts is if it is destructive to the current disk content(??). I get the impression that the OP wants to capture the image off storage, so we don’t want to disrupt the disk structure.

  • Senior Developer

    @Wayne-Workman I didn’t see the full picture until now. I think you’re spot on.

    This used to not happen with Non-resize disks (at least not that I’m aware of.)

  • Moderator

    @george1421 FOS typically hangs at this spot when GPT remnants are present. Debug + fixparts /dev/nvme0n1 in this case will typically fix it.

  • Moderator

    @JBeene For debugging purposes you will need to resetup an image capture, but before you hit the save task, you want to select the check box to do a debug capture. This will download FOS to the target computer, display some text and then drop you at a command prompt after a few presses of enter.

    From there we need to find out what FOS is running at the Saving original partition table command to see where its hanging.

    Do you have a couple of these to test on, or is this current one the only one you have?

  • @Tom-Elliott Haha, I didn’t say what it wasn’t doing. So it gets to the point in the screenshot and doesn’t get past that part (left overnight). Below is the screenshot when setting it to Single Disk - Resizable. I’ve also tried Multiple Partition Image - All Disks.


  • @george1421 Secure Boot is disabled. I have it disabled to do Legacy boot and PXE Boot.

  • Senior Developer

    As the hardware post says you’re trying non resize , maybe you can try doing resize now?

  • Moderator

    [edited] Didn’t read OP well enough.

    While this is not in the booting process, please check to see if secure boot is disabled.

  • Senior Developer

    Looks to me like it’s working at least based on what we see. What is it doing/not doing?

Log in to reply

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.