Re: Bug#747653: grub2-common: update-grub adds both devices and a line feed for BTRFS RAID 1 setup

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]

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 <Martin@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?
> 
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?
> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]