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

Linux boot #282

Merged
merged 2 commits into from
Sep 4, 2021
Merged

Linux boot #282

merged 2 commits into from
Sep 4, 2021

Conversation

mikebeaton
Copy link
Contributor

@mikebeaton mikebeaton commented Aug 3, 2021

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:

Distro OLB detection method
Fedora blspec
Ubuntu autodetect
Arch Linux blspec
Linux Mint autodetect
openSUSE autodetect
Void Linux (musl version) blspec
deepin autodetect

Parsing boot files, but boot from default install would require EFI driver for Linux LVM:

Distro OLB detection method
CentOS blspec
Rocky Linux blspec

DONE:

  • Parse and boot from /loader/entries (for BLSpec and systemd blscfg)
  • Auto-detect vmlinuz-* and init* if on plausible root fs without /loader/entries dir
  • Auto-detect Linux variant name and kernel version from kernel image file (cf. https://stackoverflow.com/a/11179559/795690 ), for use in auto-detect and when not present in blspec .conf file
    • Above is working, but the info there isn't very authoritative (e.g. Linux Mint looks exactly like Ubuntu); to replace with better approach similar to/inspired by grub os-prober
  • Make selectable as default boot entry
    • As above for no-menu quick code path
  • Allow parameterise OC drivers for optional argument passing
  • Various minor cleanups
  • Documentation

TO ADD:

  • Add support for .contentDetails and .contentFlavour files, 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:

  • Prevent over-long Linux boot entry names messing up layout of builtin menu (use ellipses when required)

Also requested/planned:

  • In order to allow entry protocol drivers to provide own audio-assist, update OC sound protocol to work from string rather than int sound ids
  • Upgrade boot entry protocol to support system actions
  • Redo existing system actions (Reset NVRAM, Toggle SIP) as entry protocol drivers
  • Use new FlexArrayLib in place of similar code in OcXmlLib
  • Use new Arg parsing code in place of existing less powerful arg parsing code

@mikebeaton mikebeaton marked this pull request as draft August 17, 2021 14:34
@mikebeaton mikebeaton marked this pull request as ready for review August 19, 2021 18:06
@mikebeaton
Copy link
Contributor Author

mikebeaton commented Aug 20, 2021

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 Configuration.pdf, and forward search for OpenLinuxBoot.

Note that you need to update your config file Drivers section as this now supports passing parameters to drivers (used here, and intended to be used in future in a couple more). You could keep your current Drivers section unchanged, but renamed to <key>#Drivers</key> (keys starting with # are ignored by OC), and add the new layout under a new <key>Drivers</key>, so that it is easy to switch between them by just swapping the #. ocvalidate in the download package is up-to-date, to allow double-checking this change.

You also need to download and add to your OC drivers a UEFI EXT4 driver (such as the ext4_x64.efi driver found within the current rEFInd download), as OC does not include this.

If you already have Linux entries in OC, no need to remove them, but you might want to use something like:

			<dict>
				<key>Driver</key>
				<string>OpenLinuxBoot.efi</string>
				<key>Enabled</key>
				<true/>
				<key>Params</key>
				<string>flags=0x8387</string>
			</dict>

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.

@nadiaholmquist
Copy link

Just tested it with Arch Linux, from a normally systemd-boot-based setup. OpenCore successfully boots my install and it seems to work as it should, nice job :)

nhp@narshe /boot % ls
EFI                                      intel-ucode.img
initramfs-linux-ck-skylake-fallback.img  loader
initramfs-linux-ck-skylake.img           vmlinuz-linux-ck-skylake
nhp@narshe /boot % cat loader/entries/arch.conf 
title   Arch Linux
linux   /vmlinuz-linux-ck-skylake
initrd  /initramfs-linux-ck-skylake.img
initrd  /intel-ucode.img
options root=UUID=a4607b9a-f0d8-49e9-a077-a750c41852bd sysrq_always_enabled=1 quiet splash loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3 acpi_enforce_resources=lax vga=current intel_iommu=on iommu=pt

bootctl reports that none of the features that would be supported by systemd-boot are supported, is this to be expected?

Current Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

Random Seed:
 Passed to OS: no

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Aug 20, 2021

@nadiaholmquist - thank you.

It would be nice to see the result of cat /proc/cmdline from inside your install, just to be sure that everything looks as it should! :) [EDIT: In fact ideally to compare when booted w/ OC and when booted w/ sd-boot. :) ]

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.

@nadiaholmquist
Copy link

/proc/cmdline are identical between OpenCore and systemd-boot: initrd=/initramfs-linux-ck-skylake.img initrd=/intel-ucode.img root=UUID=a4607b9a-f0d8-49e9-a077-a750c41852bd sysrq_always_enabled=1 quiet splash loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3 acpi_enforce_resources=lax vga=current intel_iommu=on iommu=pt

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 --boot-loader-entry and --boot-loader-menu options when restarting the system with systemctl could be nice, though if those also require systemd-boot I figure it wouldn't be worth the effort.

@mikebeaton
Copy link
Contributor Author

@nadiaholmquist I had more of a look at the systemd Boot Loader Interface and yes, it is quite systemd-boot specific. Adding these features wouldn't just be adding more code to this new OC plugin I'm working on, OC itself would need code added for this (possibly as a further extension of the new Boot Entry Protocol, but it would still be specifically for this). So again it would come down to usage. Might even make sense as a separate new plugin. But might need a volunteer to write it! And also depends importantly on an overall decision as to whether it really is worth supporting.

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.

@mhaeuser
Copy link
Member

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.

@nadiaholmquist
Copy link

@nadiaholmquist I had more of a look at the systemd Boot Loader Interface and yes, it is quite systemd-boot specific. Adding these features wouldn't just be adding more code to this new OC plugin I'm working on, OC itself would need code added for this (possibly as a further extension of the new Boot Entry Protocol, but it would still be specifically for this). So again it would come down to usage. Might even make sense as a separate new plugin. But might need a volunteer to write it! And also depends importantly on an overall decision as to whether it really is worth supporting.

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.

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Aug 21, 2021

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.

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 efibootmgr.)

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

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Aug 22, 2021

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.

Copy link
Contributor

@vit9696 vit9696 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed partially till BootEntryManagement.c

Docs/Configuration.tex Outdated Show resolved Hide resolved
Docs/Configuration.tex Outdated Show resolved Hide resolved
Docs/Configuration.tex Outdated Show resolved Hide resolved
Docs/Configuration.tex Outdated Show resolved Hide resolved
Docs/Configuration.tex Outdated Show resolved Hide resolved
Library/OcBootManagementLib/BootArguments.c Outdated Show resolved Hide resolved
Library/OcBootManagementLib/BootArguments.c Show resolved Hide resolved
Library/OcBootManagementLib/BootArguments.c Outdated Show resolved Hide resolved
Library/OcBootManagementLib/BootArguments.c Outdated Show resolved Hide resolved
Library/OcBootManagementLib/BootEntryManagement.c Outdated Show resolved Hide resolved
@mikebeaton mikebeaton force-pushed the LinuxBoot branch 4 times, most recently from 37036c7 to b03278d Compare September 4, 2021 14:31
@TaiPhamD
Copy link
Contributor

TaiPhamD commented Sep 8, 2021

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:

13:252 00:001 OCB: Should boot from 3. Ubuntu 20.04.3 LTS (5.11.0-34-generic) (T:64|F:0|G:0|E:0|DEF:0)
13:265 00:013 OCB: Perform boot Ubuntu 20.04.3 LTS (5.11.0-34-generic) to dp PciRoot(0x1)/Pci(0x0,0x0)/Pci(0x0,0x0)/NVMe(0x1,3C-07-48-44-8B-44-1B-00)/HD(2,GPT,45D659E4-BF85-4E50-993B-5A91F4875E18,0x100800,0x3A285000)/\boot\vmlinuz-5.11.0-34-generic (0/0)
13:278 00:013 OCSB: No IMG4 found - Not Found
13:280 00:001 OCB: Arch filtering 41B01018(10132256)->41B01018(10132256) caps 4 - Success
13:367 00:086 OCB: Matching <> args on type 64 43C1E018
13:369 00:001 OCB: Custom (64) DeviceHandle 475E1C18 FilePath 43C1E198

Not sure what other logs would be useful here to diagnose.

@mikebeaton
Copy link
Contributor Author

@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 mount from your successfully booted distro is useful. Thx.

@TaiPhamD
Copy link
Contributor

TaiPhamD commented Sep 8, 2021

@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
ubuntu_mount.txt
ubuntu_fdisk.txt

My GRUB is on nvme2n1p1 and the Ubuntu OS that I want to load is on nvme2n1p2

Disk model: WDS500G2X0C-00L350                      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 245BBFC2-5E3A-4E1C-BA9E-7DE5A866A757

Device           Start       End   Sectors   Size Type
/dev/nvme2n1p1    2048   1050623   1048576   512M EFI System
/dev/nvme2n1p2 1050624 976771071 975720448 465.3G Linux filesystem

@mikebeaton
Copy link
Contributor Author

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.

@mikebeaton
Copy link
Contributor Author

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.

@TaiPhamD
Copy link
Contributor

My bad I copied debug files but missed the most important one.

opencore-2021-09-10-162731.txt

✘  /Volumes/EFI  rg LNX opencore-2021-09-10-162731.txt
547:07:640 00:008 LNX: TypeGUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (ESP) PARTUUID: 9C7CCD10-86F3-47B3-A2D5-3E32BA65C0E0
548:07:648 00:008 LNX: Nothing found
555:07:667 00:001 LNX: TypeGUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (NTFS/FAT) PARTUUID: 5300C38E-331D-4DD2-A763-3DCE82A9D927
556:07:669 00:001 LNX: Nothing found
563:07:693 00:003 LNX: TypeGUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (ESP) PARTUUID: E878C4E6-004E-4E42-BE19-2E1027E45ECD
564:07:697 00:003 LNX: Nothing found
575:07:719 00:001 LNX: TypeGUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (ESP) PARTUUID: A812C758-EA83-431F-A484-A030AEFD6492
576:07:720 00:001 LNX: Nothing found
577:07:723 00:002 LNX: TypeGUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (ESP) PARTUUID: 3DF99478-B7C8-4C1B-B16C-D994132DDD6A
578:07:725 00:002 LNX: Does not appear to be root filesystem - Not Found
579:07:728 00:002 LNX: Nothing found
586:07:740 00:001 LNX: TypeGUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (NTFS/FAT) PARTUUID: 1F5AB430-2474-48FD-9387-357B13234735
587:07:742 00:001 LNX: Does not appear to be root filesystem - Not Found
588:07:744 00:002 LNX: Nothing found
602:07:770 00:002 LNX: TypeGUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (ESP) PARTUUID: 33002EF2-526D-4664-A7CD-42E9AC95A835
603:07:773 00:002 LNX: Nothing found
610:07:786 00:001 LNX: TypeGUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (DATA) PARTUUID: 45D659E4-BF85-4E50-993B-5A91F4875E18
611:07:797 00:011 LNX: Reading \etc\os-release
612:07:799 00:001 LNX: Found distro Ubuntu 20.04.3 LTS
613:07:803 00:004 LNX: Reading \etc\default\grub
618:07:812 00:002 LNX: APFS - not scanning
622:07:819 00:001 LNX: APFS - not scanning
626:07:826 00:001 LNX: APFS - not scanning
630:07:833 00:001 LNX: APFS - not scanning

@TaiPhamD
Copy link
Contributor

Yes I am using an AMD 6900xt so could be something different about this gpu. I do have another AMD rx5500 that I could test to see if it makes a difference.

Here it is with the artifact 0.7.4 debug build:

opencore-2021-09-11-005048.txt

@mikebeaton
Copy link
Contributor Author

Thanks, as said can you do same test with the new debug build, but please add flags=0xffff as plain text, in your config.plist, within the Arguments section of your OpenLinuxBoot driver. Thanks.

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Sep 11, 2021

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?

@TaiPhamD
Copy link
Contributor

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

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Sep 11, 2021

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?]

@TaiPhamD
Copy link
Contributor

opencore-2021-09-11-080620.txt
Screen Shot 2021-09-11 at 1 04 47 AM

same behavior even with the custom manual entry.

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Sep 11, 2021

Thanks for setting that up, but I see you have TextMode=false in the screenshot. Did you try setting true under TextMode in the manual entry too? The difference with that (if there is any) is important.

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Sep 11, 2021

Please do try the TextMode=true test, as above; or report back if you have definitely tried true with no difference in behaviour. It is important to know this for sure.

Remaining options to try are:

  • Try booting using PickerMode=Builtin instead of PickerMode=External
  • In your custom entry, try replacing root=PARTUUID={partuuid} value (as generated by OpenLinuxBoot) with the root=UUID={uuid} different value from /proc/cmdline (leave the rest of the custom entry argument line the same, in particular initrd=..... is required)

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.

@TaiPhamD
Copy link
Contributor

TaiPhamD commented Sep 11, 2021

  • I definitely have tried setting TextMode to true which also didn’t work . (I made sure to choose my custom entry -I mistakenly choose the auto scanned entry the first time reboot)

  • I have tried changing Picker mode to Builtin to get rid of OpenCanopy which didn’t work either .

  • I tried changing to using UUID instead of PARUUID didn’t work either

  • Tried changing gpu that didn’t work either

  • I tried add manual bless override for the custom entry \boot\linux image path didn't make a difference

  • tried messing with bios settings CSM on/off, pci 4g decoding on/off , TPM module on/off didn't seem to make a difference

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.

@mikebeaton
Copy link
Contributor Author

Well the only thing we haven't successfully tried is flags=0xffff. When that is working then each entry generated by OpenLinuxBoot.efi has a little bit of extra debug info added to its title, and we definitely didn't see that.

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 root=UUID=... and TextMode=true.

Thanks for testing these many and various combinations.

@mikebeaton
Copy link
Contributor Author

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?

@TaiPhamD
Copy link
Contributor

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.

@mikebeaton
Copy link
Contributor Author

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.

@TaiPhamD
Copy link
Contributor

When booting directly to grub . I see this message before it goes into the asus logo + Ubuntu logo then starts up normally
978E80F4-3F20-44B4-8FE9-F4BD63CE1903

chainloading without additional ext4 driver in the advanced boot options show that it’s stuck at loading initial RAM disk.
880C9DB3-679C-425F-A355-4A734D845692

I did a google search and people suggested adding additional flag such as dis_ucode_ldr
didn’t seem to help.

@mikebeaton
Copy link
Contributor Author

mikebeaton commented Sep 11, 2021

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

@TaiPhamD
Copy link
Contributor

I got it to work finally it was something stupid. SyncRuntimePermissions was false, after I enable it to true it works perfectly!

@TaiPhamD
Copy link
Contributor

By the way is there a good way to hide grub2 entry so I can only see the direct kernel image boot ?

@vit9696
Copy link
Contributor

vit9696 commented Sep 12, 2021

Should not show if you do not use BlessOverride as grub does not install to standard paths in most distros. You can also avoid installing grub in your Linux distro, which is commonly an option.

@TaiPhamD
Copy link
Contributor

TaiPhamD commented Sep 12, 2021

@mikebeaton
I would love to have a way to allow windows to know about the scanned linux kernel images by OC. If we could somehow save this information to NVRAM for example to OC Vendor GUID then I can scan it in my windows EFI boot selector app to allow users to restart to Linux. We would also need OpenLinuxBoot to allow us to change default boot entry in OC for this to work.

@mikebeaton
Copy link
Contributor Author

I got it to work finally it was something stupid. SyncRuntimePermissions was false, after I enable it to true it works perfectly!

That old chestnut. Thank you for spotting, it would have taken me a while. We need to add something to the docs...

@mikebeaton
Copy link
Contributor Author

@mikebeaton
I would love to have a way to allow windows to know about the scanned linux kernel images by OC. If we could somehow save this information to NVRAM for example to OC Vendor GUID then I can scan it in my windows EFI boot selector app to allow users to restart to Linux. We would also need OpenLinuxBoot to allow us to change default boot entry in OC for this to work.

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?

@TaiPhamD
Copy link
Contributor

@mikebeaton
I would love to have a way to allow windows to know about the scanned linux kernel images by OC. If we could somehow save this information to NVRAM for example to OC Vendor GUID then I can scan it in my windows EFI boot selector app to allow users to restart to Linux. We would also need OpenLinuxBoot to allow us to change default boot entry in OC for this to work.

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.

@mikebeaton
Copy link
Contributor Author

@mikebeaton
I would love to have a way to allow windows to know about the scanned linux kernel images by OC. If we could somehow save this information to NVRAM for example to OC Vendor GUID then I can scan it in my windows EFI boot selector app to allow users to restart to Linux. We would also need OpenLinuxBoot to allow us to change default boot entry in OC for this to work.

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?

@mikebeaton mikebeaton deleted the LinuxBoot branch September 14, 2021 08:07
@HJebbour
Copy link

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

@mikebeaton
Copy link
Contributor Author

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

@HJebbour
Copy link

@mikebeaton Thank you for your reply, please find attached the requested files and find below my machine's specs:

  • Lenovo ThinkPad X1 Carbon Gen 8 (i7-10510U)
  • Audio device: Intel Corporation Comet Lake PCH-LP cAVS (ALC285)

log_config.zip

@askwakhid
Copy link

@mikebeaton Thank you for your reply, please find attached the requested files and find below my machine's specs:

  • Lenovo ThinkPad X1 Carbon Gen 8 (i7-10510U)
  • Audio device: Intel Corporation Comet Lake PCH-LP cAVS (ALC285)

log_config.zip

Hi, have you solved this issue ?
Thank you.

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