27.03.2016 13:37, Dave Howorth пишет:
On Sat, 2016-03-26 at 21:22 +0300, Andrei Borzenkov wrote:
26.03.2016 14:59, Dave Howorth пишет:
I'm having trouble with this step. I'm now running Mint, but running its os-prober (well, Ubuntu's) only shows Windows. It doesn't even show Mint itself,
The purpose of os-prober is to look for other installed OS, so of course it won't show OS instance it runs under.
Thanks. That seems an odd restriction, but anyway it's not the point. So how can I discover the information I need for Mint's grub to try to boot openSUSE to see if Neil's suggestion works?
os-prober is not related to Neil's suggestion in any way. What he suggested was that you use your firmware ("BIOS") boot menu to select what OS to boot. Assuming your firmware offers this possibility in the first place. Or to flip default boot menu entry - again, in firmware, not in bootloader menu.
let alone openSUSE. I gather there is something called os-prober-efi but it's not part of the Mint repositories so I'm not sure whether I need to use that or use some flag to the Mint os-prober, or something else?
It is quite possible that "normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs. We carry rather extensive btrfs patch for it.
Are these tricks documented anywhere? Would my problems go away if I reinstalled openSUSE using some other more mature filesystem for root?
That depends on your definition of "documented". Interested parties could certainly read patch to find out what it does. Anyway, I said "possible" - I cannot say what was the problem without seeing log of os-prober run on Mint. But I already had evidences of other distributions failing to detect openSUSE on btrfs. And what "matureness" of btrfs or lack thereof has to do with it?
Anyway, you would get the same problem even if os-prober worked - Mint (Ubuntu) loader trusts only Mint (Ubuntu) keys.
Are you saying Neil is wrong or that his information is outdated? That it is definitely not worth trying his suggestion?
How is it related to what Neil was saying? He suggested to add each OS loader to firmware menu directly, while os-prober adds "foreign" kernels to bootloader menu of specific OS. You already tried to add Mint kernels to openSUSE bootloader; why do you expect different result when adding openSUSE kernel to Mint bootloader?
Another possibility is to create your own kernel signing key, and sign the Mint kernel yourself. I was doing that for a while. I no long have Mint installed. But I do have Kaos installed, and I'm signing that kernel with my own key so that I can boot it with secure-boot.
Hmm, that seems like more moving parts than I'd ideally like. I'm looking for the closest approximation of 'just works out of the box' that I can find.
As I already told you, you can enroll key used by distribution to sign kernels. This should be enough to do just once and if you enroll both openSUSE and Mint (Ubuntu) keys, you should be able to boot both using shim.
This is supposed to work with mokutil, using
mokutil --import file.der
OK, and as I already said, mokutil seems to have appalling documentation.
Documentation does not appear out of nowhere. Are you willing to contribute good documentation after you managed to get it working? That is, assuming that the very first Google hit searching for "mokutil" is not enough ... https://sourceware.org/systemtap/wiki/SecureBoot
What is file.der?
This is public part of certificate used to sign loader and kernel, packaged in binary format. Assuming Mint is based on Ubuntu you probably could simply try Canonical certificates from http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/... Otherwise you have to contact Mint community and ask them where to find it. If you can't, openSUSE key is shipped with grub2 package in /usr/lib64/efi/*.der.
I know as little as I can get away with about booting and less than I should about certificates.
This adds UEFI variable that contains request to MokManager to enroll certificate into boot-time database (this database is not accessible after bootloader has finished, so two stage process). On next boot shim should launch MokManager.efi, which will ask you password (which was set using mokutil --password) and import keys. These imported keys should be used by every shim, shipped by every distribution.
Cheers, Dave
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org