search

vmware / esx-boot

The ESXi bootloader
Other
66 stars 22 forks source link

mboot.efi fails with static IP #6

Open oizone opened 3 years ago

oizone commented 3 years ago

I'm running an environment which doesn't have DHCP available and need to use static IP for the UEFI HTTP boot. Dell R640 servers boot fine with static IP configured, but downloading boot.cfg fails as it seems that mboot.efi tries to initiate DHCP. Boot fails with error: Error in Dhcp4->Start: Timeout Error getting IPv4 address: Timeout Configuration error while parsing http://...file Fatal error: 15 (Not found)

Couldn't find any documentation on how to use mboot.efi with static IP HTTP UEFI boot, is this possible? If it's not possible now, I'd like to make it a feature request.

TimothyPMann commented 3 years ago

That should work, though it may not have been tested much. If has_ipv4_addr() returns EFI_SUCCESS the first time (and every time) it is called, DHCPv4 is not run. So if Dell provided a UI in the setup dialogs or the UEFI shell that lets you assign a static IP address, and you create a boot option that has an explicit boot URL in it, I would expect it to work. (If you only assign a static IP in ESXi itself, that won't be visible to the bootloader.)

I don't have a Dell machine handy, but when time permits I can try this on an HPE machine and confirm whether if it works there as intended.

oizone commented 3 years ago

Yes, I've configured following redfish properties in BIOS through ansible: PxeDev1EnDis: "Disabled" PxeDev2EnDis: "Disabled" PxeDev3EnDis: "Disabled" PxeDev4EnDis: "Disabled" HttpDev1EnDis: "Enabled" HttpDev2EnDis: "Disabled" HttpDev3EnDis: "Disabled" HttpDev4EnDis: "Disabled" HttpDev1VlanEnDis: "Enabled" HttpDev1DnsDhcpEnDis: "Disabled" HttpDev1DhcpEnDis: "Disabled" HttpDev1Uri: "http://10.37.0.26/{{ fqdn }}/mboot.efi" HttpDev1Protocol: "IPv4" HttpDev1VlanId: "{{ vlan }}" HttpDev1Dns1: "{{ dns1 }}" HttpDev1Dns2: "{{ dns2 }}" HttpDev1Ip: "{{ ip }}" HttpDev1Mask: "{{ netmask }}" HttpDev1Gateway: "{{ gateway }}"

So specific properties are that it's static ip in tagged VLAN. As said loading mboot.efi works completely fine, so static IP itself works. Once mboot.efi starts to load boot.cfg, it fails saying dhcp timed out. I can give access to Dell server in our lab if that helps.

TimothyPMann commented 3 years ago

Hmm, that sounds familiar. Actually the only reason that mboot.efi has code that can initiate DHCP at all is that I hit an issue (even with dynamic IP) where, although the firmware's UEFI boot manager had acquired an IP address and used it to load mboot.efi, once mboot.efi started, the NIC didn't have an IP address that mboot could use. It sounds like the same thing happened to you when you configured a static IP: somehow the static IP is available only to the UEFI boot manager, not to a bootloader that the boot manager starts.

oizone commented 3 years ago

So, is this an issue in the firmware or in mboot.efi? Meaning that does Dell need to fix this? Does this work on HPE for example?

TimothyPMann commented 3 years ago

I don't know if it works on HPE; I'll have to find time to try it. Deconfiguring the IP address before starting a bootloader might be a generic limitation or even an intentional feature of UEFI, though it is not documented in the UEFI spec. To understand why the IP address isn't there and find out if there is a way to recover it, I probably will also need to read the generic open source upstream UEFI code that the hardware vendors base their UEFI implementations on (namely Tianocore/EDK2). That is time consuming for me as there is a lot of code there that I'm not deeply familiar with, and it's not written in a very readable style. I am currently working on multiple other projects unrelated to UEFI HTTP boot, so I probably can't get to any of this soon.

oizone commented 3 years ago

If this is a by design limitation of UEFI HTTP boot, find it strange but let's assume it for a minute, then I assume it would be possible to pass the information through the uri? Bootloader already works different depending on it's name, bootx64.efi vs mboot.efi, so I assume similar model can pass the expected static ip info to it? using http://server/mboot.efi?ip=10.10.10.10&mask=255.255.255.0 as uri? Or if it can't be paramters, then workaround with the name, like http://server/mboot.10.10.10.10-255.255.255.0.efi wildcard on http server side can fix and always still return same original mboot.efi

oizone commented 3 years ago

And as info, I've opened severity 2 support request on VMware support on this, id 21206887703. I'll open a Dell support request also, if needed.

TimothyPMann commented 3 years ago

The bootloader doesn't work differently depending on its name.

oizone commented 3 years ago

Hmm, thought I had different behaviour in some of my tests when I didn't rename the bootloader to mboot.efi but used the original name bootx64.efi. But must have but something else, validated now and behaviour is the same with both names. Quite many changes ongoing at once in my lab. I'm opening a support ticket on this to Dell also, to validate that their firmware is working as per UEFI HTTP design on this part.

TimothyPMann commented 3 years ago

It occurs to me that there's another option that may work for you. ESXi also supports network booting directly from the installer ISO image, if your UEFI firmware is new enough (anything that supports UEFI HTTP boot should work). We probably should have documented this explicitly, since it's simpler to set up. Just put the ISO image on an HTTP server and configure the target machine to UEFI HTTP boot from the image's URL. When you do this, the firmware loads the entire image into memory and mboot accesses it as a ramdisk; mboot doesn't need an IP address.

Of course, when ESXi comes up, it won't have an IP address either. I don't know how you were planning to deal with that.

TimothyPMann commented 3 years ago

BTW, I looked at your SR 21206887703, and it seems that at some point VMware support could no longer reach you because your emails were bouncing due apparently to a forwarding loop. So if you stopped hearing updates at some point, that's why.

oizone commented 3 years ago

Using the ISO method would of course fix the boot itself, but since the point is in automated installation where each host requires it's own kickstart file, it would get very complicated since each host would need their own dedicated ISO. Doable sure, but in my opinion a bit messy workaround. Or do you see any other way of injecting the host specific kickstart file in this process? Regarding the SR, I'm not working for TietoEVRY as an internal employee anymore, so my email in that SR is not valid anymore. You can update my contact email there as onni@rautanen.me , if that SR is still alive and it helps to push this forward through that one.

TimothyPMann commented 2 years ago

Unfortunately I haven't found time to work on it. It would need a significant code change to mboot.

From: vopop123 @.> Sent: Wednesday, October 12, 2022 5:57 AM To: vmware/esx-boot @.> Cc: Tim Mann @.>; Comment @.> Subject: Re: [vmware/esx-boot] mboot.efi fails with static IP (#6)

⚠ External Email

Hi guys, did you find any solution for this issue? I'm facing the same one. Would be great, if you could share your findings. Thanks

— Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware%2Fesx-boot%2Fissues%2F6%23issuecomment-1276134112&data=05%7C01%7Cmann%40vmware.com%7C852431a82b40453fdf2608daac5141b2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638011762244274420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J3i39Ox5CPb%2Bkizm1%2FziIpP%2BYsiWHbcR2n0wyklF6Bc%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAILDEHLPSLSSP4OMKFAEDELWC2YR3ANCNFSM4ZR76V3Q&data=05%7C01%7Cmann%40vmware.com%7C852431a82b40453fdf2608daac5141b2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638011762244274420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T2UpbAQ4x2%2B3IVXXFR%2B3IbWNNf0q7EAcbkZR2bn3WDo%3D&reserved=0. You are receiving this because you commented.Message ID: @.***>

⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

U

TimothyPMann commented 4 months ago

I may have at last found a fix for this. I'm still testing, and it has definitely missed ESXi 8.0.3, but if all goes well it will be available eventually.

TimothyPMann commented 2 months ago

A fix is checked into VMware's internal repository and should become available in ESXi 9.0. It's not pushed to github at this time, but could be if that's useful.