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 <mrmazda@earthlink.net> 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.