[Feature Request] Support for PXE boot

realmax44 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

Related issue, and some basic information as to where to look currently for documentation on these network drivers: https://github.com/acidanthera/bugtracker/issues/2123

mikebeaton commented 3 months ago

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 commented 1 month ago

@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 commented 1 month ago

@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.

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.

mikebeaton commented 1 month ago

Which WinPE iso are you booting?

kokowski commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Greetings Coban

mikebeaton commented 1 month ago

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

The main instructions are in the README in the relevant directory, only in the pull request until merged, here: https://github.com/mikebeaton/OpenCorePkg/blob/network-boot/Platform/OpenNetworkBoot/README.md
Details of the optional arguments for OpenNetworkBoot are in Configuration.pdf, also only in the PR until merged
- For now you could read these in its source file: https://github.com/mikebeaton/OpenCorePkg/blob/network-boot/Docs/Configuration.tex
- (Or you could download 'macOS XCODE5 Artifacts.zip' from the latest completed build related to a commit in the PR https://github.com/acidanthera/OpenCorePkg/actions/workflows/build.yml?query=event%3Apull_request, and find built Configuration.pdf for the PR in there.)

Feel free to check these out.

CobanRamo commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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

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 commented 1 month ago

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 commented 1 month ago

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

acidanthera / bugtracker

[Feature Request] Support for PXE boot #2386