http://bugzilla.suse.com/show_bug.cgi?id=1142229 José Iván López González changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jreidinger@suse.com Flags| |needinfo?(jreidinger@suse.c | |om) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c4 --- Comment #4 from José Iván López González --- I have tried a similar scenario by myself. During the installation I have used the Expert Partitioner to perform this storage configuration: /dev/sda1 -> /home (ext4) /dev/sda2 -> swap /dev/sda3 -> extended partition /dev/sda5 -> root (btrfs) In the installation summary, I haven't modify the default bootloader configuration, that is: options "Boot from MBR" and "Set active flag in partition table for boot partition" are checked. The system was installed with no issues/warnings, and it was able to boot. See screenshots. So, please, attach your logs, because it should be able to boot after importing the mount points. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c6 --- Comment #6 from José Iván López González --- Created attachment 811163 --> http://bugzilla.suse.com/attachment.cgi?id=811163&action=edit cfdisk -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c8 --- Comment #8 from José Iván López González --- One note. I have tried the same but importing mount points, and it also works. Definitely, we need logs to check what failed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c14 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint@suse.com Flags|needinfo?(yast2-maintainers |needinfo?(snwint@suse.com) |@suse.de) | --- Comment #14 from Josef Reidinger --- (In reply to Neil Rickert from comment #11)

...

well, for me it is more likely just coincidence that it is the first logical partition or qemu do some magic in its BIOS as on real hardware it is problem with jumping to boot code on logical partition. Does it work if logical partition is not the first one?

I doubt that there is any special magic. And I doubt that it matters which logical partition is used.

My partition (in a VM) was about the same as described in comment 4 above. However, I carefully created the first partition so that there was minimal space between the MBR and the first partition. Normally, there would be 2047 blocks there. I used: parted -a cylinder /dev/sda

I then created a new label (msdos partitioning), and a new partition. I set the first partition to start at offset 0M. And parted set the partition to begin the first sector beyond the MBR.

Here's the real problem:

When I tell the installer to boot from a partition, it normally chooses the partition containing "/boot". But it makes an exception. If the partition containing "/boot" is a logical partition, then the installer changes that to boot from the extended partition. And if "/boot" is part of a "btrfs" partition, that is never going to work.

I understand the reasoning for this behavior. Traditionally, one can only boot from a primary partition. But the generic code that the installer puts in the MBR can actually boot from a logical partition. And, in case "/boot" is in a "btrfs" partition, it should just go with installing booting there and setting that logical partition as active.

Steffen - can you confirm that generic boot code from syslinux can boot from logical volume? Neil - another issue can be that some BIOSes refuses to boot from disk if there is no primary partition with active flag. We have such bug reports in past, so we set that active flag even when grub2 is in MBR which does not need it. Seymour Metz - on that page is also hint how to invoke shell commands and e.g. also how to setup network connection. So what I usually do is save_y2logs followed by scp that copy it. USB as Neil mention is also option. but I think here we do not need logs anymore as issue is quite clear. Not enough MBR gap and also not enough space in extended partition. We are just checking what is the best solution to make it working everywhere. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c16 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchang@suse.com Flags| |needinfo?(mchang@suse.com) --- Comment #16 from Josef Reidinger --- OK, so the last piece of information for making the best possible proposal. Michal - when grub2 does not fit into extended partition? only for btrfs? can we somehow detect it in advance that logical is only option when mbr gap is too small and also extended does not fit? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c20 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mchang@suse.com) | --- Comment #20 from Michael Chang --- (In reply to Josef Reidinger from comment #16)

OK, so the last piece of information for making the best possible proposal.

Michal - when grub2 does not fit into extended partition? only for btrfs?

The btrfs booting requires bootloader to know how to reading for it, which means the boot code can't be realized by the size less than 512byte.

can we somehow detect it in advance that logical is only option when mbr gap is too small and also extended does not fit?

We came up with the patch for bsc#841247, the mbr has to be used as bootloader location and once the mbr gap too small is encountered, it will fallback to btrfs partition for core.img.

https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-setup-t...

The mbr boot code in this case is not syslinux, but grub's own stage1, thus activation of ebr/pbr should be irrelevant. It looks like the report was YaST suggested to use EBR for grub2, which doesn't work for btrfs (it failed in a way like mbr gap, but "ebr too small"). IMHO YaST could go straight to use MBR for btrfs because above patch should workaround the occasion of mbr gap being too small. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c22 --- Comment #22 from Michael Chang --- (In reply to Michael Chang from comment #21)

(In reply to Michael Chang from comment #20)

...

(In reply to Josef Reidinger from comment #16)

...

The mbr boot code in this case is not syslinux, but grub's own stage1, thus activation of ebr/pbr should be irrelevant.

Well, it is relevant because some bios apparently cares the active flag being set correctly .. but that's for the partition table which should be handled separately, not the boot code itself in the mbr.

I meant grub's own stage1 doesn't care active flag so the partition map can be handled separately to make the bios happy. While the standard mbr or syslinux and so on which could have a hard fight with bios for the active flag ... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c23 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mchang@suse.com) --- Comment #23 from Steffen Winterfeldt ---

We came up with the patch for bsc#841247, the mbr has to be used as bootloader > location and once the mbr gap too small is encountered, it will fallback to btrfs partition for core.img.

Michael, this does not work. It runs into (Leap 15.1): # grub2-install --target=i386-pc --force --skip-fs-probe /dev/sda Installing for i386-pc platform. grub2-install: warning: this msdos-style partition label has no post-MBR gap; embedding won't be possible. grub2-install: error: filesystem `btrfs' doesn't support blocklists. Am I missing something? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c24 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mchang@suse.com) |needinfo?(snwint@suse.com) --- Comment #24 from Michael Chang --- (In reply to Steffen Winterfeldt from comment #23)

Michael, this does not work. It runs into (Leap 15.1):

# grub2-install --target=i386-pc --force --skip-fs-probe /dev/sda Installing for i386-pc platform. grub2-install: warning: this msdos-style partition label has no post-MBR gap; embedding won't be possible. grub2-install: error: filesystem `btrfs' doesn't support blocklists.

Am I missing something?

No. Somehow without any post mbr gap available the returned error code is GRUB_ERR_FILE_NOT_FOUND rather than GRUB_ERR_OUT_OF_RANGE. I have added that error code to the fallback condition to try filesystem embed. Would you please help to verify the fix in the repository ?

https://download.opensuse.org/repositories/home:/michael-chang:/boo:/1142229...

FWIW I also tested and it worked as expected. :) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c26 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mchang@suse.com) |needinfo?(snwint@suse.com) --- Comment #26 from Michael Chang --- (In reply to Steffen Winterfeldt from comment #25)

The new grub2 works.

But I've one question: if the mbr gap is there grub2 embeds around 90k into the mbr gap. If it's not there and it uses btrfs it is fine using the 64k at the start of the btrfs.

Why the difference in size?

Did you try --no-rs-codes options to grub2-install ? The added size in mbr gap might come from the reserved space for Reed–Solomon codes. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1142229 http://bugzilla.suse.com/show_bug.cgi?id=1142229#c28 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #28 from Steffen Winterfeldt --- Ok, to sum up the situation: The installer always proposes to install grub into the mbr. If that's not what's wanted, say due to special circumstances, you can still change the location to someplace else manually. But this is not a supported scenario. And the warning popup reminds you of that. If you opt for installing the bootloader into a logical partition with generic boot code in the mbr, this will work as long as you do *not* set any active primary partition (only the logical partition). Some BIOSes insist on an active primary partition, though. In this case you've simply run out of luck. One could change the generic boot code to tolerate this but this would result in incompatible behavior (afaics). With Michael's grub2 fix in comment 24 all has been done, I think. -- You are receiving this mail because: You are on the CC list for the bug.