Am Montag, 2. Juni 2014, 19:39:22 schrieb Andrey Borzenkov:
> В Sat, 10 May 2014 20:53:34 +0200
>
> Martin Steigerwald <mar...@lichtvoll.de> пишет:
> > Package: grub2-common
> > Version: 2.02~beta2-10
> > Severity: normal
> >
> > 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.
>
> 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 :(
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,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
