When you assign /boot/efi to a correct partition on a secondary disk, there is an error message that says you haven't assigned a /boot/efi partition. Obviously this is incorrect and very confusing. There needs to be a separate error message for this situation that explains why it could be a problem and direct the user to the boot drive selection screen where they can select the correct boot drive.
Created attachment 1449203 [details] screenshot of error Beyond goofy error message, I can't even guess how this is translated into other languages because it makes zero sense in English and does not help the user resolve the problem. The chosen /boot/efi is definitely on a GPT formatted disk. It's definitely formatted FAT32. So every single complaint in this dialog is incorrect.
Description of problem: On UEFI, when choosing two disks for installation, an apparently bogus and unhelpful error message related to bootloader appears. Version-Release number of selected component (if applicable): anaconda 29.15-1.fc29 How reproducible: Always Steps to Reproduce: 1. Mimicking an actual setup in a VM: two drives vda = HDD, and vdb = SSD. SSD already has Windows, is GPT, has an ESP formatted FAT32, and some free space. vda is empty. 2. In the installer, choose both drives as destinations. 3. In custom partitioning, choose existing vdb2 (the ESP) mountpoint /boot/efi 4. Configure /boot and / and swap likewise on vdb. 5. Configure /home to take all the space on vda. 6. Done. Actual results: Error attached. Expected results: No error. The installer has all necessary information to perform this installation, the error message is completely bogus. Additional information: What's apparently going on, is the bootloader link at the bottom of the screen for choosing drives that should only be relevant for BIOS installations, is somehow being dragged along for UEFI installations. So that dialog is pinned to expecting vda for the bootloader, even though in custom partitioning the desired location has been chosen. Also, in this instance, automatic partitioning ends up creating a new ESP on the empty drive rather than reuse the existing ESP on vdb. By putting it on another drive, the Windows 10 boot selection menu found in shift+restart submenu won't show Fedora as a boot option.
Created attachment 1449231 [details] anacond.log
Created attachment 1449232 [details] program.log
Created attachment 1449233 [details] storage.log
It’s not really the error message that is the problem, though. UEFI doesn’t require that the ESP and boot partitions be on the same drive. The fault is in the assertions the test makes about what makes a valid UEFI boot system. The actual requirements and options: One or more ESP partitions must exist. Fedora’s ESP partition must be selected as the boot drive. (Why is this done on the screen prior to partitioning drives? Should be a checkbox in the partitioner.) You may have a /boot partition (or /) on another or the same drive regardless of whether there is one (or even multiple) ESP partitions on the same drive. Anaconda enforces this instead: /boot (or /) must be on the same drive as the ESP. This drive must have been set as the boot drive on the previous screen.
I've got the same massage about /boot/efi are not found on UEFI disk. In my case I've got a disk on sata and a disk on m.2 bus. After the error message, when I click on "2 storages devices selected" on the bottom left of the screen, I see that the disk selected to boot is the disk on sata. But previously I had explicitly selected the disk on m.2 to be the one to boot on. To fix the problem I need to confirm my partition configuration twice, come back on "Installation destination" and select again the disk on m.2 as the one to boot, confirm it, confirm my custom partition configuration and then it work without error. Yeah, it's not a really good user experience. When you just have 2 disks with 2 different speeds and just want to use one for system and one for personal data, the number of steep is not pleasant.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Proposed as a Blocker for 29-final by Fedora user chrismurphy using the blocker tracking app because: "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: Assign mount points to existing storage volumes," In certain dual drive installations, the user's assignment of an existing EFI System partition to /boot/efi mount point is ignored by the installer, and thus it presents the bogus "Failed to find a suitable device". The user did the exact correct thing in the GUI, but then the backend logic is failing to accept the assignment of the existing ESP.
Bug 1616446 is a likely duplicate (slight variation).
Isn't this just https://bugzilla.redhat.com/show_bug.cgi?id=1168118 but with slightly more error text for some reason? We've known about that for years, and it's sort of almost impossible to fix.
As that bug is long, you can cut straight to https://bugzilla.redhat.com/show_bug.cgi?id=1168118#c59 and comment #60.
Discussed during the 2018-10-08 blocker review meeting: [1] The decision to classify this bug as an RejectedBlocker was made: "This is really the same as an old bug, #1168118, which was never fixed. That bug was rejected as a blocker and we uphold that decision here (it is not very commonly encountered, can be worked around, and fixing it would be quite disruptive and come with a risk of breaking something worse). we will close the bug as a dupe of the old one" [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-10-08/f29-blocker-review.2018-10-08-16.00.log.txt
*** This bug has been marked as a duplicate of bug 1168118 ***
This isn't really a duplicate. This one isn't so much about fixing the issue, but that the error message is incorrect or at least misleading without the information on how to fix the problem.
Fair point, but it's probably not worth two bug reports.
This could have been an easy fix. It didn't have to wait for the other one. And it can still be done sooner if the other one is going to take a long time. I admit that it involves a rare situation and I haven't run into it myself.
It is in fact not that simple to fix just the message either, believe it or not, as in order to display an accurate message, we have to accurately identify the situation, and accurately identifying the situation involves going quite a long way towards *fixing* it. At least IIRC, it's been a couple of years since I did the legwork to poke through all the code. We could make the error text *vaguer* so it covers more possibilities, but making it more accurate is hard.