Hi,
I can’t finish instalation on one of my computers when using BTRFS as root filesystem.
It always fails after some time (with disk still running) because it cannot write boot loader.
With EXT4 it is ok.
Strange is that at another, installed to fresh, clean, newly partitioned SSD it works
well even with BTRFS…
Any idea?
Shini
If the failing computer is legacy BIOS HDD, in order to boot you will need a separate /boot partition with a non-btrfs file system on it e.g. ext2, etc.
Some extra comment about the separate /boot: It can be relatively small, but large enough for multiple kernel support and Grub2. I use a logical partition with ext2, 500MiB (used about 40% with Tumbleweed installed), and the boot flag is set there.
That’s definitely not true, at least not in general.
I have installed openSUSE 13.1 with a single btrfs partition (no separate /boot) on a legacy BIOS sytem one year ago without any problem.
During the weekend I upgraded to 13.2, still no problem… 
But, AIUI, the gap between the MBR and the first partition has to be big enough to embed grub2’s boot code, as it is apparently not supported to embed it in a btrfs partition.
This seems to be a problem when you use MSDOS/Windows tools to partition the disk, i.e. the gap is too small then and grub2’s core.img doesn’t fit in.
If you use YaST to partition the drive it should just work even without a separate /boot.
Of course, as grub2 does have some trouble with btrfs (in particular it cannot write its environment, which means that if you set an entry to boot this will be permanent as grub2 cannot reset it), a separate /boot might be a good idea anyway.
So shrinking and moving first partition should help? It is HP NB, shipped with Windows, i just
shrunk W. partitions and made extended one for root/home/swap at the end.
Btw. that embeding to btrfs will be supported later?
Yes, at least that’s what I think.
If the first partition starts on sector 63 (as used to be the default, in particular with MSDOS/Windows), the gap is too small.
Moving the partition back should help.
IIANM, YaST normally uses Megabyte-aligned partition boundaries, also to speed up access on 4K sector drives.
Btw. that embeding to btrfs will be supported later?
No idea.
There are are other limitations as well in grub2’s btrfs support.
It might not even be possible to support every btrfs feature, grub2 is just a boot loader after all, no operating system.
But I do not have enough insight to really answer that question.
A separate boot partition (with ext2 preferably) should of course prevent all possible problems, at least if it’s big enough (it has to have space for at least 3 kernels and their initrds).
It should be supported. Do you have reproducible case when grub2-install fails on btrfs partition?
I don’t.
As I wrote, I never had such a problem here.
But I think I read a bug report about that recently. Or was it a forum thread?
Of course! The separate boot partition was advised in the online openSUSE Reference Manual when I last visited it. Unfortunately it’s “down for maintenance”, so I couldn’t check the reference.
my partitions, maybe it help you…
/dev/sda1 * 63 805306319 805306257 384G f W95 Ext’d (LBA)
/dev/sda2 805306368 941115391 135809024 64,8G 7 HPFS/NTFS/exFAT WINDOWS
/dev/sda3 941115392 972572671 31457280 15G 7 HPFS/NTFS/exFAT RECOVERY
/dev/sda4 972572672 976756735 4184064 2G c W95 FAT32 (LBA) BIOS
/dev/sda5 126 67103504 67103379 32G 83 Linux SYSTEM
/dev/sda6 67103568 134207009 67103442 32G 83 Linux OLD SYSTEM
/dev/sda7 134207073 150978869 16771797 8G 82 Linux swap / Solaris
/dev/sda8 150978933 805306319 654327387 312G 83 Linux HOME
I alternate system partitions with each reinstall to keep last system working…
I tried to install BL to MBR + root to replace old BL and it failed. EXT4 is ok.
There was recent report about failure to install in MBR (as opposed to partition), with one probable cause - too small post-MBR gap (old style 63 sectors). But btrfs leaves 128K for bootloader on a device, so installing on btrfs partition should be possible.
Yes, that was what I was suggesting here.
The post MBR-gap is too small, so the code doesn’t fit in.
And the output he posted does confirm this.
But AIUI, grub2-install will fall back to install to that gap if it cannot install the code into a partition for whatever reason. Correct?
@shini42:
As I understand it, the first failed installation did not install grub2 to the MBR, or did it?
I.e. did you select “Install to MBR” or “Install to / partition” or what?
But btrfs leaves 128K for bootloader on a device, so installing on btrfs partition should be possible.
Ok, so apparently the problem should not be btrfs at all.
Maybe perl-bootloader or whatever tried to install to a different partition where it is not supported?
Seeing that /dev/sda1 is marked active, maybe it wanted to install to this one?
Could that be a bug in perl-bootloader or whatever, or rather a wrong configuration (i.e. “Install to MBR” selected although the post MBR gap is too small)?
But why did it work with ext4 as / filesystem then, but failed with btrfs?
Maybe just the boot loader settings were different, i.e. not “Install to MBR” selected?
Hm.
On 2014-11-05 15:56, wolfi323 wrote:
> But, AIUI, the gap between the MBR and the first partition has to be big
> enough to embed grub2’s boot code.
Thus, you are installing grub on the disk (after the mbr), not on the
first partition. It does not affect what the partition is.
The problem is, I understand, when you install generic mbr, and place
grub on an btrfs primary (classic) partition.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes.
Or you try to install to a partition where it is not supported (NTFS e.g.), it will fall back to install to the post MBR gap then instead, I think.
And in shini42 fstab output, /dev/sda1 is the active partition, so grub has to be installed either to the MBR or /dev/sda1, otherwise the system won’t boot.
And /dev/sda1 is no btrfs partition at all. It actually is a logical partition.
The problem is, I understand, when you install generic mbr, and place
grub on an btrfs primary (classic) partition.
But according to arvidjaar this should actually be supported, IIUIC.
On 2014-11-07 15:16, wolfi323 wrote:
> Or you try to install to a partition where it is not supported (NTFS
> e.g.), it will fall back to install to the post MBR gap then instead, I
> think.
It can’t do that! There may be something else in there, like lilo, grub
1, another grub 2, other booters…
>> The problem is, I understand, when you install generic mbr, and place
>> grub on an btrfs primary (classic) partition.
> But according to arvidjaar this should actually be supported, IIUIC.
I’m surprised that btrfs has problems with this configuration.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Just to add a case that actually works with GRUB2 installed to btrfs root/ partition, generic code to MBR.
The Linux stuff is all within the extended partition, so don’t know what happens with a primary root/.
All went smooth in the past with EXT3/4 several times.
This time (13.2RC1 actually) the DVD installer complained about not being able to install the bootloader.
Upon recovery, it turned out that GRUB2 was actually installed to the btrfs root/, only the boot flag was still on sda1 (the Win* one).
With the boot flag set to sda8, GRUB2 booted like a charm.
Device Boot Start End Sectors Size Id Type
/dev/sda1 63 127684682 127684620 60,9G 7 HPFS/NTFS/exFAT
/dev/sda2 127700685 215046089 87345405 41,7G f W95 Ext'd (LBA)
/dev/sda3 215109632 231176191 16066560 7,7G 7 HPFS/NTFS/exFAT
/dev/sda4 231184384 234438655 3254272 1,6G 7 HPFS/NTFS/exFAT
/dev/sda5 127700748 131911678 4210931 2G 82 Linux swap / Solaris
/dev/sda6 152906733 190097144 37190412 17,8G 83 Linux
/dev/sda7 190097208 215046089 24948882 11,9G 83 Linux
/dev/sda8 * 131911680 152905727 20994048 10G 83 Linux
My feeling too…
Hm?
There may be something else in the MBR, there maybe something else in the root partition’s boot loader space.
There even might be something else (a different grub2 version e.g.) on the /boot partition already that will be overwritten.
Please note, I do not know whether it does that, and I don’t want to investigate right now either. This was just speculation.
It might just fail when told to install to a partition that is not supported, but that won’t change the end result, an unbootable system.
>> The problem is, I understand, when you install generic mbr, and place
>> grub on an btrfs primary (classic) partition.
> But according to arvidjaar this should actually be supported, IIUIC.
I’m surprised that btrfs has problems with this configuration.
Hm? It’s not btrfs that has problems with this configuration.
This is about the boot loader installation, not the filesystem.
And upto now we do not know whether there are problems with this configuration (generic MBR, grub on primary partition).
I do have the same configuration here (btrfs on /dev/sda4 which is /), and it worked fine. With 13.1 and 13.2 (which was an online upgrade, but still).
So I think just having btrfs on a primary partition is not the problem, something else is.
But we do not even know what boot loader options the OP set. (install to MBR, root, …)
IMHO, with his setup an installation to the MBR is bound to fail, as the post-MBR gap seems to be too small.
And OTOH, even the OP mentions that it worked just fine on a freshly partitioned SSD (with btrfs).
Btw, there’s even a mention in the release notes meanwhile, that there might be problems (probably because of the partitioning, i.e. first partition starting at sector 63) with an existing Windows installation:
http://doc.opensuse.org/release-notes/x86_64/openSUSE/13.2/#idm140129443081152
And I also found the bug report now, which actually lead to that release notes entry:
https://bugzilla.opensuse.org/show_bug.cgi?id=900954
Comment#5:
There is a grub error, from the log:
Error: ‘/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe “/dev/disk/by-id/ata-Maxtor_6L200P0_L438QZXG”’ failed with exit code 1, output:
/usr/sbin/grub2-install: warning: your core.img is unusually large. It won’t fit in the embedding area.
/usr/sbin/grub2-install: error: filesystem `btrfs’ doesn’t support blocklists.
I suppose this is due tthe first partition starting at sector 63, so the space
between the MBR and the first partition is not large enough to the bootloader.
Why the bootloader is installed to the MBR if btrfs should be supported, I don’t know. That’s why I suspected a bug in perl-Bootloader or whereever.
But I saw now, that there’s actually a fix proposed and submitted to Factory already:
https://bugzilla.opensuse.org/show_bug.cgi?id=841247#c18
So I guess further discussion (here) is futile…
Because user selected it? Because this is default in YaST? Because btrfs partition is logical and not primary?
Unfortunately it is too late … we all know that media does not get updates.
Apparently Michael Chang’s fix has made its way to the public repos, if only among “unstable” packages, and to the 20141112 Tumbleweed snapshot.
I would like to give it a try over the weekend since I might still have a messy boot process.
Three questions:
Thanks,
Bruno
Why ext2 for /boot filesystem and not ext3/ext4?