Bug 1168777

I've been investigating https://bugzilla.redhat.com/show_bug.cgi?id=1168118 all day. I think I nailed it down reasonably well. I just tested, and it can also be reproduced on RHEL 7 (well, I had a CentOS 7.0 image lying around so I used that, but same difference). I expect it's in 7.1 and 7.2 as well as it's never been fixed in Fedora.

The reproducer, as described in #1168118, is:

* Boot a UEFI system with two empty disks attached (Xda and Xdb)
* Select both disks and go to custom partitioning
* Create a layout of simple partitions with /boot and /boot/efi on Xdb, / and swap on Xda, all correct (sufficient size, /boot/efi as ESP filesystem)
* Try to complete custom partitioning

actually I think it doesn't matter where / and swap are, the only important thing is you have more than one disk selected, and /boot/efi is on a disk other than the first.

What's going on is that pyanaconda/kickstart.py Bootloader class execute() method always sets storage.bootloader.stage1_disk to the first disk (modulo a couple of checks we don't really need to worry about here), unless its bootDrive variable has been set to something, which AFAICS only happens by user interaction on the 'Full disk summary and bootloader' screen or from a kickstart. If the stage1 target mount point - /boot/efi, in the UEFI case - is on any other disk, everything falls apart because only the partitions on the first disk get considered as possible stage1 target devices, and none of them is one, so the installer believes there's no valid target.

I wondered if it at least works if you go into the "Full disk summary" page and set the appropriate disk as the 'boot disk' before going into custom partitioning, but it doesn't, because between doing that and going into custom partitioning, pyanaconda/ui/gui/spokes/storage.py's _doExecute() is run and decides the choice was invalid (because there's no /boot/efi partition yet, so no valid stage1 device) and resets bootDrive to "".

I posted a patch to #1168118 which seems to fix this for me, and doesn't seem to break various other UEFI and BIOS paths I tested (but this is complex and sensitive code and it's *entirely* possible I missed something or there's a better way to fix it - but it's a start, at least). I strongly suspect this affects omapARM as well, because it really affects anything that uses a mounted partition as a stage1 target.

I *suspect* there may be similar issues with biosboot (BIOS + GPT) and prepboot (PPC) as well, but I don't have PPC hardware and the 'gpt' parameter which should force a gpt-on-BIOS install doesn't seem to work, so I can't easily test those cases right now.