+++ This bug was initially created as a clone of Bug #1695911 +++ Description of problem: When attempting to install on existing raid devices, anaconda fails to recognize an existing EFI system partition as such. An EFI system partition should not need to be formatted. It should be possible to use --useexisting and install the Fedora EFI boot loader into the existing partition. This does not work. Neither from kickstart options, or from blivet-gui trying to set the device as the /boot/efi mount point without actually formatting the device. Version-Release number of selected component (if applicable): Fedora 30 Server Beta and also Fedora 29 Server How reproducible: 100% Steps to Reproduce: 1. Boot installer on efi system with existing hard drive efi partition 2. Add part entries for efi device in kickstart with --noformat 3. Start kickstart install in graphical mode 4. Graphical mode will eventually come up and show an error on drive selection 5. Go into drive pane and read the error listed, it will complain of no EFI partition even though one is required Alternatively 1. Boot on efi system in graphical install mode 2. Use blivet-gui for manual drive selection 3. Attempt to mount existing system EFI partition and /boot/efi and proceed with install 4. Anaconda will complain that efi requires an efi system partition mounted at /boot/efi Actual results: Unable to complete the install. Expected results: I expect the existing EFI system partition to be mounted as appropriate and the fedora shim EFI binaries to be installed as normal. Additional info:
Please, attach logs from the installation. You can find them in /tmp/*log.
Created attachment 1551967 [details] anaconda.log
Created attachment 1551968 [details] dbus.log
Created attachment 1551969 [details] program.log
Created attachment 1551983 [details] storage.log
Created attachment 1551984 [details] syslog
From what I could see in the logs, this is what looks like is happening to me: 1) Even though it's possible to create a raid1 EFI System Partition and anaconda will properly use a version 1.0 md raid superblock, when anaconda is scanning the system's devices, it does not recognize a raid1 array with version 1.0 superblock as a possible EFI system partition 2) Anaconda scans the md raid1 array and finds a vfat filesystem. It does not mark it as EFI system partition. In the specific circumstance that the filesystem is vfat, and the raid1 array has a version 0.90 or 1.0 superblock, and the partition type of the md raid partition is marked as EFI System Partition in the partition table instead of Linux RAID, then anaconda's block scan should tag the md device as the EFI system partition and treat it as such. Because anaconda does not recognize the EFI system partition for what it is, the only way to code this into a kickstart that won't hang the kickstart is to forcibly reformat the EFI parition on each install. This is problematic if you have a dual OS install or if you just happen to have some custom.cfg grub boot menu items on the EFI partition.
Thanks for the logs! It seems to be an issue in the storage configuration library. Reassigning to blivet.
upstream PR: https://github.com/storaged-project/blivet/pull/834 updates image: https://vtrefny.fedorapeople.org/img/rhbz1695913.img I was able to test this in a UEFI VM and I was able to reuse a preexisting /boot/efi without reformatting it and the system booted but it would be nice if someone could test this in some real-world scenario.
FEDORA-2020-cab532bdb5 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cab532bdb5
FEDORA-2020-cab532bdb5 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-cab532bdb5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cab532bdb5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-cab532bdb5 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.