On Tue, 2016-03-29 at 10:52 -0600, Chris Murphy wrote:
On Tue, Mar 29, 2016 at 12:57 AM, Dave Howorth <dave@howorth.org.uk> wrote:
On Tue, 2016-03-29 at 08:44 +0300, Andrei Borzenkov wrote:
Отправлено с iPhone
29 марта 2016 г., в 7:09, Chris Murphy <lists@colorremedies.com> написал(а):
On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote: 28.03.2016 07:54, Chris Murphy пишет:
Long version: Basically the distros have a bunch of mutually incompatible forks of upstream GRUB.
How it is relevant in this case at all?
It's the superset position, the ultimate cause for all bootloading madness on Linux. It's not the user's fault they're so often confused about something that should be so basic and reliable. The GRUB2 multiboot experience handed to us by distros is basically crap and it's not really possible to overstate that.
This is marginally less crap with upstream GRUB. But it's actually nearly pleasant with systemd-boot (gummiboot) and rEFInd. So it's not
So rEFInd or systemd-boot will ignore file signature and allow you to load and launch anything you through at them? Otherwise please explain how using different boot loader would change anything here.
How about checking the signature and then asking the user whether they want to ignore a broken/missing signature, rather than deciding for them what is or isn't safe? At least that way I would have a system that booted nicely whilst I looked for a solution to make the nag message go away (e.g. "missing signature, do you really want to boot?")
Because that'd be writing a vulnerability into the bootloader making it easy to defeat Secure Boot. All someone needs now is to get access to your grub.cfg and just code it to blindly accept any unsigned kernel and even lie to you onscreen with a message that it's signed and safe to boot. The entire point of secure boot is to make this hard for an attacker, which means it'll be hard for you to thwart also.
I don't know enough to be sure, but are you sure that is really true? grub is signed, I believe, so that can't be modified and if the only options are 'refuse to boot' or 'only boot after a warning' then it's fairly safe, surely? And perhaps it's possible to code it so the 'refuse to boot' option is secure, e.g. by providing a separate grub.efi?
The simplest and safest solution to your problem is use the firmware built-in boot manager to select the distro, and by doing that the shim+grub combination for that distro is used to boot. An alternative to this is use efibootmgr to change the boot order or set a boot next (one-time) and then reboot.
That does sound like a nice idea, but unfortunately as I think I've already said, the firmware boot menu only shows Windows. So it won't work. My suspicion is that something in the openSUSE install has upset it, so I'm going to reinstall Mint's boot components and see if that fixes it. I also discovered that btrfs support is not installed by default in Mint, so now I've installed it, perhaps Mint will discover openSUSE and its grub will be able to boot everything. Or failing that, I'm coming around to Neil's view that secure boot simply isn't worth the price. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org