Re: [opensuse] leap install messed up mint
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
29.03.2016 19:42, Chris Murphy пишет:
On Tue, Mar 29, 2016 at 12:11 AM, Andrei Borzenkov
wrote: Отправлено с 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,
??? I did not say a single word about GRUB. You said that using different bootloaders will solve OP problem without explaining how. When I asked how using different bootloaders is going to solve the problem you answered that using no bootloader will do it. I was just surprised how the second statement proves the first. May be this is language problem, in this case I apologize for misunderstanding.
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
Now if you insist on discussing GRUB, I better have known shit that has known deficiencies with known workarounds, that allows us to reproduce problems to be able to fix them than unknown shit that is different on every system, changes with every firmware update, behaves unpredictably and requires physical presence to be able to do anything at all which means nobody can realistically debug it.
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
You have been told more than once that this is not possible in OP case. May be you finally explain now how to fix it using firmware boot manager instead of explaining what holy crap GRUB it - by your own word it should be so easy and simple.
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?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Mar 29, 2016 at 12:38 PM, Andrei Borzenkov
??? I did not say a single word about GRUB. You said that using different bootloaders will solve OP problem without explaining how.
No I brought up different bootloaders as examples of how multiboot in general can work by dynamic discovery rather than the static and almost perpetual broken state it's in with distro GRUBs, i.e. GRUB should be able to do a better job.
Now if you insist on discussing GRUB, I better have known shit that has known deficiencies with known workarounds, that allows us to reproduce problems to be able to fix them than unknown shit that is different on every system, changes with every firmware update, behaves unpredictably and requires physical presence to be able to do anything at all which means nobody can realistically debug it.
Yes i hear this frequently when I get mad about GRUB. And I used to believe it. Now, I think it's specious. What you say should be true, we should be able to more easily fix bugs in software and get them out to users, especially in cases where the manufacturer abandons the hardware with no more firmware updates (this is almost certainly a given as UEFI systems age). The problem is GRUB bugs just aren't getting fixed. Upstream has said more than once it wants to replace os-prober. And os-prober upstream is in something like life support mode, and even that's generous. And even the install environment can sabotage os-prober or grub-mkconfig. Not all of this is GRUBs fault, it's just that a lot of GRUB in the multboot area is both crusty and complicated because the distros don't care to put any work into it, to make multiple Linux boot more user friendly. It's practically sport for one Linux distros to intentionally obliterate the bootability of another distro. They would never get away with this when it comes to Windows or OS X, users would flip out. But somehow, breaking the boot of the previous Linux results in distro developers making excuses. Hence why I place more blame on distros, than GRUB upstream.
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
You have been told more than once that this is not possible in OP case.
I've read once, and it's not clear why so I'm not giving up on that yet. In any case, the efibootmgr boot order and next boot does appear to work for the OP and that's still 8000% easier than messing around with GRUB.
May be you finally explain now how to fix it using firmware boot manager instead of explaining what holy crap GRUB it - by your own word it should be so easy and simple.
Yeah well, early boot bugs, especially pre-boot environment bugs, are very pernicious. So hopefully the OP has old firmware and new firmware fixes the problem. If not, I recommend efibootmgr. More to the point I'd recommend disabling os-prober not even bother making all these broken boot entries for each GRUB, and just use efibootmgr to set he boot order or boot next value. One thing to not do though is use efibootmgr to change the boot order to Windows. Only use boot next for Windows! That way booting twice ensures it's possible to get back to one of the Linux distros and back to efibootmgr. If the boot order is changed for Windows first, then the system is stuck booting Windows, and it'll take booting live media to fix it again with efibootmgr. This really needs to be more user friendly is the main point. For all the ills of Windows and OS X, this works so much better there. Two Windows? 8 and 10? No problem. Two OS X's? No problem. Heck Apple's firmware boot manger is graphical, dynamically discovers OS X and Windows. And it's been this way for a long time, not in software. So of course free software could do as good or better. Actually Fedora on Macs is pretty badass, it adds a Fedora option to the built-in boot manager menu (it leverages the dynamic discovery feature of the firmware), and also to the OS X Startup disk panel. So it's not all or always shit. :-) But this is due in large part to *some* sense of standardization by Microsoft and Apple for their on-disk layouts where on Linux there's essentially no such spec or standard by which GRUB could be assured where to find critical things, rather than depending on os-prober to go on a hunting expedition. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Andrei Borzenkov
-
Chris Murphy