Bug#780115: grub-installer: fails on multi-device btrfs, zfs
Package: grub-installer
Version: 1.112
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Hi,
A section of code in grub-installer (dating back to lilo-installer)
assumes that `grub-probe -t device` or 'findfs' returns only one device.
Otherwise it fails with:
Wrong number of args: mapdevfs <path>
That's coming from here:
http://anonscm.debian.org/cgit/d-i/grub-installer.git/tree/grub-installer?id=84d9a8936986f388feac192b785cc7ba98f9ce1d#n244
after rootfs, bootfs, bootfstype and rootfstype were all
properly set.
For a multi-disk mdraid or LVM, only one device path is returned, e.g.
/dev/md0, /dev/mapper/foo-bar
When modern filesystems btrfs and zfs are striped or mirrored across
multiple devices, then findfs returns a list of devices, one per line.
I'm not familiar if partman-btrfs allows to create multi-device sets.
The kfreebsd installer allows to create such a configuration. This can
happen using unofficial ZFS-on-Linux installer images too.
That's the bug this patch refers to:
https://lists.debian.org/debian-boot/2014/11/msg00181.html
and fixed differently with this earlier proposal:
http://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?h=zol&id=c96fd6c89445758fc6b5964d47c9d811bcb44238
It appears to have been reported and fixed in Ubuntu, differently again:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1354730
https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222
All three fixes look a bit of a hack to me, but picking any one device
works as a placeholder until this code reaches a conclusion that is
inevitable.
The purpose of this code is to find indications it should fall back to
grub-legacy. In the case of btrfs, zfs, and some other situations it is
mandatory to use grub2 anyway:
http://anonscm.debian.org/cgit/d-i/grub-installer.git/tree/grub-installer?id=84d9a8936986f388feac192b785cc7ba98f9ce1d#n374
I think if bootfstype was tested earlier, a lot of this legacy code
could be skipped over or 'optimised out'. Awkwardly though, variables
stay in scope until the end of this long script, and it's hard to see if
something gets (re-)used later. findfs gets used in some more places
and I'm not sure yet if it's satisfactory in *all* places to to consider
only the first one.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: