Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support for PXE boot #2386

Open
realmax44 opened this issue Feb 27, 2024 · 20 comments
Open

[Feature Request] Support for PXE boot #2386

realmax44 opened this issue Feb 27, 2024 · 20 comments
Assignees

Comments

@realmax44
Copy link

realmax44 commented Feb 27, 2024

Sorry if I ask a maybe stupid question, but I would like to know if it is possible to make OpenCore boot images via PXE.

I have an Unraid server here in my home network with a Linux VM on which iVentoy provides images that I can boot over the network. Of course, I always have to call up the UEFI boot menu to do this. Would this also be possible via OpenCore? Again, I apologize if I am completely misunderstanding something. This idea was also triggered by the many UEFI network drivers that OpenCore comes with, but which are not documented anywhere.

@CobanRamo
Copy link

That's exactly what I wanted to ask...
How exactly does it all work with these files?
It's really not documented anywhere, it would be great if we found out something about it.

Greetings Coban

Bildschirmfoto 2024-02-28 um 21 12 12

@mikebeaton
Copy link
Contributor

Related issue, and some basic information as to where to look currently for documentation on these network drivers: #2123

@mikebeaton mikebeaton self-assigned this Jun 18, 2024
@mikebeaton
Copy link
Contributor

So it turns out that network boot (PXE boot and HTTP(S) boot) is a bit of a collaboration between the boot manager and the network boot drivers, not just a self-contained process which you can launch - i.e. a non-trivial amount of the relevant logic needs to be present in the boot manager (in our case OpenCore, or a boot entry protocol driver for OpenCore). But watch this space...

@realmax44
Copy link
Author

realmax44 commented Aug 15, 2024

@mikebeaton Thank you very much for your work. I've configured and tried your OpenNetworkBoot and I'm almost happy, because for me it's working partially. Booting Linux ISOs with iVentoy is working without any problem, but when i try to boot a Windows PE, the display remains black after the PE files are loaded and the Windows logo appears. Booting the same Windows PE images over the UEFI boot menu is working without any problem. Could it be a video driver issue? Haven't tried to boot macOS Recovery yet.
15112256

@mikebeaton
Copy link
Contributor

mikebeaton commented Aug 15, 2024

@mikebeaton Thank you very much for your work. I've configured and tried your OpenNetworkBoot and I'm almost happy, because for me it's working partially. Booting Linux ISOs with iVentoy is working without any problem, but when i try to boot a Windows PE, the display remains black after the PE files are loaded and the Windows logo appears. Booting the same Windows PE images over the UEFI boot menu is working without any problem. Could it be a video driver issue? Haven't tried to boot macOS Recovery yet. 15112256

So, almost good news. ;)

Does Windows PE boot directly from OpenCore on that machine (i.e. OpenCore in the equation, but OpenNetworkBoot out of it)? Since you mentioned Windows PE working via UEFI boot, but didn't mention OpenCore even though Window PE is showing in your OpenCore menu, I'm guessing not? Have you tried setting SyncRuntimePermissions?

@realmax44
Copy link
Author

It is indeed the case that my Win PE can no longer be started via OpenCore. Here, too, the boot process ends at the Windows logo. The booter quirk SyncRuntimePermissions is activated. I don't know exactly what has changed in the last updates, but I know that booting Win PE via OC has always worked. I haven't started it for a while now. I'll try it with the OC debug version and post the logs when I have time.

@mikebeaton
Copy link
Contributor

It is indeed the case that my Win PE can no longer be started via OpenCore. Here, too, the boot process ends at the Windows logo. The booter quirk SyncRuntimePermissions is activated. I don't know exactly what has changed in the last updates, but I know that booting Win PE via OC has always worked. I haven't started it for a while now. I'll try it with the OC debug version and post the logs when I have time.

Please can you first check whether Win PE does or doesn't start with the current release of OpenCore (i.e. to find out whether the issue of Win PE not starting is to do with the OpenNetworkBoot changes or not). If it actually is to do with these changes, that is very helpful to know and please let me know here. (With a debug log when you have time.)

If it is to not do with OpenNetworkBoot then that would need opening as a separate issue. Also with a debug log, please. If it is a main OC issue, and if you can find a little more time again, a bisect to find the commit which introduced the issue would be very helpful.

@mikebeaton
Copy link
Contributor

mikebeaton commented Aug 16, 2024

I can boot Win PE from a USB using the most recent CI build of my PXE and HTTP(S) Boot pull request: https://github.com/acidanthera/OpenCorePkg/actions/workflows/build.yml

Be aware of the potential relevance of all of these quirks and see also Configuration.pdf 12.5 Tips and Tricks §9 How can I decide which Booter quirks to use?

@realmax44
Copy link
Author

I was able to solve the problem of the non-functioning Windows PE boot via OC. In my case it was the DMAR table that was responsible. I had experimented with the address ranges of the Reserved Memory Regions (should actually be removed completely). Now that I have removed them completely, Windows PE can be started again with OC without any problems.

But unfortunately this does not completely solve the PXE boot via OC. Now Windows PE is booted completely, but there are graphics problems that do not occur when booting locally via OC.

IMG_1965

@mikebeaton
Copy link
Contributor

Which WinPE iso are you booting?

@kokowski
Copy link

kokowski commented Aug 16, 2024

Ok, this problem could also be resolved. In the iVentoy screen, where you can choose the image to load, you can also set the resolution for the selection screen. I have to take the highest available resolution for the working Windows PE boot. I had set iVentoy to a lower resolution, because of graphical errors that occurred when booted over the UEFI boot menu. Now I can set iVentoy to the highest resolution in the selection screen by default, which I prefer. THX again for your work!

@mikebeaton
Copy link
Contributor

Since this is an iVentoy problem you could try using OpenNetworkBoot's HTTP Boot support to boot your desired .iso directly* rather than via iVentoy, hopefully avoiding these screen resolution issues, since they don't happen when booting direct from OpenCore. (*HTTP Boot drivers on most systems, including the version we ship, have semi-'secret' - i.e. hardly ever mentioned - native .iso and .img support.)

You would not need to set up any DHCP or PXE helper server, you can just use the OpenNetworkBook --uri argument to specify the URL of the .iso. But you do need a webserver somewhere (anywhere, in fact), to serve the .iso file. (And you need to add one or more certificates if you want to use an https:// URL.)

@mikebeaton
Copy link
Contributor

Since this is an iVentoy problem you could try using OpenNetworkBoot's HTTP Boot support to boot your desired .iso directly* rather than via iVentoy, hopefully avoiding these screen resolution issues, since they don't happen when booting direct from OpenCore. (*HTTP Boot drivers on most systems, including the version we ship, have semi-'secret' - i.e. hardly ever mentioned - native .iso and .img support.)

You would not need to set up any DHCP or PXE helper server, you can just use the OpenNetworkBook --uri argument to specify the URL of the .iso. But you do need a webserver somewhere (anywhere, in fact), to serve the .iso file. (And you need to add one or more certificates if you want to use an https:// URL.)

This works.

RamDiskDxe.efi has just been added to OpenNetworkBoot PR, as it is needed for HTTP(S) Boot .iso/.img support (if not already present in firmware - see OpenNetworkBoot README).

@CobanRamo
Copy link

Do you have an example Config.plist for me of how you set it up so that I can test it?

Greetings Coban

@mikebeaton
Copy link
Contributor

mikebeaton commented Aug 17, 2024

Bearing in mind that this is in no way supported yet:

Feel free to check these out.

@CobanRamo
Copy link

CobanRamo commented Aug 18, 2024

So I followed your readme strictly to find out which drivers I needed.

A number of them were missing on my Z590, I had to find out in the debug version which ones were there and which ones needed to be added.
Z590 Driver

Later I also ran the whole thing on my VMware.
On Vmware it is enough to just activate the OpenNetworkBoot.efi.
Vmware Driver

https://www.youtube.com/watch?v=dp6Owjr5C2U

I didn't quite understand why only 2 entries appeared on the real Z590.
On Vmware, 5 entries are displayed.
OpenCanopyMenu_vZ590
OpenCanopyMenu_vmware

I can report that the WDS server works excellently. See Video.
I still need to practice a bit with HTTP, I haven't been able to get it to work yet.

But I have a request for Mike, can't you put this NetworkBoot on the "Auxiliary" on the OpenCanopy menu?
That would be more suitable for these things, wouldn't it?

In any case, great work from you, thank you.

Regards, Coban

PS: if the DebugLog can help you; from both systems.
DebugLogs.zip
dh_Dump_vmware.txt
dh_dump_Z590.txt

@mikebeaton
Copy link
Contributor

@CobanRamo - Thanks for testing it and putting up some clear reports.

There is an optional --aux argument for the driver to make the entries auxiliary, but perhaps auxiliary should be the default, and I should change to having a --no-aux argument.

Where you have only two entries on the Z590, it only has HTTP Boot. Possibly you don't have PXE Boot natively on the Z590? (Or possibly you will get more entries if you enter OpenCore via the BIOS boot menu. That happens on a test HP I have.) Perhaps we should provide the few additional required drivers for PXE boot as well...

If you select HTTP Boot and you don't see at least the ">>Start HTTP Boot" text (i.e. as you do not in your video on VMWare, AFAICT) then the HTTP Boot you have (or VMWare has, in this case; I hadn't tested this but will try, thanks) is not working in the context of OpenCore. You should try unloading the existing HttpBootDxe and loading the OpenCore provided one instead.

@CobanRamo
Copy link

Possibly you don't have PXE Boot natively on the Z590?

Quite possible, I didn't find anything in the dh dump either.

Perhaps we should provide the few additional required drivers for PXE boot as well...

If that is possible, why not...

--aux argument for the driver

It works perfectly, I thought it would be more logical as a standard, but with an argument it's OK too.
Aux

aux1

You should try unloading the existing HttpBootDxe and loading the OpenCore provided one instead.

I hope I did the unload correctly, it didn't really make any difference, I always get this "http", "pxe" drivers aren't in the BIOS, it looks like.

If you select HTTP Boot and you don't see at least the ">>Start HTTP Boot" text

httpservice

That's correct, you can't see anything on vmware, but you can see it natively on z590.
When I start one I get the following message as shown in the picture.
I think that's normal, I also have the Wds server on this computer, I'll move the server to another computer and test it natively here too as soon as I have time.

Regards, Coban

@mikebeaton
Copy link
Contributor

mikebeaton commented Aug 19, 2024

According to your VMWare debug log, you have the Unload in the wrong section. Also, the name to unload by is the long, English language, driver name. To find it, redo your OpenCore SysReport: enable SysReport; remove the existing {ESP}/SysReport directory if there is one; reboot. Then look in SysReport/Drivers for the list of available (long, English) names to unload by. (The use of this long name is subject to change. It's the best approach I've found so far that works cross firmware to identify a specific driver after it's loaded.)

EDIT: Btw grep -i unload {oclogfilename}.txt should find you lines related to succeeded or failed unloads (or a line complaining it's not finding the Unload config in the right section, in this case).

@CobanRamo
Copy link

CobanRamo commented Aug 19, 2024

I think I've figured out what it is exactly, let me explain;

This Z590 has an Intel I225-V3 onboard which I'm not so happy with, I had deactivated it, so of course everything that has to do with it is also deactivated. If this is deactivated, the Pxe driver also disappears from the dh command.

I've installed an Intel 82574L here, the loaded drivers of course appear for it and without Pxe, so the whole thing only twice.

With the onboard NIC activated I have everything back, see pictures.
I think in cases like this or let's say for computers without a Pxe network stack you probably need the OpenCore Pxe driver.

In any case, I have it now as it should be.

Z590_dh_dump_NEW.txt.zip
Z590_opencore-2024-08-19-081705.txt.zip
SysReport.zip
PXE_HTTP
OnboardNetworkStack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants