Boot failure with BIOS /bios_grub with multiple disks

Complex example - partitions are configured as seen on the attached screenshot.

After installation, system failed to boot and BIOS boot order needed to be edited.

Resulting "parted --ls" output:

Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
 1 1049kB 2097kB 1049kB ntfs
 2 2097kB 2150MB 2147MB
 3 2150MB 120GB 118GB

Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sdb: 240GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sdc: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
 1 1049kB 2097kB 1049kB bios_grub
 2 2097kB 2150MB 2147MB ext4
 3 2150MB 120GB 118GB

Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sdd: 240GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

Model: Linux Software RAID Array (md)
Disk /dev/md127: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
 1 0.00B 480GB 480GB ext4

Model: Linux Software RAID Array (md)
Disk /dev/md126: 118GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
 1 0.00B 118GB 118GB ext4

A less complex example, doing the same on Virtualbox with two virtual storages:

Here, two partitions were manually created on the first hard disk, which caused a third bios_grub partition ot tbe created on the same disk. bios_grub was automatically set up as the first partition. The second was /boot, an ext4 file system. The third partition was setup as a RAID device in an md RAID-1 array, together with an evenly sized partition on a second disk (where dummy partitions were created to match the first disk's bios_grub and /boot partitions in size and position).

The bios_grub partition was shown as setup on the first disk during installation. After installation,t he system would not boot. After changing the BIOS boot order so it would boot again, the attached parted --ls output was captured, indicating that both bios_grub and /boot had not been created on the first BIOS disk but on the second, causing boot to fail.

You can just swap sata slots in VirtualBox for your two storages, so os will be booted normally.

Thanks for suggesting a workaround, Andrew.

Did you also run into this then? If so, could you please change the status to 'confirmed'? Thanks.

Reproduced today on 18.04.2, with this configuration (within VirtualBox):

2 disks, both 10 GB or a size of your choice.

Start installer, do basic setup, select manual partitioning:
On the first disk, you select "make bootable", which effectively creates the first partition on it (see bottom), a 1 MB bios_grub one. Mirror this partition with an unused 1MB partition on the second disk.
Create a 2GB partition on both disks. On the first disk, this is ext4 file system /boot, on the second disk it is unused. I wanted to make this a RAID-1, but this installer cannot put /boot on a RAID.
Create a third partition on both disks covering the remaining allocatable space.
Make a RAID-1 out of the these third partitions on both disks. Create an ext4 file system mounted at / on top.
Continue installing, everything should succeed.
Until you reboot, where you are greeted with "FATAL: No bootable medium found! System halted."

Installer partitioning screenshots:

Basic setup - https://i.imgur.com/DJvWk1e.png

Partitioning complete - top: https://i.imgur.com/YOR5Js3.png
Partitioning complete - bottom: https://i.imgur.com/GcwJpw5.png

I think this stuff should be fixed now but am not completely sure...

For the symmetric setup that we tested it works as expected. I.e. two disks have the same layout:

partition 1: bios_grub
partition 2: raid1->/boot
partition 3: raid1->luks->/

While this matches the title, I think the original report only covers having one bios_grub.

Tentatively marking fix released. Please re-open if you disagree :)