OpenLinuxBoot cannot be started properly from MBR partition

[btwise]

@mikebeaton After load OpenLinuxboot. efi and ext4_x64.efi, I insert the LINUX disk that contains the EXT4 partition, and I cannot enter the GUI. How do I boot LINUX?

[mikebeaton]

Testing has been concentrated on proving that OC can now natively boot several different already-installed distros.

But if I understand what you're saying, you have an issue starting the installer? There shouldn't be any issue there, either.

That part should just work, and just the same as before OpenLinuxBoot: you put in a USB drive, if the menu was already open when you inserted it, press ESC in OC to refresh the options, then choose the new external drive which shows! That should be it. Sometimes there are two which show for one USB stick and only one works.

Also, to confirm, you have successfully updated your config.plist Drivers section to the new format? (See Drivers section in Docs sample .plist files.)

[btwise]

My Linux system has been installed on my USB disk partition, which can be normally booted by GRUB or Xorboot. Even if I booted to OC GUI interface in advance, after I inserted my USB disk, the GUI interface would be blocked, no usb partition would appear, and the cursor could not be moved. My UEFI-Drivers has been updated to the latest structure, and the OC version is also the latest version

[mikebeaton]

Ah. Okay. Makes sense now. Hmm. Log file please? Run same test in full debug version of OC, the test inserting USB after first booting into OC sounds good, and send log. Thanks.

[btwise]

Will logs be generated when debug mode is enabled? When the USB disk is inserted after entering the OC boot interface without inserting the USB disk, the computer already freezes

[mikebeaton]

I am guessing the interface only freezes when you actually press Escape key to update OC? If so, OC will generate log info up to the freeze, and possibly including info about the freeze before it halts.

If it actually freezes as soon as you insert the USB disk(?), then I think the problem may be with the ext4 driver. You can test that theory without doing any logging - just disable OpenLinuxBoot.efi and then test inserting USB after OC start, with and without the ext4_x64.efi driver.

[btwise]

I have tested that if I do not load ext4_64.efi, it will not freeze, of course can not see EXT4 partition. Tomorrow I will test if I only load ext4_64 file without load OpenLinuxBoot

[mikebeaton]

Would be VERY helpful if you can quickly test that today - of course, understood if not.

[mikebeaton]

Also, if you have a moment to confirm: the freeze is immediate when you insert the drive yes? (Does not happen later, after pressing ESC to refresh OC entries?)

[btwise]

I have tested it today. If openLinuxboot. efi is not loaded and only EXT_x64.efi is loaded, OC GUI interface will not freeze, but EXT partition icon cannot be seen. If openLinuxboot. efi and EXT_x64. efi are loaded at the same time, enter OC GUI in advance in time, insert USB disk, press ESC to refresh, it will freeze!

[btwise]

This is the generated log file! OpenLinuxBoot.zip

[mikebeaton]

Okay, looking... I do know we can definitely boot Deepin no problem, it was already tested and working fine, before release. Looks like it's something to do with the setup of your external drive. Am trying to replicate or figure out what to ask you next!

[btwise]

Whether or not it depends on the hard disk partition, because my USB disk has both ext4 and NTFS, but even if the boot is unsuccessful, it should not cause the GUI interface to freeze

[mikebeaton]

No there's definitely a bug, which I think is being triggered by some combination in your setup, but I agree is not the 'fault' of your setup - i.e. should not be happening, Can I ask, is your USB disk MBR rather than GPT? (Still should not freeze, even if it is - I agree!)

[mikebeaton]

Hi @btwise - Please could you send a debug log which includes the freeze, using this build https://github.com/acidanthera/OpenCorePkg/suites/3704508306/artifacts/90463605 .

Please could you also attach the file /etc/default/grub from inside your Linux distro.

[btwise]

No there's definitely a bug, which I think is being triggered by some combination in your setup, but I agree is not the 'fault' of your setup - i.e. should not be happening, Can I ask, is your USB disk MBR rather than GPT? (Still should not freeze, even if it is - I agree!)

My disk partition is MBR, but it also has FAT32 partitions to boot with UEFI ，because it is my tools disk，so cannot use GPT fully

[btwise]

Hi @btwise - Please could you send a debug log which includes the freeze, using this build https://github.com/acidanthera/OpenCorePkg/suites/3704508306/artifacts/90463605 .

Please could you also attach the file /etc/default/grub from inside your Linux distro.

OK!

[btwise]

Hi @btwise - Please could you send a debug log which includes the freeze, using this build https://github.com/acidanthera/OpenCorePkg/suites/3704508306/artifacts/90463605 .

Please could you also attach the file /etc/default/grub from inside your Linux distro.

Use the DEBUG version you provided to compile and freeze the same GUI after refreshing, but the log file is obviously different! opencore-2021-09-08-090114.txt this is/etc/default/grub file! grub.zip

[mikebeaton]

Still no huge clues. I'm going to produce a version with more debug info, hopefully tomorrow.

[btwise]

Still no huge clues. I'm going to produce a version with more debug info, hopefully tomorrow.

okay，It can read files under ext4 partition, but cannot boot, and freezes OC boot

[mikebeaton]

Yes. It's not yet clear why it's stopping, though I'd have to say it looks like it's in the new driver, not in the ext4 driver. I need to add more clues to the logs.

[mikebeaton]

@btwise - Please can you provide the OC debug log from the same test, insert your Linux USB drive then press ESC, using the latest build https://github.com/acidanthera/OpenCorePkg/suites/3739572732/artifacts/91687026 . Please add flags=0xffff to the arguments of your OpenLinuxBoot.efi driver before running this test (this will add a bit more info to the logs).

[btwise]

@btwise - Please can you provide the OC debug log from the same test, insert your Linux USB drive then press ESC, using the latest build https://github.com/acidanthera/OpenCorePkg/suites/3739572732/artifacts/91687026 . Please add flags=0xffff to the arguments of your OpenLinuxBoot.efi driver before running this test (this will add a bit more info to the logs).

The test is complete. After pressing ESC on the GUI interface with this version, the wait time is slightly longer, but it does not freeze. and I can also see the LINUX disk, but it does not seem to boot into LINUX successfully opencore-2021-09-13-025015.txt

[mikebeaton]

The issue is the MBR partition.

• There is a possible future update in which the correct options will be autodetected
• For now, OC cannot detect the correct partition id for Linux root on a non-GPT drive
• I have updated exactly how the user options work, so that at least you can work round this:

Log into your Deepin via GRUB, note the correct values from cat /proc/cmdline, ignoring the BOOT_IMAGE... value, so it will be something like:

root=UUID=12345678-0000-0000-0000-000000000000 ro splash quiet DEEPIN_GFXMODE=0,2560x1600

Then, if you have only one Linux install, you can just add:

autoopts="root=UUID=12345678-0000-0000-0000-000000000000 ro splash quiet DEEPIN_GFXMODE=0,2560x1600"

to the Arguments of OpenLinuxBoot.efi in your config.plist. Those options will apply to every Linux distro, but that's fine if you only have one.

If you have more than one distro installed, you can use:

partuuidopts:00000000-0000-0000-0000-000000000000="root=UUID=12345678-0000-0000-0000-000000000000 ro splash quiet DEEPIN_GFXMODE=0,2560x1600"

That will apply to every Linux distro on any MBR drive (no way to work round this, and pick out just one particular distro, I'm afraid), but it won't affect any other Linux distro on any GPT drive.

[btwise]

@mikebeaton use https://github.com/acidanthera/OpenCorePkg/commit/91859cec79be08ea0aebdc1e9c1ba923cf7688c3 after,If do not add the autoopts parameter toopenLinuxboot.efi and insert the external LINUX disk into the GUI interface, it will freeze again. If add the autoopts parameter, I can boot LINUX normally!

[mikebeaton]

It freezes again? Goddamit. It would be good to pin down this freeze. Can you run the test which freezes, but with flags=0xffff set in OpenLinuxBoot driver Arguments, and send the log, pls?

[btwise]

It freezes again? Goddamit. It would be good to pin down this freeze. Can you run the test which freezes, but with flags=0xffff set in OpenLinuxBoot driver Arguments, and send the log, pls?

I test again， I added the flag parameter, it didn't really freeze, just stayed in the GUI interface for about 20 seconds before I could continue to operate the keyboard, but if without the autoopts parameter, couldn't recognize my Linux disk But if not any parameter on OpenLinuxBoot.efi，it will really freeze!

[mikebeaton]

It would really help to get a debug log during the time when it is behaving strangely. A pause of 20s is strange enough! Can you make and send a debug log of that, please. (I cannot replicate here, I need more clues from your log to find out what to fix.)

[mikebeaton]

My disk partition is MBR, but it also has FAT32 partitions to boot with UEFI ，because it is my tools disk，so cannot use GPT fully

@btwise - In terms of trying to replicate the problem here, I'm struggling to even get Deepin to agree to install itself onto an MBR disk in a UEFI system, I'm sure I could manually force something, but then no idea if it would be the same as yours. If you still remember, can you give a quick sketch of how you set it up (i.e. the disk, and then Deepin on it)? (At the same time, I would still definitely like the opencore debug log, from any time there is any sign of unusual behaviour.)

[btwise]

@mikebeaton Sorry, I didn't upload the log in time because I was arranging time!

This is the log with flags= 0xFFFF parameter, there is only one file and it does not freeze the GUI! With_Args.zip

This is the log with no parameters, it has two files, and it freezes the GUI! No_Args.zip

The preceding logs are generated using the DEBUG version of OpenLinuxboot. efi.

[btwise]

this is my partitions summ!

[mikebeaton]

Hi - I will look at these, but I really need the logs with the debug version of everything (specifically, OpenCore as well as OpenLinuxBoot, but really, just everything!).

Not sure if you're aware, but unless you have a very non-standard setup, you can just overwrite with everything from the DEBUG/RELEASE package of OpenCore to switch versions:

cp -r ~/Downloads/OpenCore-0.7.3-DEBUG/X64/EFI /Volumes/efi

(assuming your ESP volume is mounted at /Volumes/efi) to switch to DEBUG and then

cp -r ~/Downloads/OpenCore-0.7.3-RELEASE/X64/EFI /Volumes/efi

to switch back.

This does not overwrite your config.plist, or any other custom settings [EDIT: nor your themes]. I guess you might want to backup the first time to be sure, but there should be no problems.

[btwise]

Hi - I will look at these, but I really need the logs with the debug version of everything (specifically, OpenCore as well as OpenLinuxBoot, but really, just everything!).

Not sure if you're aware, but unless you have a very non-standard setup, you can just overwrite with everything from the DEBUG/RELEASE package of OpenCore to switch versions:

cp -r ~/Downloads/OpenCore-0.7.3-DEBUG/X64/EFI /Volumes/efi

(assuming your ESP volume is mounted at /Volumes/efi) to switch to DEBUG and then

cp -r ~/Downloads/OpenCore-0.7.3-RELEASE/X64/EFI /Volumes/efi

to switch back.

This does not overwrite your config.plist, or any other custom settings. I guess you might want to backup the first time to be sure, but there should be no problems.

Okay,I use bootx64.efi,OpenCore.efi, drivers floder all the files for DEBUG version, regenerating the log!

[mikebeaton]

Please confirm for each one whether it pauses or not, as well as whether it freezes, or not. If you can get a DEBUG (of everything ;) ) log which is made during a 20 sec pause this would be even more helpful than a log during a freeze (but a freeze would be helpful too...).

[btwise]

This is a log generated using all the DEBUG version files. Hope it helps you！ with_args.txt no_args.zip

The 20 second pause I feel is caused by the DEBUG version, not the problem!

[mikebeaton]

Hi @btwise - Thanks for all the tests so far. Please can you check that this table is right, and update and correct if not:

OpenLinuxBoot.efi driver <Arguments>...</Arguments>	OC RELEASE	OC DEBUG
Empty arguments	Freeze	Freeze
autoopts={deepin-opts}	Shows entry and boots	Shows entry and boots
flags=0xffff (but no autoopts={deepin-opts})	No freeze, no Deepin boot entry	No freeze, no Deepin boot entry
flags=0xffff autoopts={deepin-opts}	Shows entry and boots	Shows entry and boots

[btwise]

It's right

[mikebeaton]

It's frustrating that we cannot get the freeze and the detailed debug (flags=0xffff) at the same time.

[mikebeaton]

Just clutching at straws, before looking at completely different routes, but even with DEBUG version of OpenLinuxBoot.efi, combined with RELEASE version of (the rest of) OpenCore, it still does not freeze with flags=0xffff, but freezes with empty arguments - is that correct too?

[btwise]

I don't know openlinuxboot.efi or other parameter, until the current flags and autoopts it does not freeze, that's a strange question, may partition structure to do with me!

[mikebeaton]

I can see you answered my last question above already, actually.

I'm trying to use the more detailed log (obtained with flags=0xffff) to see exactly where in the code it freezes, but as soon as you turn the more detailed debug log on for me, it no longer freezes. That is my problem at the moment, so as I say, on to other avenues to try to chase this down.

I guess since your problem is fixed, I'll close it again.

I'll put help wanted though: if anybody can get this freeze to happen with flags=0xffff logging turned on (the important flag bit is 0x4000, any others can be set as you need) then that would be very helpful.

[mikebeaton]

@btwise FYI the hang issue is (finally...) fixed by https://github.com/acidanthera/OpenCorePkg/commit/15bc4003b2ff0e9393b0899724711160b39a659a - if you have any time to retest and report back, it should now boot fine even if no Arguments given to OpenLinuxBoot.efi driver.

[btwise]

@mikebeaton I've tested it and it does fix the boot menu freeze hang problem, but if without the autoopts arguments for OpenLinuxBoot, it can't recognize my Linux partition and boot properly

[mikebeaton]

Yes - that is all as expected. Thank you for the report. (I will keep you posted if I get a chance to do an update which could boot your distro with no autoopts.)

[mikebeaton]

@btwise - I have added a task for supporting distros with your layout as discussed above to https://github.com/acidanthera/bugtracker/issues/1776 - it remains on my list of something that would be good to do!

I appreciate this is Deepin, which I am happy to agree is a mainstream distro - FWIW I also think it is a very nice distro! However my install of Deepin (on a drive with other OSes, but using defaults for that circumstance AFAIK) did not end up with this layout, and very many distros are proving not to use this layout. All the same, it is a perfectly legitimate layout, which I would like to support automatically (i.e. without users having to manually specify the kernel args) in OpenLinuxBoot.

[btwise]

@btwise - I have added a task for supporting distros with your layout as discussed above to #1776 - it remains on my list of something that would be good to do!

I appreciate this is Deepin, which I am happy to agree is a mainstream distro - FWIW I also think it is a very nice distro! However my install of Deepin (on a drive with other OSes, but using defaults for that circumstance AFAIK) did not end up with this layout, and very many distros are proving not to use this layout. All the same, it is a perfectly legitimate layout, which I would like to support automatically (i.e. without users having to manually specify the kernel args) in OpenLinuxBoot.

Whether or not to complete this function, so far OpenLinuxBoot can not start my Deepin without adding any parameters

[mikebeaton]

@btwise - I just re-read the issue, in my most recent reply I forgot that the main thing about your distro is that it is on MBR.

MBR drives are not officially supported on OpenCore generally - never mind in OpenLinuxBoot - and there is no realistic chance of OpenLinuxBoot autodetecting the partition UUID for your boot partition, which it would need to do to fully autoboot for you. (Unix filesystem UUID requires a bunch of code per filesystem which simply isn't in the UEFI drivers for any filesystem; normally we can sidestep this by using PARTUUID - which is available in UEFI, but does not exist on MBR - instead of UUID).

It's possible that other workarounds may arise in future, particularly if we end up writing more grub.cfg parsing code (whether this will help depends on other details of your layout) but I wouldn't rely on it any time soon.

However with distros like Deepin or Ubuntu, the kernel boot args other than root= are not particularly important (unlike in some other distros), and none of them (especially not root=) are likely to change, so you should be safe with this setup.

Again, to repeat, I have had Deepin on GPT booting with autodetected options fine, for months (since before release) - the issue you have is not specific to Deepin.

[btwise]

@mikebeaton Is it possible to add code similar to grubx64.efi in OpenLinuxBoot.efi to directly read grub.cfg file by parameter to boot，Of course I have to add a function and parameter without destroying the original design idea of ​​OpenLinuxBoot

[mikebeaton]

Can you send the output of sudo ls -F /boot run from within your distro.

[mikebeaton]

Also mount | grep /boot.

[btwise]

sudo ls -F /boot boot.log