On Wed, Apr 13, 2016 at 9:37 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
14.04.2016 00:17, Chris Murphy пишет:
I suggest you keep doing what you've been doing, the path of lease resistance, until there are resources to do this correctly. And to do it correctly means getting distros together and agreeing on scope and details of a bootloader specification or standard. So far there's an insufficient concensus; and GRUB upstream is opposed to the specs as written so far.
Reference please. As far as I remember GRUB upstream maintainer did not like specific patch implementing parsing of these specs that is part of Fedora (or at least was proposed there). Nobody ever submitted support for it upstream, so how can you say upstream is opposed to it?
The spec itself was considered problematic, not just the Fedora implementation of that spec (which departs from the spec in meaningful ways). No direction on how to improve the spec to meet upstream's concerns has been given. http://lists.gnu.org/archive/html/grub-devel/2013-06/msg00023.html The entire point of a boot specification is constraint, so naturally there will be use cases that can't be supported. The spec is a subset of common functionality designed to make things easier for users who will accept standardization via completely automatic, non-customizable, installations. The experts can do things how they've been doing it if they want.
So until the bootloader upstreams will take multiboot Linux seriously, you pretty much have to continue to give up on this pipe dream.
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
I assume Microsoft and Apple are also willing to support it?
That's misplaced, they're not going to change. And there isn't a problem on their end anyway. Microsoft and Apple support n and n+1 versions simultaneously installed, and that does work reliably for both of them. They also haven't changed their boot methods in a sufficiently long period of time that they're each defacto standards. The problem really is for the users who want two or more Linux distro-versions. I can name at least one major distro that face plants on setting up boot out of the box for n and n+1, it's that bad. As soon as n+1 is installed, n can't be booted without user intervention. Horrible. Now maybe we should just admit that only experts get to multiboot? Maybe regular users just are just out of luck?
Part of the problem of doing this correctly is that it should be encrypted by default.
If the current (i.e. old) installer finds a swap partition that is big enough for our needs, it will use it instead of creating a separate one. Although this can save some space, we are wondering if it's a good idea to do that by default. It effectively means that we will share the swap space with another Linux installation in the same computer. During normal operation that can be fine, but the swap partition is also used for suspend to disk (i.e. hibernate). That means that if we start LinuxA while LinuxB is hibernated, we will make impossible for LinuxB to resume the suspended execution.
Why is it even remotely easy to boot Linux A if Linux B is hibernated?
Because if Linux B is booted through bootloader manager by Linux A, then Linux B has no way to modify its configuration, it simply is not aware of it.
I know, that's my complaint. Windows and OS X have had such mechanisms for a very long time, 20+ years. The mechanism details isn't what matters, it's the fact they designed for this use case. Linux bootloader upstreams and distros haven't. They really simply haven't done that work. It's only accessible by expert users.
And having common bootloader specs still leaves the question which OS instance manages bootloader *installation* and update. So this requires quite a big change in how this part is managed - and this in every distribution out there.
The spec says each OS manages those updates into a common shared location in an unambiguous way for a single (conforming) bootloader to act upon. Since they both can't be running at the same time, it's reasonable to conclude the current boot communicates user intent via a common shared configuration location and file format. And yes, no kidding, big change. Cooperation among distros is like finding water in a desert. Maybe it's even more rare, and the whole idea is just doomed to evaporation and what we have is as good as it's going to get. And if that's true, then I just don't see how we proceed to the next step which is safely supporting hibernation in a multiboot context. If the booting of two or more Linux OS's can't be agreed upon cooperatively I don't see how hibernation of those OS's gets sorted out. Any installer asked to do a multiboot installation should probably configure the system in such a way that the user can't (easily) hibernate the system. Experts will just have to go unhide/enable hibernation manually since they're aware of the risks. It's not fair to do that to regular users asking for automatic installations from a GUI installer. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org