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 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,
--
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
