[Bug 896369] New: Installation left two GPT partitions with legacy-boot flag set
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c0 Summary: Installation left two GPT partitions with legacy-boot flag set Classification: openSUSE Product: openSUSE Factory Version: 201409* Platform: x86-64 OS/Version: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: yast2-maintainers@suse.de ReportedBy: Larry.Finger@lwfinger.net QAContact: jsrain@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 My computer uses GPT partitions, by I am not using EFI. Of course, the legacy-boot flag must be set to indicate the active partition. I installed 13.2 on an unused partition while leaving the root partition for 13.1 alone. I also reused /home. The installation was done from the Live KDE medium of 20140909. When trying to boot after installation, the BIOS reported multiple active partitions. Investigating with gparted, the legacy-boot flag was set for both the 13.1 and 13.2 partitions. The installer failed to clear the flag when it set the one for the new installation. Reproducible: Always Steps to Reproduce: 1.Install 13.2 (Factory) on a non-EFI system with GPT 2. 3. Actual Results: System failed to boot. I am reporting this bug as "Normal" severity as it is an unusual configuration. It does, however, leave an unbootable system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c1 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmazda@earthlink.net, | |snwint@suse.com --- Comment #1 from Felix Miata <mrmazda@earthlink.net> 2014-09-12 03:21:54 EDT --- cf. Bug 581652 and Bug 618286 . The former if fixed literally would conflict with clearing an existing flag upon setting flag on some other. The latter ought to serve to avoid what happened here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c2 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell@suse.com AssignedTo|yast2-maintainers@suse.de |jreidinger@suse.com --- Comment #2 from Arvin Schnell <aschnell@suse.com> 2014-09-12 07:44:14 UTC --- yast2-bootloader deals with those flags. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c3 --- Comment #3 from Josef Reidinger <jreidinger@suse.com> 2014-09-12 08:15:58 UTC --- Yeah, it is problem that different bioses work in different way. So what is desired behavior for one, can be bad for different. In general in your case I propose to unset all legacy_boot flags and install grub to MBR of disk. To be honest usually when you have more then one system, then having GRUB in MBR is the best choice to allow easy boot to both systems. I worry, this is not something I can fix. Only possible think that comes to my mind is to add some warning, that both partition will have legacy_boot and it can for some bioses cause troubles. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c4 --- Comment #4 from Felix Miata <mrmazda@earthlink.net> 2014-09-12 05:05:32 EDT --- How about in bootloader options screen replacing the checkbox for "Set Active Flag in Partition Table for Boot Partition" with a select list or radio buttons to select any partition for the flag, or to select none, from among existing partitions? The select list or buttons could be hidden if location of Grub installation is MBR. Something else could be on each individual partition's edit screen, add a radio button for "Set an active flag on this partition"? Yet another possibility, on the installation summary of the partitioner to include a list of partitions that have active flags set, with a red warning provided for any disk with more than one flag set and Grub not installed to MBR? (In reply to comment #3)
In general in your case I propose to unset all legacy_boot flags and install grub to MBR of disk. To be honest usually when you have more then one system, then having GRUB in MBR is the best choice to allow easy boot to both systems.
Not if there is also Windows, so Larry's only two, only Linux case would be a rather limited one. Even when there are only two, last to install wins is not an optimal way to have booting configured, as upgrading the earlier installation can repeatedly make a mess that needs manual cleanup. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c5 --- Comment #5 from Josef Reidinger <jreidinger@suse.com> 2014-09-12 09:46:46 UTC --- (In reply to comment #4)
How about in bootloader options screen replacing the checkbox for "Set Active Flag in Partition Table for Boot Partition" with a select list or radio buttons to select any partition for the flag, or to select none, from among existing partitions? The select list or buttons could be hidden if location of Grub installation is MBR.
It is not so easy as some broken bios checks disk if it contain any partition with boot, otherwise it will fail.
Something else could be on each individual partition's edit screen, add a radio button for "Set an active flag on this partition"?
I worry, that it is slightly out of scope bootloader. Bootloader goal is to provide reasonable configuration for user to allow boot, this is really dangerous and expert option, where user can easily break his booting.
Yet another possibility, on the installation summary of the partitioner to include a list of partitions that have active flags set, with a red warning provided for any disk with more than one flag set and Grub not installed to MBR?
Yes, this sound more reasonable. With link that will fix it ( in sense grub to MBR and activate exactly one partition to make broken bioses happy ).
(In reply to comment #3)
In general in your case I propose to unset all legacy_boot flags and install grub to MBR of disk. To be honest usually when you have more then one system, then having GRUB in MBR is the best choice to allow easy boot to both systems.
Not if there is also Windows, so Larry's only two, only Linux case would be a rather limited one. Even when there are only two, last to install wins is not an optimal way to have booting configured, as upgrading the earlier installation can repeatedly make a mess that needs manual cleanup.
Yes, I agree. I think I need to think slightly about this setup and how to best solve it. Probably try to detect such case and offer grub to MBR and have only one activated partition. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c6 --- Comment #6 from Felix Miata <mrmazda@earthlink.net> 2014-09-12 09:47:49 EDT --- (In reply to comment #5)
...make broken bioses happy...
You keep mentioning this. It makes me think you don't understand that it is normal for legacy-compatible PC MBR code to expect to find no more than one boot flag in any HD's MBR table. The BIOS is not broken just because with legacy code in HD0's MBR a PC fails to boot when more than one flag is set. The failure with more than one set is purposeful. There's not enough space in the MBR's code block for deciding which to choose if more than one flag is set. And, the BIOS and the MBR code original writers knew the operating systems for which it was originally designed, PC-DOS, and later OS/2, will not function in a state with more than one flag set in HD0's MBR. In fact, IBM's Boot Manager would and will ensure only one boot flag is set in HD0's MBR table at every boot. My first two suggestions necessarily assume one is in expert mode and knows that multiple flags set can be boot obstacle with legacy-compatible MBR code. My #3 suggestion makes the best sense to me too, but I think a way to manage flags before reaching summary view makes good sense too. Maybe boot flag management deserves a separate screen if Grub on MBR is not selected, possibly similar to the way selecting fstab options works? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=896369 https://bugzilla.novell.com/show_bug.cgi?id=896369#c7 --- Comment #7 from Larry Finger <Larry.Finger@lwfinger.net> 2014-09-12 15:10:13 UTC --- I am not sure a separate screen is needed as it should be easy enough to scan the table and clear all legacy-boot flags before setting one for the new installation. Surely, there is equivalent code for legacy partitions as I have never had the installer leave multiple partitions active. I have never used Grub on MBR - that is a personal choice. It allows quick replacement of the primary system by booting any Live medium and changing the flags with fdisk or gparted. If possible, I would like to keep that flexibility. It is also a lot quicker, and less dangerous, than reinstalling the boot loader. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com