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