Lenovo x1 Gen 4 - NVMe with GPT partition
-
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.
-
Thank you.
-
@wcheung Assuming the upgrade helped?
-
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
-
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)”
-
@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.
-
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.
-
@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 Captain Obvious: “Well that stopped exactly where you said it would.”
- There are not other errors after that?
- 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
- In the fog settings turn up logging level to 7, that may produce more intelligent error messages.
-
No, it just sits on that screen. I’ve waited 15-20 mins,
-
@wcheung even when you go into the FOG server and boots the logging to 7 then reboot and try to image again?
-
Updated firmware, and turned logging level to 7 and still got the same results. No additional error messages then the screen shot sent earlier.
-
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.
-
@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.
-
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.
-
@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.
-
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 ?
-
@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).
-
Oh no I want to figure this out and i sure other people out there with Lenovo X1s will come across this issue. Plus I like the fully automated service FOG provides.
I will try the USB FOS suggestion.
