On 07/25/2015 11:39 PM, Felix Miata wrote:

Larry Finger composed on 2015-07-26 02:17 (UTC-0500):

Your post seems to have come from the future.

That was one other side-effect of installing 42.1 that I did not catch at the time.

...

After installation of openSUSE 42.1-RC1 to a second partition on my system with the legacy BIOS bootable option set, I ended up with two partitions having the "boot" and "boot_legacy" flags set. Of course, the BIOS refused to boot. To work around this situation, I needed to boot a rescue system and use parted to toggle the legacy_boot flag off for one of the two partitions.

...

This bug is identical to that of Bug 848609, which was "fixed" in 13.1. Obviously, it has crept back in with the SLE code.

...

This bug is reported as Bug 939453. https://bugzilla.opensuse.org/show_bug.cgi?id=939453

Larry, I'm guessing y2logs will be wanted attached to see if the checkbox was set to "Set active Flag in Partition Table for Boot Partition". IIRC, it has always been pre-selected whenever I've installed, regardless whether bootloader target was a primary or logical partition. I've been in the habit of automatically deselecting it, as my bootloader target is virtually always to a logical, where the boot flag is entirely irrelevant.

No matter what check boxes are selected or deselected, installation should never leave a user's system unbootable. Fortunately, I had been through this before and knew the fix. A newer user might not have a clue. As long as a particular installation needs to set the "legacy_boot" flag, it absolutely must clear that flag on all other partitions. This is a gpt disk setup with no logical partitions - there are 10 partitions that are all equal. This configuration is what you get when you convert an EFI-partitioned disk into a legacy boot form. I did that because (1) Windows 8 refused to boot, and (2) I clobbered its boot partition while trying to fix it. As I really had no interest in booting Windows, I made the change to get Linux up and running. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07/26/2015 01:30 PM, Chris Murphy wrote:

On Sun, Jul 26, 2015 at 9:51 AM, Larry Finger wrote:

...

As long as a particular installation needs to set the "legacy_boot" flag, it absolutely must clear that flag on all other partitions.

I thought that flag was only used by syslinux gptmbr.bin use case, which suggests BIOS firmware and a GPT partition scheme. That itself is an odd combination because there are a sufficient number of BIOS firmware systems that face plant on GPT that it's not a good default combination.

GRUB doesn't make use of legacy_boot, whether on BIOS or UEFI firmware. And it's next to pointless on UEFI firmware systems because the UEFI spec says any code in LBA 0 is to be ignored (except by CSM).

I'm under the impression these are all sufficiently edge cases they shouldn't happen on installations, and just be used for things like installation media.

This may be an edge case, but I'm not sure how rare it is. The bug report referenced in my first E-mail was not posted by me - there are at least two of us. The other one was in 13.1, I first hit the case with 13.2, and now it is present in 42.1. My BIOS has two options for boot - UEFI and CSM. The text says that the later option is for an OS that expects traditional BIOS booting capability. That is the setting that I am using. The legacy_boot flag is not used by GRUB as it is used by the BIOS to find the correct GPT partition to boot in the same manner that the active partition is selected for the boot code in a traditional DOS-type partition scheme. We all know what happens if you have more than one active partition. That is what is happening here. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. composed on 2015-07-27 02:45 (UTC+0200):

on a BIOS machine, it would just boot the first partition marked bootable, even if all four were marked such.

I can't remember ever finding a BIOS HD0 bootable while having more than one boot flag set on its primary partitions. My experience is unless there is exactly one flag set, boot process simply stops post-POST, sometimes with a cryptic message, sometimes with no message at all.

The code was too small to be able to be clever: so it just booted the first one it could find :-) -- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Jul 26, 2015 at 6:20 PM, Larry Finger wrote:

On 07/26/2015 01:30 PM, Chris Murphy wrote:

...

On Sun, Jul 26, 2015 at 9:51 AM, Larry Finger wrote:

...

As long as a particular installation needs to set the "legacy_boot" flag, it absolutely must clear that flag on all other partitions.

I thought that flag was only used by syslinux gptmbr.bin use case, which suggests BIOS firmware and a GPT partition scheme. That itself is an odd combination because there are a sufficient number of BIOS firmware systems that face plant on GPT that it's not a good default combination.

GRUB doesn't make use of legacy_boot, whether on BIOS or UEFI firmware. And it's next to pointless on UEFI firmware systems because the UEFI spec says any code in LBA 0 is to be ignored (except by CSM).

I'm under the impression these are all sufficiently edge cases they shouldn't happen on installations, and just be used for things like installation media.

This may be an edge case, but I'm not sure how rare it is.

I thought openSUSE exclusively used GRUB 2? gptmbr.bin is syslinux/extlinux bootloader code that goes on LBA 0, and looks for which GPT partition has the legacy_boot attribute set to know where to continue loading code. But it doesn't make sense to use gptmbr.bin to jump to GRUB's core.img. So is extlinux being used in these cases?

The bug report referenced in my first E-mail was not posted by me - there are at least two of us. The other one was in 13.1, I first hit the case with 13.2, and now it is present in 42.1.

Yes. This comment is unexpected unless extlinux is the bootloader. https://bugzilla.opensuse.org/show_bug.cgi?id=848609#c3

My BIOS has two options for boot - UEFI and CSM. The text says that the later option is for an OS that expects traditional BIOS booting capability.

legacy_boot is really an odd duck. It's a GPT partition attribute, and is an analog to the MBR partition active bit. But something has to know what this GPT partition attribute is, and the only code I know that understands it is gptmbr.

That is the setting that I am using. The legacy_boot flag is not used by GRUB as it is used by the BIOS to find the correct GPT partition to boot in the same manner that the active partition is selected for the boot code in a traditional DOS-type partition scheme. We all know what happens if you have more than one active partition. That is what is happening here.

Strictly speaking the firmware is completely unaware of the legacy_boot attribute, it's only something the gptmbr.bin initial bootloader code is looking for to know where to continue loading bootloader code. Which is why I'm confused. gptmbr.bin is part of the syslinux package. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Jul 26, 2015 at 9:41 PM, Andrei Borzenkov wrote:

В Sun, 26 Jul 2015 19:23:03 -0600 Chris Murphy пишет:

...

On Sun, Jul 26, 2015 at 6:20 PM, Larry Finger wrote:

Strictly speaking the firmware is completely unaware of the legacy_boot attribute, it's only something the gptmbr.bin initial bootloader code is looking for to know where to continue loading bootloader code.

Which is why I'm confused. gptmbr.bin is part of the syslinux package.

GPT_MBR = "/usr/share/syslinux/gptmbr.bin" DOS_MBR = "/usr/share/syslinux/mbr.bin" def generic_mbr_file @generic_mbr_file ||= mbr_is_gpt? ? GPT_MBR : DOS_MBR end

YaST writes it if you check "install generic MBR".

Oh, you know what? I spaced out that openSUSE doesn't put core.img in either the MBR gap or BIOSBoot. They're sticking it into the 64KB bootloader pad on Btrfs. Since core.img starts right at the first sector of the Btrfs partition, gptmbr.bin and mbr.bin will find it when the Btrfs partition is marked bootable. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Sun, 26 Jul 2015 22:08:37 -0600 Chris Murphy пишет:

On Sun, Jul 26, 2015 at 9:41 PM, Andrei Borzenkov wrote:

...

В Sun, 26 Jul 2015 19:23:03 -0600 Chris Murphy пишет:

...

On Sun, Jul 26, 2015 at 6:20 PM, Larry Finger wrote:

Strictly speaking the firmware is completely unaware of the legacy_boot attribute, it's only something the gptmbr.bin initial bootloader code is looking for to know where to continue loading bootloader code.

Which is why I'm confused. gptmbr.bin is part of the syslinux package.

GPT_MBR = "/usr/share/syslinux/gptmbr.bin" DOS_MBR = "/usr/share/syslinux/mbr.bin" def generic_mbr_file @generic_mbr_file ||= mbr_is_gpt? ? GPT_MBR : DOS_MBR end

YaST writes it if you check "install generic MBR".

Oh, you know what? I spaced out that openSUSE doesn't put core.img in either the MBR gap or BIOSBoot.

That depends on boot device selected in bootloader configuration.

They're sticking it into the 64KB bootloader pad on Btrfs. Since core.img starts right at the first sector of the Btrfs partition, gptmbr.bin and mbr.bin will find it when the Btrfs partition is marked bootable.

Even when installed in partition grub consists of two parts - boot sector that is installed in partition boot record and core.img that is installed elsewhere. Do not confuse them. [gpt]mbr.bin finds only the former; where the latter is located is encoded as absolute position in boot sector as usual. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org