Bug#803624: grub-common: btrfs-root-fs rootflags-kernelparameter problems

Christoph Anton Mitterer calestyo at scientia.net
Sun Nov 1 05:26:03 UTC 2015


Package: grub-common
Version: 2.02~beta2-29
Severity: wishlist


Hi.

There are two things about the rootflags parametr that 10_linux generates
automatically when the root fs is btrfs.


1) (And I haven't looked at this in depth):
The subvol, if any, seems to be intentionally made relative.
But does this take into account, that the subvol paths are relative to
the top level subvol (i.e. ID=5) and not to the current default subvol?
Cause if not, the relative path would probably break as soon as one changes
the default subvol.




2) I wanted to make one of my servers, which runs on a RAID1 btrfs more
resilient against disk losses; i.e. it should boot even though one of the
two disks failed.

a) When I set "degraded" as mount option in /etc/fstab, than this doesn't
have any effect.
The initramfs doesn't store (and use it) and grub doesn't consider it (i.e.
add it it to rootflags=) either in the generated grub.cfg.

But admittedly, I'm not really sure whether it should.


So perhaps a proper solution would be, if 10_linux takes up such mount-options
from /etc/fstab and appends them to rootflags=
Maybe even generally (and not just "degraded") as not all filesystems may
provide something like ext* where one can store the default mountoptions in the
fs superblock.
But then there should be an option (guess in /etc/default/grub) which disables
that auto-pickup for those people who may want to do more special things.


Cheers,
Chris.



More information about the Pkg-grub-devel mailing list