http://bugzilla.novell.com/show_bug.cgi?id=548993
User mrmazda@earthlink.net added comment
http://bugzilla.novell.com/show_bug.cgi?id=548993#c22
--- Comment #22 from Felix Miata 2009-11-05 07:46:17 MST ---
Created an attachment (id=325776)
--> (http://bugzilla.novell.com/attachment.cgi?id=325776)
Kubuntu Karmic Grub2 boot menu file (grub.cfg)
Multiboot can get rather complex pretty quickly as new operating systems are
added. Installers shouldn't try to be smarter than they can be and bite off
more than they can chew with expectation of success.
Those installing openSUSE on a system with more than 2-3 operating systems
already installed should be presumed to know more than a little about multiboot
generally, and specifically how to manage their boot configuration manually
better than any installation program can do.
This monstrosity was the Kubuntu installer's attempt to locate and include
every bootable partition on the target system. Kubuntu was told to install its
/ to sda13 and write the bootloader to its / partition, leaving the MBR
untouched. Not only is its attempt in the form of this file close to
incomprehensibly corpulent, when the previous bootloader chainloads to its
partition all that results is a Grub1 prompt.
I take the position that unless a Linux installer is explicitly told to put /
or /boot on an active primary partition, or put on same that is not already
active but to make it active, or to put its bootloader on the MBR, it should
presume another bootloader is already installed that can chainload or load
directly the new installation. A consequence of this presumption is that the
new bootloader need not facilitate booting anything other that what is
currently being installed. IOW, if installing to a logical, and not explicitly
told to put bootloader on MBR, it should install nothing at all whatsoever
anywhere except to the target / and/or /boot; and the new bootloader menu
should have entries for the new installation only, or possibly one additional
entry to chainload the active primary as a fallback.
Now if the active primary partition has Windows' NT Loader, the installer
should probably not be so presumptuously intrusive as to modify boot.ini.
Nevertheless, NT Loader can effectively "chainload" Grub/Lilo, and this can be
facilitated by copying the new Linux partition's boot sector to a file NT
Loader on the active partition can load, along with a howto and/or suggested
replacement boot.ini file that the user who has not explicitly told the
installer to put the new bootloader on the MBR can choose to use or not. It
might even put a .lnk file to find that information into the all users' desktop
"folder" in the Documents and Settings tree. The installer also could copy that
information to the new /root/Desktop directory and/or an available removable
media.
For those not familiar with using NT Loader to boot Linux I suggest to read
this: http://fm.no-ip.com/install-doz-after.html
openSUSE installer behavior and
http://en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_w...
and http://en.opensuse.org/SDB:Prefered_bootloader_options need to be kept
sync'd, incorporating the principles of respect for what already is and of
least surprise in choosing what behavior should be.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.