Comment 3 for bug 1236625

I'm running into the same issue here, similiar circumstances it sounds like. I've been trying to work around what seems like an utterly broken install process (lack of mdadm, hang at trying to not activate ubuntu one), now stuck at trying to figure out what is broken about the grub install.

I'm using two redundant ssd's, mdraid, luks, and lvm in that order. I'm not sure how developers intend for a completed installation to work, but trial and error got me with what looks like this:

/dev/sda
-part1:efi (fat32)
-part2:md0 (boot0)
-part3:md1 (luks volume)
|__md0-/boot (ext2)
|__md1 - cryptsetup
 |-lv-root0 - / (ext4)
 |-lv-usr0 - /usr (ext4)
 |-lv-var0 - /var (ext4)
 |-lv-varlog0 - /var/log (ext4)
 |-lv-home0 - /home (ext4)

Rinse/repeat with /dev/sdb

It's a pain, I have to install gdisk and mdadm in the liveos, build the partitions, mdadm, cryptsetup, build pv/vg/lv's. format/mount the partitions under /target (this keeps the installer from demaning to format them stupid since I went through hassle to setup block-size, stride, and stripe-width), and *then* run the installer. At the partitioning, I simply set them to be ext4 and set the directory to boot, and choose the sda disk.

After installing, the only thing I catch is grub failing with "grub-install dummy". Looking at the df statistics, it's mounted all the partitions properly, including the efi under /boot/efi, but looks like the grub disk parsing is just broken how it's deriving the location.

This would be much easier it worked like Arch and just simply used the efi partition as /boot instead of /boot/efi.

Grub is setting at 2.00-19ubuntu2 once the installer is run, so should encompass this fix.

What exactly is ubuntu expecting since the desktop installer isn't flexible enough to do what I need it to?