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?
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?
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. 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org