Conversation
|
If anybody watching has some time to download the build artefacts for this version and try it out, that would be great. Instructions are in the attached Note that you need to update your config file You also need to download and add to your OC drivers a UEFI EXT4 driver (such as the If you already have Linux entries in OC, no need to remove them, but you might want to use something like: where the flags mean scan everything (which is the default anyway), and then add some debugging text to boot entry names created by this driver, which is not added by default and will help identifying entries added by this new system. It is fully working for me on latest Fedora and Ubuntu, and tested in principle (i.e. with the relevant config files, but not end to end yet) on a couple more, including CentOS. So any feedback as to how it works (and with which distro) would be gratefully received. |
|
Just tested it with Arch Linux, from a normally
|
|
@nadiaholmquist - thank you. It would be nice to see the result of We are not currently attempting to pass bootloader capabilities to anything - I could look into attempting to provide that info; though of course not much except Arch Linux uses systemd-boot directly, as I understand it - so it might be some work for little gain to most people - unless you (or anyone else wanting to comment) believes otherwise? I'm marginally surprised that your install has understood that it was not booted by systemd-boot as normal, in terms of what capabilities it reports - though I'm sure when I look into how this works, it'll make sense. (I'm assuming you didn't change that, and can still boot via systemd-boot if you wish. What does it report if you do that?) [EDIT: Yes, I can see what's going on, it's just volatile NVRAM variables. We're not providing it. I do think it's quite systemd-boot-specific. The one thing that looks useful (but that we don't already provide) is the random seed, but again almost nothing except Arch uses it, I believe. :-/ ] Thanks again. |
|
And yeah you are probably right about a minority of distros using systemd-boot, I know Fedora uses some pretty cursed setup with GRUB while somehow still implementing the boot loader spec, idk about Debian/Ubuntu/etc. Being able to support the |
|
@nadiaholmquist I had more of a look at the systemd Boot Loader Interface and yes, it is quite For anyone else reading, this is nothing to do with whether you can boot Linux with this new system. You can. it's to do with whether you can issue additional commands from within Linux, to tell the bootloader what to do on next boot. |
|
Is there any distro but Arch that is pushing systemd-boot adoption? I don't think I saw another distro, especially the big ones, that intend to support this garbage loader. I don't think Arch usage can be endorsed looking at the trust situation (AUR and friends), so I'd vote to keep anything to support (realistically) Arch-specific things, most especially systemd-boot, to third-party code. Default boot option should be handled via BootNext (so macOS and Windows can also be supported), for the boot menu option we could re-use the firmware setup functionality of UEFI. Linux should have tools to support those general functionalities over systemd-boot-specific mechanisms. |
Ah, I'd have thought those features were part of the boot loader spec but I guess leave it to systemd to invent its own thing for no clear reason... At this pint doesn't seem line it makes sense to support to me either. |
Yes, ofc we already support actual (used by many people) standards such as the BootNext var - this is already fully integrated into OC and works in OpenLinuxBoot automatically. (And yes, can already be set using Boot Loader Interface uses its own, different, NVRAM namespace, with different vars. i.e. While we indeed already have the majority of those features, just setting the NVRAM var which would put check marks next to them would be false, as we do not support them via the not-really-standard Boot Loader Interface variables |
|
Added known booting list in OP. It seems like the basic approach is sound, as planned/hoped. I'd still be very happy to receive reports from anyone else trying it out. Even if it worked! ;-) Thanks to @nadiaholmquist so far. |
vit9696
left a comment
vit9696
left a comment
There was a problem hiding this comment.
Reviewed partially till BootEntryManagement.c
mikebeaton
force-pushed
the
LinuxBoot
branch
4 times, most recently
from
37036c7 to
b03278d
Compare
mikebeaton
force-pushed
the
LinuxBoot
branch
from
b03278d to
87370a6
Compare
|
I tried it on my Ubuntu install and OpenCore was able to auto detect both kernel images from Ubuntu. When I select the Linux boot entry I get a black screen and nothing boots after waiting for about 5 minutes. Pressing the power button will instantly turn off the PC. The Ubuntu grub boot loader exists on a separate ESP than OpenCore. Booting to grub boot loader directly works. I get this log from OC debug build: Not sure what other logs would be useful here to diagnose. |
|
@TaiPhamD The full log would be useful to diagnose (as contains other LNX lines about what it encountered as it detected your distro). Also the output of |
|
@mikebeaton Here it is. Let me know if you want me to get any other logs. Thank you for creating this PR! opencore-2021-09-08-080114.txt My GRUB is on nvme2n1p1 and the Ubuntu OS that I want to load is on nvme2n1p2 |
|
Hi @TaiPhamD - Thanks for the info so far. Bear with me, I will produce a build with some additional Linux-related debug output in it, hopefully tomorrow. |
|
Hi - looking again now and have realised you've provided the log with a debug version of OpenCore but still with the release version of OpenLinuxBoot.efi - please run again using debug versions of both. |
|
My bad I copied debug files but missed the most important one. opencore-2021-09-10-162731.txt |
|
You need to make a custom entry in the config.plist Entries section, with the Path set equal to the whole path after "dp" in the log line "OCB: Should boot from... dp ...." and the Arguments set equal to the value inside <> (but not including <>) in the log line "OCB: Args". My guess, if you can get this to work and try to boot, is that it may well show the same behaviour as now with TextMode false, and may well boot into Ubuntu with TextMode true. Can you try this? |
Yes I can try it. FYI the previous 0.7.4 flags I had already updated the flags to 0xffff |
|
Hmm it doesn't appear to be showing the additional info? Anyway above quoted test is what we need next. [EDIT: In fact the setting definitely hasn't applied, for whatever reason, as a little bit of extra text is prepended to the title of each generated entry, when all debug are flags set, and we can see that that is not present, in the log. Perhaps copy and paste here the text from Drivers you are using for this, in case I can spot why it is not quite working?] |
|
opencore-2021-09-11-080620.txt same behavior even with the custom manual entry. |
|
Thanks for setting that up, but I see you have |
|
Please do try the Remaining options to try are:
You could also try a different gfx card, as you suggest, but I'd be particularly interested to know if any of the above combinations of changes can make it boot with no change in hardware. |
The only other thing I can think of is that I am using a pci-e adapter addon for my m.2 drive . I can try to install Ubuntu on my sata ssd tomorrow and see if that would work. |
|
Well the only thing we haven't successfully tried is If you can get that working, then maybe just run the log again, so I can see what OLB reports, but start the custom entry set to Thanks for testing these many and various combinations. |
|
Actually, new question, does Ubuntu start if you chainload GRUB - if you use OC to start GRUB, then GRUB to start Ubuntu? Or only when you start GRUB directly? |
|
Chainloading using method A from: https://github.com/dortania/OpenCore-Multiboot/blob/master/oc/linux.md used to work for me but now has the same behavior. I also have to add \EFI\ubuntu\grubx64.efi in BlessOverride entry or else I get the bless error. |
|
I would guess that chainloading will work again if you do not load ext4_x64.efi driver (since grub is also going to try to load it's own ext4 driver). Can you confirm. |
|
When booting directly to grub . I see this message before it goes into the asus logo + Ubuntu logo then starts up normally chainloading without additional ext4 driver in the advanced boot options show that it’s stuck at loading initial RAM disk. I did a google search and people suggested adding additional flag such as dis_ucode_ldr |
|
So, without loading OpenLinuxBoot.efi and without loading ext4_x64.efi, chainloading to GRUB then Ubuntu no longer works in the current version of OC, but used to work before? In that case could you unload both those drivers (and go back to the old drivers layout, since you are going to be checking previous versions of OC), and then do a binary search for the commit in OC which breaks your GRUB chainloading? Because it is sounding in this case as if something else new in OC (not directly this new Linux driver) is preventing your Ubuntu from starting, and the next step is to find out what. (I'm sure you already know the process for binary search to a problem commit, but just in case @82ghost82 wrote a very nice writeup just recently.) |
|
I got it to work finally it was something stupid. SyncRuntimePermissions was false, after I enable it to true it works perfectly! |
|
By the way is there a good way to hide grub2 entry so I can only see the direct kernel image boot ? |
|
Should not show if you do not use |
|
@mikebeaton |
That old chestnut. Thank you for spotting, it would have taken me a while. We need to add something to the docs... |
OpenLinuxBoot working with OpenCore both sets and responds to NVRAM default boot settings. If you boot into Windows via OC when Linux is the OC default, then you will be able to pick up the Boot#### NVRAM setting which OC has created - and perhaps store that as an option to select later? Not perfect, for you, I know, but might help? |
Thank you this almost works. However, It seems like whenever you change default boot , it will create Boot#### in the global boot GUID and OCbt#### in OC GUID. Unfortunately, it seems to create it at the same index such as Boot0080 so if you had triple boot Windows , MacOS, or Linux then you can only see Boot0000 as windows for example, then Boot0080 as either Ubuntu or MacOS (depending which was the default). So I think the code that stores the Ubuntu entry into the Boot#### or OCBt#### Variable need to use a different integer index than MacOS so that both linux & macos don't store to the same 0x80 location and wiping themselves out each time a different default is selected. |
Hi, yes that is how it works. That's what I meant about storing it as an option to boot later. I mean you'd have to start Windows once with each OS that you want to be able to return to as the default, then store that value as something to set again later. As I say, not ideal, but might be better than nothing? |
|
I don't know if I should post my issue here, but when I boot from OC to Ubuntu or Fedora using OpenLinuxBoot my Audio setup is not working (It shows Dummy Output and no Input), if I boot from GRUB audio works properly both input and output |
|
@HJebbour It should ideally work. It would make more sense to create a separate issue. Can you post config.plist, debug OC boot log booting into Ubuntu, also your machine and sound specs. |
|
@mikebeaton Thank you for your reply, please find attached the requested files and find below my machine's specs:
|
Hi, have you solved this issue ? |
|
In recent testing I found that OpenLinuxBoot does not detect a fresh Ubuntu 25.10 installation, though earlier versions like 24.04 are detected correctly. Upgrading from 24.04 to 25.10 also seems to work. However if I directly install 25.10 from USB to an ext4 partition on the drive it is not detected and displayed in OpenCanopy but I can boot from grub. I've tested this on both a Macbook Pro 2009 and Macbook Pro 2010 running OCLP 2.4.1, which seems to use OpenCorePkg version 1.0.4 |
Thanks for reporting. Please create a new issue for this. |
8 participants
Ready for any further review - still without additional support for system actions and associated sound protocol changes.
Boots Linux automatically, via OC, without chaining to Grub (in case anyone reading this is wondering "so what's new"?!).
Tested booting fine:
Parsing boot files, but boot from default install would require EFI driver for Linux LVM:
DONE:
/loader/entries(for BLSpec and systemd blscfg)/loader/entriesdir.conffileos-proberTO ADD:
.contentDetailsand.contentFlavourfiles, to set entry base name and entry flavour, where auto-detection sets them wrong or finds no value. Currently auto-detection is working well enough that this should not be required except in edge cases.TO FIX:
Also requested/planned: