http://bugzilla.novell.com/show_bug.cgi?id=618286 http://bugzilla.novell.com/show_bug.cgi?id=618286#c2 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from Felix Miata <mrmazda@earthlink.net> 2010-06-30 14:45:06 UTC --- (In reply to comment #1)
You said that you left the active flag checked, which means that you agreed to set the active flag to a partition relevant for your linux system. You should have set it unchecked, this would fulfill your first point of expected behavior.
In Bug 581652 I deselected the boot flag box and wound up unbootable because no active flag was set on any primary partition following installation, even though one was when installation began. There must be broken logic in what YaST is doing as a consequence of the state of the active flag checkbox. Active flag never has relevance to any but a primary partition. Therefore, as long as openSUSE installation is to a / or /boot that is a logical partition, the state of the active flag checkbox should be disgregarded - no action taken in regard to boot flags. Or better yet, a boot flag checkbox should not even be shown if the installation target is a logical. At the very least, the help for the grub settings page should clearly explain the consequences of setting the boot flag box or not.
(or tell me how I can detect that the other bootloader on the system is working and can chainload me, because it may as easily be a non-working relic of some previous installation).
Questions could be asked, such as: 1-Do you wish this installation to be/control your primary bootloader 2-Was your system bootable when you began installation 3-Will your current bootloader be chainloading this installation 4-Will your current bootloader be using this installation's Grub configfile 5-Would you like a grub stanza to paste into your current bootloader for booting this openSUSE installation Note that with standard MBR code, there must always be an active flag set on some primary in order for the system to boot a HD. Steps should be taken when standard MBR code is in place and the installation target is a logical that only affirmative direction to remove a boot flag from a primary should result in there being none set when installation has completed.
Novell - cannot support all of these scenarios; if you provide patches, they will be weocome).
I don't know how to access the source, or program. Nevertheless, if help is really needed because keeping a boot flag set on some primary when standard boot code is in place on the MBR is really so complicated, with help, I might be able to provide some. -- 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.