On Tue, Mar 29, 2016 at 12:11 AM, Andrei Borzenkov
Отправлено с iPhone
29 марта 2016 г., в 9:02, Chris Murphy
написал(а): On Mon, Mar 28, 2016, 11:44 PM Andrei Borzenkov
wrote: Отправлено с iPhone
29 марта 2016 г., в 7:09, Chris Murphy
написал(а): On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov
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.
My recommendation is the same as when I first posted. Use the firmware's built-in boot manager. It solves all of these problems, the user doesn't have to get wrapped up in bootloader esoterics and workarounds.
And how it makes your statements about boot loaders more relevant?
I've already answered that question. By repeating it, you're proposing it's not relevant in order to diminish my criticism of GRUB having shit UI/Ux when it comes to multiboot. Even when GRUB multiboot works, it's basically shit. And it being shit even compared to the built-in boot manager is pretty appalling because even that isn't great. But at least if you can figure out how to get to the built-in boot manager, it doesn't face plant with incoherent, unhelpful errors, that then require Rube Goldberg levels of hacks to work around. -- First, get a cat. Then get a spoon. Now, we're going to teach the cat how to use the spoon. Yes, we need to do this to get Linux A's bootloader to boot Linux B, but this is because Linux is so much better. Where's your cat? You need a cat. No of course this isn't documented anywhere. -- User pain and questions go down dramatically when they figure out they can do this more reliably with the firmware's boot manager. And it solves essentially all known multiboot problems whether Secure Boot related or not. User pain and questions go up dramatically when asked to hack GRUB to work around its deficiencies (in pretty much all ways but especially when it comes to multiboot). It's good and necessary for some users to know such things, because who else do we turn to when we need to know how to build and sign our own kernels and get them to work with Secure Boot? But in the meantime, as a general purpose solution, I think it's better for people to give up on GRUB when it comes to multibooting because the experience is shit. And it's not their fault. Why would I recommend something that makes users miserable? -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org