grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#747653: grub2-common: update-grub adds both devices and a line f


From: Andrey Borzenkov
Subject: Re: Bug#747653: grub2-common: update-grub adds both devices and a line feed for BTRFS RAID 1 setup
Date: Fri, 1 Aug 2014 20:54:26 +0400

В Fri, 01 Aug 2014 17:43:03 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:

> On 29.07.2014 15:12, Martin Steigerwald wrote:
> > Am Montag, 2. Juni 2014, 19:39:22 schrieb Andrey Borzenkov:
> >> В Sat, 10 May 2014 20:53:34 +0200
> >>
> >> Martin Steigerwald <address@hidden> пишет:
> >>> 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?
> > 
> While changing grub-probe isn't agood idea: it's GRUB internal tool, we
> could filter and leave only one device but I don't think it makes any
> sense as multidevice btrfs needs uuid uniqueness in any case. Why didn't
> UUID code path kick in?

Most likely due to

! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}"

Currently GRUB_(BOOT)_DEVICE is used as

a) argument for various property probing, where we must know all
individual devices for multi-device file systems
b) as fallback to pass to kernel

may be it makes sense to export both in grub-mkconfig, as

GRUB_KERNEL_DEVICE (which will simply use first in the list; any better
name?)
GRUB_DEVICES (same as GRUB_DEVICE now)

and audit all scripts for usage. Although I was a bit unsure in some
cases, especially for non-Linux.


> > I just applied my patch from above again after a GRUB update.
> > 
> > Colin?
> > 
> > Andrey, what new kind of worms have you in mind? :)
> > 
> > Ciao,
> > 
> 
> 

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]