Andrei Borzenkov composed on 2016-04-16 19:04 (UTC+0300):
Felix Miata composed:
The solution used here, where all machines are BIOS, is limiting bootloader control of each installation exclusively to its own installation, loaded through a bootloader independently controlled.
How does it solve the problem discussed here?
There's an underlying issue in $SUBJECT: "new installer". The installer is being rebuilt anew, which is ideal opportunity for thinking outside the box, possibly evolving what an installer can or should do. We've seen in the thread multiple issues regarding swap configuration besides swap device count, among which: 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 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. 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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org