On Sun, 2016-03-27 at 14:17 +0300, Andrei Borzenkov wrote:
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.
He did suggest using efibootmgr to control what is booted, but as I've said the EFI boot menu only displays Windows so that's no good to me as a long-term solution, only as a stopgap way to boot Mint to try other things.
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?
You said '"normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs'. I took that to mean that os-prober can handle other file systems, so if I reinstall openSUSE on ext4 or reiserfs say then I might be able to persuade Mint's os-prober to give me the information I think I need to try using its grub to boot openSUSE, which would solve my problem.
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?
It seems you only read part of Neil's message. Here is the relevant part again: 'I suggest you check whether Mint can boot opensuse. When I last checked, it could. The boot process for Mint was less secure, in that it wasn't checking kernel signatures. (It was only checking the "shim" signature).' That is what I am trying to do.
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?
I'm willing to contribute good documentation when I understand something. I'm very much hoping that I won't need to understand any more than how to import a key.
That is, assuming that the very first Google hit searching for "mokutil" is not enough ... https://sourceware.org/systemtap/wiki/SecureBoot
Yes, I saw that link. I didn't bother reading it since it appears to be about something different. Even having read it, I'm no wiser.
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.
Neil explained why he thought trying to get openSUSE to boot Mint was futile, unless I got the kernel signed, so it seems likely to be easier to get Mint to boot openSUSE, which is why I want to understand how to get its os-prober to detect openSUSE or otherwise get whatever I need to put in its grub configuration. Can I just copy some details from openSUSE's grub?
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