Lenovo x1 Gen 4 - NVMe with GPT partition

[wcheung]

Re: HP Z640 - NVME PCI-E Drive

Hate to be the guys that tries to revive an old topic, but before I open a new tread I will like to see if I can ask questions on this first.

I have a Lenovo x1 Carbon that does BIO and UEFI that uses NVMe SSDs (PCIE 3.0 x4)

Using the stable 1.2.0 (I don’t mind trying 1.3.0 just started learning this system a week ago)

Kernel 3.19.3
init.xz init_32.xz Default

Everytime I deploy a new machine it states that the machine has no OS. I assume it is the way I am uploading the image.

My question is, is there a way to capture with UEFI only? and is there any changes I need to make to support NVME drives, as I did notice my disk label is nvme0n1p1 and nvme0n1p2

Please note I have a server running with identical set up with regular SSD with MBR partition versus GPT on these nvme drives.

[wcheung]

Hi @george1421,

So I think i figured it out, after creating the USB disk, before even using the FOS disk I went to test to make sure the problem still exists from yesterday.

Turns out… The USB Ethernet adapter was the problem. Its not so much it doesn’t work, it has to do with something with the MAC ID on the USB Ethernet adapter.

I’ve notice since day lets say M1 uses the usb ethernet adapter (by lenovo) and gets the MAC id, say MAC_1
then plug the same adapter into machine 2 (M2) fog will see it as only one host.

So the lesson here is… keep track of your usb ethernet adapters that have MAC ADDR on them. Lenovo has created different Ethernet adapters that don’t have Mac IDs on them.

Now the problem is after I select “Perform Full Registration” I get a black screen. Would this be Kernel related?

[george1421]

For NVMe drives you MUST use either 1.2.0-trunk (which doesn’t exist any more) or 1.3.0-RCx series. FOG 1.2.0 doesn’t understand the NVMe disk naming structure (nvme0n1p1) properly. This is outside the use of the kernel this is actually the changed in the code on the virtual hard drive (init.xz). And you can’t use the new kenrel and the new inits with fog 1.2.0 stable.

The issue is 1.2.0 only understand the older disk structure of /dev/sdX1 and it used the alpha parts to defined the disk and the number parts to define the partition. The NVMe disks broke that logic. Because there are numbers as part of the disk identifier so the internal logic broke down. The developers worked on this issue for several weeks to get it fixed in the trunk build.

[wcheung]

Thank you.

[Tom Elliott]

@wcheung Assuming the upgrade helped?

[wcheung]

Not yet. I will confirm once completed.

At the moment I am trying to configure 1.3.0 RC11 on an isolated network like I have done for my 1.2.0 Stable.

I feel like PacMan ever dot is a new obstacle . Will report back

[wcheung]

Update::

Almost there, I got 1.3.0 RC11 installed and configured /etc/dhcp/dhcp.conf and static IP for a isolated network.

MBR partition with traditional /dev/sdX) works fine.

Now testing with LEnovo X1 Carbon Gen 4 with UEFI only with GPT partitions on NVME SSDs

Results:
PXE over IPv4 looks promising, it sees the FOG server but It stops at

“bzImage… ok
init.xz… ok”

I will need to search the forum against

“waiting for link-up on net0… Down (http://ipxe.org/38086193)”

[Tom Elliott]

@wcheung What boot file are you using? I’ve seen this issue before and typically it’s due to the iPXE driver in use. If you’re using the ipxe.efi file, you may need to try snp.efi, or snponly.efi, or intel.efi, or realtek.efi.

I know I’m giving a lot of info, but each environment is different. There’s not simple way I can say “this” or “that” file will work for every machine.

[wcheung]

Morning Tom (West Coast here)

No no I understand its not an exact one size fit all. I am honestly not sure how to check which iPXE driver I would be using.

[george1421]

@wcheung Please take a picture with a mobile phone of the exact spot where it stops. Make sure it is a clear picture so we can pinpoint the exact spot in the process.

[wcheung]

[george1421]

@wcheung Captain Obvious: “Well that stopped exactly where you said it would.”

1. There are not other errors after that?
2. Have you confirmed that you have the latest firmware on this computer? We have seen flaky early release firmware from lenovo causing this type of error
3. In the fog settings turn up logging level to 7, that may produce more intelligent error messages.

[wcheung]

No, it just sits on that screen. I’ve waited 15-20 mins,

[george1421]

@wcheung even when you go into the FOG server and boots the logging to 7 then reboot and try to image again?

[wcheung]

Updated firmware, and turned logging level to 7 and still got the same results. No additional error messages then the screen shot sent earlier.

[wcheung]

So this machine comes with a unique ethernet adapter called OneLink Ethernet Adapter, I don’t have it available and I am currently using Lenovo USB Ethernet adapter which has worked for current and previous generation machines and windows 7 & 10 but in legacy mode.

I will try again tonight when I get that adapter.

[george1421]

@wcheung So nothing is executing once iPXE hands off to the FOS Engine kernel. In the /tftpboot directory in the fog server, there are other .efi files you can try. I’m going to suspect they will give you the same results, but it would be worth a try.

The next step I would say is to try to create a FOG USB boot drive. This will skip the pxe boot process (which seems to be working) and load the FOS engine right from the usb flash drive. In this case instead of using iPXE to boot, we will use grub to boot. The instructions are here:https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Once you build this usb boot drive, I want you to pick the last option which again debug to drop to a command prompt… Oh wait you are using FOG 1.2.0, that doesn’t support uefi firmware well or NVMe disks at all.

Still go ahead and build this usb flash drive. Its based on FOG 1.3.0, I’m interested to see if you can boot into the debug console and pick up an IP address. None of the other menus will work since your FOG 1.2.0 server is missing the needed backend to make it work. BUT, it will tell you if you will have a better chance with FOG 1.3.0 and this computer.

(as you can see as I think more about 1.2.0) Even of you could get the 1.2.0 FOS Engine to boot with the new kernel, the 1.2.0 inits won’t understand NVMe disk, gpt format, and marginally supports uefi. I really think if you have the resources available, you would be better off spinning up a new FOG 1.3.0-RCx FOG server.

[wcheung]

in /tftpboot do I back up default.ipxe (say default.ipxe_bak) and copy one of the other .efi and rename to default.ipxe?

No I am running 1.3.0 RC 11, I was running 1.2.0 last week and with much success so much so its on another dedicated machine and locked down.

[george1421]

@wcheung No, don’t touch the files in that directory. Only look to see the file names with .efi extension, then update your dhcp option 67. If you mess (rename/change) with any of the files in the /tftpboot you will break pxe booting.

OK then, I must have missed when you upgraded to 1.3.0. OK then I’m back on having you build a usb boot for the FOS Engine. We have seen certain firmware not support the handoff between iPXE and the FOS Engine. Both bzImage and init.xz get transferred to the target computer then nothing happens. We have seen this on one firmware where the screen freezes but the FOS Engine continues to work for capturing and deploying images. But I think its still the handoff from iPXE to FOS. To test this we created the FOS USB boot process which uses grub to handoff booting to the FOS Engine. If we can get the FOS engine to boot then we can deal with the usb ethernet adapter. There is a kernel parameter to usb nics that may need to be added, but again the kernel is not booting so the kernel parameter at this point is not important.

[wcheung]

So I haven’t had a chance to do the USB FOS Engine boot yet, but i did try something interesting… hear me out.

I set the machine, lets call it X1_1 from UEFI only to Legacy boot then proceed as normal. I was able to PXE boot and perform a full registration and capture an image.

Then on a second (identical machine) lets call this one X1_2 set it to Legacy boot, and deployed an image to it. Once completed I set the machine back to UEFI only and watch the machine boot up… and now I’m in Audit mode with all the app/updates performed in a Pre-Sysprep config just as I imaged it on X1_1.

I don’t think I would call this a win but it worked… your thoughts @george1421 ?

[george1421]

@wcheung That is one option and it will work (as you have seen). If you only have a handful of systems this may be an option so you don’t have to burn a lot of time trying to resolve this issue. This decision is up to you (time vs ease of use).