Ubuntu installer crashed installing bootloader on btrfs+hw_raid5

[Damiön la Bagh]

Distributor ID: Ubuntu
Description: Ubuntu 12.04 LTS
Release: 12.04
Codename: precise
LiveUSB 64-bit

ubuntu@ubuntu:~$ apt-cache policy grub-installer
N: Unable to locate package grub-installer

Setup:
Hardware Raid controller 768000MB RAID5 over 4 disks mount point /home fstype btrfs
Single disk (outside the raid) 320000MB partition1 mount / fstype btrfs
            10000 partition0 mount /swap fstype linux-swap

Expected: grub-installer writes the booth loader to device /dev/sdc
ubuntu installs, and we can use the computer

What really happened:
during the install of Ubuntu when the grub-installer went to write out grub the installer crashed.

Will have to try again with a seperate /boot partition outside the btrfs file system to see if I can get it to start that way.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ubiquity 2.10.16
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Uname: Linux 3.2.0-23-generic x86_64
ApportVersion: 2.0.1-0ubuntu5
Architecture: amd64
CasperVersion: 1.315
Date: Tue Jul 10 18:57:52 2012
InstallCmdLine: noprompt cdrom-detect/try-usb=true file=/cdrom/preseed/ubuntu.seed boot=casper persistent initrd=/casper/initrd.lz splash -- BOOT_IMAGE=/casper/vmlinuz
LiveMediaBuild: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
 LANGUAGE=nl_NL.UTF-8
 TERM=unknown
 PATH=(custom, no user)
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
SourcePackage: grub-installer
UpgradeStatus: No upgrade log present (probably fresh install)

[Damiön la Bagh (kat-amsterdam)]

This bug can be marked as solved + suggested Improvement to the installer:

I forgot to create a small unformatted partition with the label bios_grub before installing.

As soon as I added a 64mb unformatted partition and used gparted to give it the label bios_grub everything worked fine. Installer worked and the machine booted.

It would be nice if you could add the bios_grub labeled unformatted partition to the beginning of the drive directly from the installer. (or even in the background have the installer do it automatically)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Damiön la Bagh (kat-amsterdam)]

btrfs is designed to replace the partition table, the partitions, the software raid controller and the filesystem.
There is no place to put a 64mb bios_grub partition as the disk becomes pure btrfs.

This is definitly not solved. When using a partition table-less btrfs install, which is the way btrfs is designed to be used, grub should be creating it's bootloader in /@/boot but instead the installer is crashing.

[Phillip Susi (psusi)]

You are mistaken Damiön. While you can install any filesystem, btrfs or otherwise, to a disk without a partition table, you need a partition table if you want to be able to boot from that disk because it is required by the pc bios. The OP here did have a partition table, but since it was gpt, he needed a bios_grub partition as he discovered, so I am closing this report per his request.

[Damiön la Bagh (kat-amsterdam)]

No, Phillip, you are not up to date in your filesystem technologies.

I have 5 machines running with btrfs on raw disks with no partions and no partition tables that boot Ubuntu just fine (some legacy bios and other UEFI). As designed by the btrfs team (borrowed from the ZFS filesystem methodology)

The trick is to install grub to /@/boot

using this command
mount /dev/sda /mnt
grub-install --boot-directory=/mnt/@/boot /dev/sda

If these two steps would be loaded into the Ubuntu Installer then there would be no problems installing and booting btrfs raw disks.

[Phillip Susi (psusi)]

You can do this with grub for bios systems since btrfs leaves 64k unused at the start of the disk for a boot loader ( though it does not require an @boot subvol ), but this is not possible for efi systems since efi requires a gpt partition table with an efi system partition containing valid efi files in a fat filesystem to boot.

Since there is no gain to this configuration, but several drawbacks, I do not believe it is one we will be switching to by default.

In any case, this has nothing to do with this bug report, which the original reporter asked to be closed.