Felix Miata schreef op 16-04-16 20:57:
1-hibernation of multiboot systems is loaded with opportunity for destruction.
2-hibernation seems to be the primary use of swap in modern systems with copious RAM, multiple fast CPU cores, often employing SSDs dramatically lowering I/O time and diminishing efficacy of swapping
3-a partitioning proposal for a multiboot system arguably must depend on informed user input
Nice summary Felix.
Were all OS installations limiting themselves to controlling only the installation from whence provided, their jobs could be as simple as when only one installation is or will be present. Instead of every OS's boot loader trying to incorporate anticipation of abundant possibilities, control that which cannot be controlled, or wresting control from that which was last configured, a master bootloader under independent control whose job on wake is to determine sleep state before anything proceeds, then allow only compatible options to proceed, could be designed and implemented, a two-stage boot selection process. Possibly this is the realm of UEFI or an extension thereto, either of which can be no help for legacy systems.
Two-stage is generally an interesting thing anyway, for several reasons (for me): - chainloading additional loaders is one of the most essential and elementary things if you want to create a more complex operating system setup If ANYTHING should be easy, it should be chainloading into e.g. the boot record of a partition (rather than MBR/whatever). - UEFI may try to do this thing as well but at the moment, for me, the thing is utterly complicated - an advanced boot loader may be able to hide boot options, or group them together at a lower level. Grub even contains decryption options and may even be able to chainload into another bootloader that it has first decrypted.
In the mean time, a less sophisticated master boot loader under independent control could serve as reminder of danger and pitfalls, especially if its active selection details are served up with *resume<whatever> as a highlight, as Gfxboot's showopts can. Here, normal Linux kernel stanzas always contain noresume. Boot speed here, as long as not unduly delayed (boot times ~90s or less being acceptable), is a non-issue compared to predictability and reliability. Here, both Grub Legacy and IBM BM have proven suited to task.
Personally I do feel the operating system should be allowed to control the (master) boot loader. The system I would devise myself would include: - an agreement between Linux systems on how to configure a common "core" (boot configuration) - a different system where configuration is not generated as it is now (grub2) but where operating systems insert modules into some common directory - in this system the user is capable of making his/her own choice as to the "markup" or "layout" of the boot menu -- the relevent options and all of the required parameters are already there, the user now only has to pick and choose. This implies that boot parameters (locations) are saved as files. The menu is a user-editable file. The file can reference inclusions and this could for instance include symlinks to "main kernel" and "secondary kernel". If you had that, interoperability between Linux OSes would become much easier. The parameters for each OS are now controlled by that OS itself. The only thing that both (or more) operating systems can touch, is the common menu file, and/or locations where kernels are kept (ie. a shared /boot). I think this starts to resemble UEFI but now it is a much more simple thing. I don't know the details of what it should be, but that is what I would do. Grub2 is just notoriously difficult because the detection scripts may not even work for a different install. It is being asked to control the boot parameters for a different OS it may not full well know about. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org