Ubiquity calls mapdevfs with wrong number of args on btrfs raid1

[Barry Kolts]

Trying to install Saucy on a KVM vm. The filesystem is /vda1 mounted on /boot, vda2 and vdb1 ate btrfs raid1 swap is on vda. Installer always says it can't install bootloader on vda, pick another device. But no device works. I'v tried many time with different configurations of the virtual disks, always ends the same.

Thanks,
Barry

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: ubiquity 2.15.26
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
ApportVersion: 2.12.5-0ubuntu2
Architecture: amd64
CasperVersion: 1.336ubuntu1
Date: Wed Jan 1 19:19:46 2014
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity
LiveMediaBuild: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MarkForUpload: True
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
SourcePackage: grub-installer
UpgradeStatus: No upgrade log present (probably fresh install)

[Phillip Susi (psusi)]

Looks like a bug in ubiquity:

ubiquity: Wrong number of args: mapdevfs <path>

[Ubuntu Foundations Team Bug Bot (crichton)]

Exception during installation:
Jan 2 01:19:41 ubuntu /plugininstall.py: Traceback (most recent call last):
Jan 2 01:19:41 ubuntu /plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 1780, in <module>
Jan 2 01:19:41 ubuntu /plugininstall.py: install.run()
Jan 2 01:19:41 ubuntu /plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 78, in wrapper
Jan 2 01:19:41 ubuntu /plugininstall.py: func(self)
Jan 2 01:19:41 ubuntu /plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 242, in run
Jan 2 01:19:41 ubuntu /plugininstall.py: self.configure_bootloader()
Jan 2 01:19:41 ubuntu /plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 1049, in configure_bootloader
Jan 2 01:19:41 ubuntu /plugininstall.py: "GrubInstaller failed with code %d" % ret)
Jan 2 01:19:41 ubuntu /plugininstall.py: ubiquity.install_misc.InstallStepError: GrubInstaller failed with code 1
Jan 2 01:19:41 ubuntu /plugininstall.py:

[Barry Kolts (bhkolts)]

I've been trying to install grub2 manually but no luck. This is the first time I have tried to install grub2 manually so I'm no grub expert.

However I have changed my filesystem from btrfs to ext4 mounting / on one disk and /home on the other and it installs flawlessly. So it must have something to do with btrfs.

The installer does create a subvolume for / called @ and a subvolume for /home called @home. I think this is where I was having trouble with grub and possibly this is where the installer was having trouble.

Hope this helps,
Barry

[Barry Kolts (bhkolts)]

I found this on the Archwiki https://wiki.archlinux.org/index.php/Btrfs#GRUB

Missing root

Users experiencing the following: error no such device: root when booting from a RAID style setup then edit /usr/share/grub/grub-mkconfig_lib and remove both quotes from the line echo " search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}". Regenerate the config for grub and the system should boot without an error.

From the Saucy live-cd i used gparted to create the files system with /dev/vda1 btrfs and swap on /dev/vda and /dev/vdb1 btrfs o /dev/vdb. I set /dev/vda as the boot device. I then exited gparted and opened a terminal and ran

sudo mkfs.btrfs -L RAID1 -m raid1 -d raid1 /dev/vda1 /dev/vdb1
sudo btrfs device scan

I then exited the terminall and installed Saucy. When the partitioner starts chose "Something else". Mount / on /dev/vda1 but do not format or you will destroy the raid. When the installer complains it can't install the boot loader choose "Continue without installing boot loader".

When the installer is through, click on "Continue to try" rather than restart. Open up a terminal and

sudo mount /dev/vda1 /mnt
sudo gedit

When gedit launches navigate to/usr/share/grub and open grub-mkconfig_lb and remove the quotes from

echo " search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"

save the file and exit gedit. Now back in the terminal type

sudo grub-install --root-directory=/mnt/@ /dev/vda

/mnt/@ because the Saucy installer mount / on subvolume @ and mounts /home on subvolume @home.

When that is done you should be able to reboot into the system.

I'm using /dev/vda instaed of /dev/sda because I installed this on a KVM virtual machine. Also this is my first experience with btrfs and installing Grub from scratch and post my experience as maybe helpful in fixing Ubiquity.

Barry

[Huygens (huygens-25)]

"My bug" is related to that one, so I am adding the information as comment rather than creating a new one. However, if you think it is "enough different" let me know and I will create a separate bug.

I wanted to install Ubuntu Server on a system with 3 disks using Btrfs in RAID5. My first attempt was with Ubuntu 12.04.4 LTS but the btrfs tools shipped with it do not support RAID5. So I decided to go with Ubuntu Trusty Thar Alpha 2 (build from the 2014-02-08) and try my luck with it. This release of Ubuntu Server supports Btrfs in RAID5 although the installer does not. So during the "partitionning" phase I switched to another terminal to create the Btrfs filesystem in RAID5.
All was set-up correctly and the rest of the installation process was successfully done (in the log and as far as I can tell on the FS itself, all required files and configuration have been created). The problem is that the step to install Grub failed miserably with the same error as reported initially in this bug report.

I can provide some insight why this fails. Lines 295-314 from grub-installer (not grub-install, but the one used during installation). This script tries to find the root and boot mount point and the filesystem type of /boot. The problem of the functions findfs and findfstype in the case of RAID (in redundant mode, so RAID1,5,6,10 at least for Btrfs) is that they will find on all my 3 devices (sda, sdb and sdc) a /boot partition! So when a few lines later the script calls mapdevfs and use the $rootfs and $bootfs parameters, instead of showing /dev/sda2 (in my case) it has /dev/sda2 /dev/sdb2 /dev/sdc3, and obviously mapdevfs complains to support the 3 devices given as parameters.

When debuging the script grub-installer (using the "set +x" option), I have found out that the following command returns:
# chroot /target grub-probe -t device /boot
/dev/sda2
/dev/sdb2
/dev/sdc2

Which is then not foreseen for the rest of the scripts. I wrote an ugly patch which works for me, I changed the lines 295-296 to
rootfs=$(findfs / | head -n1)
bootfs=$(findfs /boot | head -n1)

I then ran the following command:
grub-installer /target/ /dev/sda

So given the current script, it is not possible to install Ubuntu with a /boot partition using Btrfs configured with a redundant "RAID"disk (aka as of today RAID1,5,6,10).
Note: this was only tested with RAID5, but obviously the other RAID configuration will be affected the same.

Note: However, the script was too complex to be read in a text console to be able to correct it so that I could install on each HDD grub. Because now only /dev/sda has grub, but if it fails my system is unable to boot in degraded mode because I do not have a bootloader on sdb or sdc. I was thinking that grub-installer second parameter was the destination device. But when trying to patch the rootfs and bootfs to get sdb2, and use sdb instead of sda for grub-installer, I saw in the log that it still installed Grub in sda :-(

[Huygens (huygens-25)]

Actually my "patch" did not work :-( I got in rescue mode while rebooting...

I think I will create dedicated "/boot" partition on top of MD instead of using Btrfs. This is quite disappointing! I wanted Btrfs because of its checksum+RAID combination. I will have to rely on plain "old" MD+ext4...

[dododge (dododge)]

I ran into the same problem trying to use a raid1 btrfs for "/" in the 14.04 Xubuntu installer. Just like above, I tracked it down to grub-installer, patched it almost the exact same way, and then after the installation finished it wouldn't boot.

Somewhere else in the installer it uses a grub-probe device scan to populate the kernel options in the grub configuration, and again the installer assumes that grub-probe only ever returns one device. When I went into the grub menu and viewed the entry, I found that it had listed both of my btrfs devices on the kernel command line, separated by a line break (which is just how grub-probe outputs them):

      linux /vmlinuz-3.13.0-20-generic.efi.signed root=/dev/mapper/vg-root1
  /dev/mapper/vg-root2 ro rootflags=subvol=@ quiet splash $vt_handoff

After editing that to remove the extra device it did get farther into the boot.

In my case it still failed: I'm trying to use logical volumes for the btrfs devices which are allocated from a volume group built from encrypted partitions. The resulting initramfs neverf asked for the encryption passphrase(s), so it still couldn't find the root device and dropped me into an initramfs shell. For a more normal setup with just plain btrfs partitions, editing the kernel line in the grub menu might be enough to get it to boot.

[Huygens (huygens-25)]

As I stated in my previous comment, I went for the solution to have /boot on a MD+ext4 RAID (which has the following, non-blocking but annoying, bug #1274320).

I am half happy with this solution, but at least most of my files are now under Btrfs.