Dear Maintainer,

I am booting my Debian system via a BTRFS RAID 1 which spans a logical
volume on a Crucial MSATA and Intel SATA SSD each.

After running update-grub I am getting this in /boot/grub/grub.cfg:

                echo    'Linux 3.15.0-rc5-tp520 wird geladen …'
                linux   /vmlinuz-3.15.0-rc5-tp520 root=/dev/mapper/sata-debian
        /dev/mapper/msata-debian ro rootflags=subvol=debian  init=/bin/systemd resume=/dev/mapper/sata-swap
                echo    'Initiale Ramdisk wird geladen …'
                initrd  /initrd.img-3.15.0-rc5-tp520

update-grub basically adds both devices of the BTRFS RAID 1 device
separated by a line feed. For mounting BTRFS RAID 1 tough one of them
is enough, once btrfs device scan is run, for which I currently use an
script for initramfs-tools as a work-around as it didn´t work out of
the box on my last tests[1].

This behaviour is due to grub-probe which is called by grub-mkconfig
at line 139

138 # Device containing our userland.  Typically used for root= parameter.
139 GRUB_DEVICE="`${grub_probe} --target=device /`"
140 GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null`" || true

which is called by update-grub returns both devices with a
linefeed:

merkaba:~> grub-probe --target=device /
/dev/mapper/sata-debian
/dev/mapper/msata-debian

grub-probe is an ELF binary.

The following little change workarounds the issue for me:

merkaba:~> diff -u /usr/sbin/grub-mkconfig.dist /usr/sbin/grub-mkconfig
--- /usr/sbin/grub-mkconfig.dist        2014-05-08 14:35:25.000000000 +0200
+++ /usr/sbin/grub-mkconfig     2014-05-10 20:46:00.380096263 +0200
@@ -136,7 +136,7 @@
 fi

 # Device containing our userland.  Typically used for root= parameter.
-GRUB_DEVICE="`${grub_probe} --target=device /`"
+GRUB_DEVICE="`${grub_probe} --target=device / | head -1`"
 GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null`" || true

 # Device containing our /boot partition.  Usually the same as GRUB_DEVICE.


But I suppose the real fix is to be made in the binary grub-probe.


[1] merkaba:~> cat /etc/initramfs-tools/scripts/local-top/btrfs
#!/bin/sh

PREREQ="lvm"
prereqs()
{
        echo $PREREQ
}

case $1 in
prereqs)
        prereqs
        exit 0;
esac

. /scripts/functions

log_begin_msg "Initializing BTRFS RAID-1."

modprobe btrfs
vgscan
vgchange -ay
btrfs device scan

log_end_msg

See also

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686130#15
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612402#66

Thanks,
Martin

В Sat, 10 May 2014 20:53:34 +0200
Martin Steigerwald <Martin@Lichtvoll.de> пишет:

No, grub-probe is correct; grub needs to know all devices so it can
have full information which drivers it requires to access them.

See also
https://lists.gnu.org/archive/html/grub-devel/2014-05/msg00005.html

I suggest you discuss it with Colin, but for now I tend to think, fix
should go into 10_linux. May be always use UUID for btrfs.

But this sounds like new can of worms :(

Am Montag, 2. Juni 2014, 19:39:22 schrieb Andrey Borzenkov:

Any oppinions here on how to take this forward?

I just applied my patch from above again after a GRUB update.

Colin?

Andrey, what new kind of worms have you in mind? :)

Ciao,

Am Montag, 2. Juni 2014, 19:39:22 schrieb Andrey Borzenkov:

Any way on how to proceed on this one?

I applied

merkaba:/usr/sbin> diff -u grub-mkconfig.dist grub-mkconfig
--- grub-mkconfig.dist  2014-05-08 14:35:25.000000000 +0200
+++ grub-mkconfig       2014-05-10 20:46:00.380096263 +0200
@@ -136,7 +136,7 @@
 fi

 # Device containing our userland.  Typically used for root= parameter.
-GRUB_DEVICE="`${grub_probe} --target=device /`"
+GRUB_DEVICE="`${grub_probe} --target=device / | head -1`"
 GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null`" || true

 # Device containing our /boot partition.  Usually the same as GRUB_DEVICE

for a dozen of times meanwhile.

It works for me. I understand that it may not work if the first drive is
not on LVM, while the second is, as I bet grub would not load LVM driver
then. Anyway I still boot of a small Ext4 /boot.

Well I dpkg-diverted the file for now, but this way I risk breakage on
upgrades as changes to the file are not automatically applied.

Maybe above can just to into 10_linux, *just* for the root= kernel command
line.

Or… it could additional devices on kernel command line in that BTRFS syntax, for
non initrd users, but that might break as well as between update-grub and
boot may be changes of device paths.

So either just supplying the first device on kernel command line or the UUID
sounds reasonable to me. Either way BTRFS will require a btrfs device scan
call in initrd, but unless you do add the devices manually on kernel command
line thats just how it is. This is discussed currently in… hmmm, I thought
there was a discussion on BTRFS mailing list, but I do not find it at the
moment.

Ciao,

В Sat, 06 Dec 2014 12:01:11 +0100
Martin Steigerwald <Martin@lichtvoll.de> пишет:

From: Andrei Borzenkov <arvidjaar@gmail.com>
Subject: [PATCH] fix linux kernel root= argument with multidev btrfs

Btrfs may reside on multiple devices, but only one of them should be
passed to root= kernel argument. Add two helper functions:

- get_root_device: select "best" device for the list. For single device
just return it to skip probing; for multiple devices try to find LVM as
before but fall back to the first device if not found.

- find_abstraction: return device with requested abstraction driver from
the given list.

Refactor code to use them and reimplement uses_abstraction on top of
find_abstraction.

Also replace check for LVM with uses_abstraction in 10_kfreebsd.
---
 util/grub-mkconfig_lib.in   | 50 ++++++++++++++++++++++++++++++++++-----------
 util/grub.d/10_kfreebsd.in  |  8 +++-----
 util/grub.d/10_linux.in     | 10 +++++----
 util/grub.d/20_linux_xen.in | 10 +++++----
 4 files changed, 53 insertions(+), 25 deletions(-)

diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
index 29ef865..ecae264 100644
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -283,21 +283,27 @@ gettext_printf () {
   printf "$(gettext "$gettext_printf_format")" "$@"
 }

Am Montag, 8. Dezember 2014, 23:09:24 schrieb Andrei Borzenkov:

This looks like it needs to be applied to grub sources instead a installed
grub.

[…]

Or I can use some version control branch?

I don´t see the branch on

http://git.savannah.gnu.org/cgit/grub.git/refs/heads

Where can I clone it?

And then I just build it and copy over the generated files from the files the
patch changed manually to my installed grub to test?

I have grub-pc 2.02~beta2-17 debian package installed.

Thanks,

В Tue, 09 Dec 2014 18:49:21 +0100
Martin Steigerwald <Martin@lichtvoll.de> пишет:

You are posting to grub-devel, right? :)

Just apply on top of master.

git clone git://git.savannah.gnu.org/grub.git
cd grub
git am e-mail-with-patch

I do not know what other patches Debian has, so using upstream directly
may lose Debian specific changes. Also you would need to build using
correct configure options.

I would suggest to build it for different prefix, like

./autogen.sh
./configure --prefix=/usr/local/grub-test
make
make install

then run /usr/local/grub-test/sbin/grub-mkconfig and examine generated
configuration.

I myself do not use Debian, sorry.