Ok, I found the solution and can answer my own questions.
1) can I use LVM over RAID1 on a UEFI machine ?
Yes, definitely. And it will be able to boot even if one of the two disks fails.
2) How to do this ?
The're seem to be a bug in the installer, so just using the installer results in a failure to boot (grub shell).
Here is a working procedure:
1) manually create the following partitions on each of the two disks:
- a 512MB partition with type UEFI a the beginning of the disk
- a partition of type RAID after that
2) create your RAID 1 array with the two RAID partitions, then create your LVM volume group with that array, and your logical volumes (I created one for root, one for home and one for swap).
3) let the install go on, and reboot. FAILURE ! You should get a grub shell.
4) it might be possible to boot from the grub shell, but I choosed to boot from a rescue usb disk. In rescue mode, I opened a shell on my target root fs (that is the one on the root lvm logical volume).
5) get the UUID of this target root partition with 'blkid'. Note it down or take picture with your phone, you'll need it next step.
6) mount the EFI system partition ('mount /boot/efi') and edit the grub.cfg file: vi /boot/efi/EFI/ubuntu/grub.cfg
Here, replace the erroneous UUID with the one you got at point 5.
Save.
7) to be able to boot from the second disk, copy the EFI partition to this second disk:
dd if=/dev/sda1 of=/dev/sdb1 (change sda or sdb with whatever suits your configuration).
8) Reboot. In your UEFI setting screen, set the two EFI partitions as bootable, and set a boot order.
You're done. You can test, unplug one or the other of the disks, it should work !
Your problem is that the EFI boot process stores data on the boot loader's location in NVRAM, so when you install on one computer and then move the disk to another computer, the second computer doesn't know where to look to find the boot loader. The usual way around this problem is to use the default/fallback boot loader filename, EFI/BOOT/bootx64.efi, on the EFI System Partition (ESP; that's your FAT32 partition). The firmware looks for this filename on removable disks. The big caveat is that you may need to use the firmware's built-in boot manager to select that disk, and the details of how to access that boot manager vary from one computer to another.
You can copy the boot loader to that location manually. The way that's most likely to work, from a working Ubuntu installation, is:
cd /boot/efi/EFI
sudo mkdir -p BOOT
sudo cp ubuntu/shimx64.efi BOOT/bootx64.efi
sudo cp ubuntu/grubx64.efi BOOT/grubx64.efi
Note that these commands will overwrite any existing EFI/BOOT/bootx64.efi boot loader. You probably don't have one on your external disk right now, but you might want to double-check this. Also, this assumes that the ESP on the external disk is mounted at /boot/efi. You should definitely double-check that with df before you proceed. You don't want to overwrite the boot loader on your internal disk by accident!
If you're sure that you'll be booting with Secure Boot disabled, you could copy EFI/ubuntu/grubx64.efi to EFI/BOOT/bootx64.efi, but that won't work if the target computer has Secure Boot enabled.
Best Answer
Precisely what Ubuntu version are you trying to install? Please specify the exact filename of the .iso image that you downloaded. My first guess is that you've got a 32-bit (i386) version, which won't be bootable in EFI mode on a 64-bit computer -- at least not without additional tedious mucking about. It's also possible that you've downloaded a Mac version (amd64+mac), which likewise also lacks EFI support. Another possibility, for rEFInd at least, is that you've accidentally reconfigured the
scanforline inrefind.confto omit theopticaloption, which is required to "see" EFI-bootable optical discs. This last possibility seems rather remote, though; by default rEFInd does scan for EFI-bootable optical discs.I just checked, and in VirtualBox, at least, rEFInd has no problems detecting the EFI boot mode of an AMD64 Ubuntu 12.04 system (
ubuntu-12.04-desktop-amd64.iso).