Lenovo x1 Gen 4 - NVMe with GPT partition
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)
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.
So it is all good, I got the USB FOS disk working, but no need. All I had to do was use the OneLine+ Ethernet adapter and it resolved all my issues. I was able to capture and deploy images with in 2~5 mins. This X1 Gen 4 was a big headache but this PCIE 3.0 x4 SSD should be worth it… I hope.
This post is deleted!
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?
This post is deleted!
@wcheung In the link that Tom posted [ https://forums.fogproject.org/topic/7302/lenovo-thinkpad-yoga-260-w-lenovo-thinkpad-usb-3-0-ethernet-adapter-fru-03x6903 ] The Op just posted he has success with a Yoga and ThinkPad in uefi mode using a Onelink+ to rj45 adapter. It may be worth your while to review his thread.
Just trying to link some relatively similar threads. In the hopes, of course, they may contain helpful information or at least show we’re not sitting around.
@wcheung maybe I missed it but have you simply tried adding
has_usb_nic=1to kernel args?
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.
@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).
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 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.
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 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.
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.
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 even when you go into the FOG server and boots the logging to 7 then reboot and try to image again?
No, it just sits on that screen. I’ve waited 15-20 mins,
@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.