Bug 1168118 - Custom UEFI layout with /boot/efi on second disk fails: is_valid_stage1_device not called on disks after the first
Custom UEFI layout with /boot/efi on second disk fails: is_valid_stage1_devic...
Status: NEW
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
28
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
: 1384627 (view as bug list)
Depends On:
Blocks: F25FinalFreezeException
  Show dependency treegraph
 
Reported: 2014-11-26 03:03 EST by Sumit Rai
Modified: 2018-07-23 07:13 EDT (History)
36 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1010495
: 1488204 (view as bug list)
Environment:
Last Closed: 2018-05-29 07:50:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Anaconda Log file. (132.10 KB, text/plain)
2014-11-26 03:03 EST, Sumit Rai
no flags Details
Anacond program.log. (84.21 KB, text/plain)
2014-11-26 03:06 EST, Sumit Rai
no flags Details
Anacond storage.log. (1.40 MB, text/plain)
2014-11-26 03:10 EST, Sumit Rai
no flags Details
Anaconda ifcfg.log. (13.39 KB, text/plain)
2014-11-26 03:11 EST, Sumit Rai
no flags Details
dmesg (176.00 KB, text/plain)
2014-11-26 03:11 EST, Sumit Rai
no flags Details
parted logs. (1.47 KB, text/plain)
2014-11-26 03:15 EST, Sumit Rai
no flags Details
Reproduced without boot,esp flag (206.97 KB, application/x-gzip)
2014-11-26 13:14 EST, Sumit Rai
no flags Details
anaconda.log from my reproduction with Final TC4 (30.11 KB, text/plain)
2014-11-26 21:51 EST, Adam Williamson
no flags Details
storage.log from my reproduction with Final TC4 (242.63 KB, text/plain)
2014-11-26 21:52 EST, Adam Williamson
no flags Details
TC4 With Patch 1168118 (135.29 KB, application/x-gzip)
2014-11-28 06:03 EST, Sumit Rai
no flags Details
TC4 without Patch (45.24 KB, application/x-gzip)
2014-11-28 06:04 EST, Sumit Rai
no flags Details
Anaconda GUI Manual Partitioning screen (106.30 KB, image/png)
2014-11-28 19:15 EST, Sumit Rai
no flags Details
All anaconda logs + dmesg (76.75 KB, application/x-gzip)
2014-11-28 19:24 EST, Sumit Rai
no flags Details
Anaconda logs for updates-1168118-tc2.img (78.13 KB, application/x-gzip)
2014-11-28 20:07 EST, Sumit Rai
no flags Details

  None (edit)
Description Sumit Rai 2014-11-26 03:03:03 EST
Created attachment 961525 [details]
Anaconda Log file.

This problem has occured again in Fedora 21 beta so I am cloning this bug.

Steps Taken:
1. Boot From Fedora 21 Beta Live CD.
2. Select the disks and select custom partitioning.
3. Create a /boot partition of size 500MiB. (/dev/mmcblk0p2).
4. Create a /boot/efi partition of size 200MiB with file system set to
Linux HFS+ ESP. (/dev/mmcblk0p1).
4. Create a / mount point from LVM of size 10000MiB.
5. Click Done. Below Error is observed despite creating a /boot/efi partition of type Linux HFS+ ESP.

"No valid bootloader target device found. See below for details.
For a UEFI installation, you must include an EFI System Partition on a GPT-formatted disk, mounted at /boot/efi."

+++ This bug was initially created as a clone of Bug #1010495 +++

Description of problem: On Apple hardware with either an existing FAT32 EFI System partition, or an existing Fedora HFS+ EFI System partition, installer fails with an error message "you have not created a bootloader stage1 target device."


Version-Release number of selected component (if applicable):
anaconda 20.18-1

How reproducible:
Always if there is either a FAT32 or HFS+ EFI System partition present prior to install.

Steps to Reproduce:
1. Computer contains either a default OS X installation, or a default Fedora 18 or 19 installation.
2. Attempt to install using guided partitioning, default partition scheme LVM. (Problem also occurs with other schemes, and also occurs with autopartitioning selected within Manual Partitioning UI.)


Actual results:
Installer fails. Error message in storage configuration is "you have not created a bootloader stage1 target device"

Expected results:
Installer should use an existing HFS+ EFI System partition, otherwise create an HFS+ EFI System partition (for use with mactel-boot).

Additional info:

--- Additional comment from Chris Murphy on 2013-09-20 17:34:51 EDT ---



--- Additional comment from Chris Murphy on 2013-09-20 17:39:45 EDT ---

Proposing as beta blocker: When using the guided partitioning flow, the installer must be able to cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation, and complete an installation using any combination of disk configuration options it allows the user to select.

--- Additional comment from Chris Murphy on 2013-09-20 17:41:26 EDT ---



--- Additional comment from Chris Murphy on 2013-09-20 17:42:02 EDT ---



--- Additional comment from Chris Murphy on 2013-09-20 17:42:14 EDT ---



--- Additional comment from bcl@redhat.com on 2013-09-20 18:27:29 EDT ---

Chris, why did you close the previous bug?

As it stands, this will not be fixed in F20.

The solution involves setting a new GUID on the HFS+ ESP that Anaconda creates so that we can differentiate between it and the Apple HFS+ root partition. I have code for the parted part of this in rawhide, but given the level of change it would involve I don't want to change things for F20 at this point. I haven't done any work on the Anaconda/blivet part of things yet.

--- Additional comment from Chris Murphy on 2013-09-20 19:21:32 EDT ---

I closed it as a dupe of this one a.) because the one for 19 obviously isn't ever going to be fixed, and b.) I wasn't sure about the effect of flipping it from 19 to 20 with the whiteboard filled in.

What GUID are you proposing? It seems doubtful either the firmware or Startup disk is going to display a volume for a partition type GUID it doesn't recognize. And if it's going to be the GUID for Apple Boot, then how is this differentiated from the existing Apple Boot already on every Mac?

--- Additional comment from bcl@redhat.com on 2013-09-20 20:20:32 EDT ---

On the Mac side things already work, mactel-boot sets up the HFS+ ESP to look like a fake boot volume so that the icons show up. This is what you get when you start from scratch.

The problem is when we do another install Anaconda has no way to tell if the HFS+ volume is the Apple disk or the one it created. So I made up a new partition type GUID (47CB5633-7E3E-408B-B7B8-2D915B7B21B1) so that we can test for it. You can experiment with the parted side of things using  the version from rawhide and setting the hfs_esp flag on a partition.

--- Additional comment from Chris Murphy on 2013-09-20 20:39:28 EDT ---

On a working Fedora 19 install, I installed parted-3.1-16.fc21.x86_64.rpm, and used parted to set the hfs_esp flag on the Fedora ESP, and rebooted. The system is no longer booting by default. When I reboot using the option key, Fedora is not a listed option. When I reboot OS X, in the Startup disk panel, Fedora is not an option. 

When I use gdisk to restore the Fedora ESP to a partition type GUID of 48465300-0000-11AA-AA11-00306543ECAC (AF00 in gdisk), the Fedora system is once again bootable by default, visible with the option key boot manager, and the OS X startup disk panel.

So the proposal doesn't seem like it's going to work, despite a test sample size of one, there's every reason to believe other Apple EFI firmwares behave the same way and will only show volume with partition type codes of:

426F6F74-0000-11AA-AA11-00306543ECAC
48465300-0000-11AA-AA11-00306543ECAC
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Although that last one, for all I know, will cause the firmware to assume it's Windows and thus subject to booting via the CSM.

--- Additional comment from Chris Murphy on 2013-09-20 20:50:33 EDT ---

The Fedora HFS+ ESP is consumed by the firmware if the type code is either:
426F6F74-0000-11AA-AA11-00306543ECAC
48465300-0000-11AA-AA11-00306543ECAC

Meaning if it's set to either of those, Fedora boots. If it's set to anything else, it doesn't, including EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. But it's a momentary brain lapse on my part forgetting this is expected. The firmware trigger for CSM booting is finding code in the MBR bootstrap region, and a hybrid MBR (2 or more entries), with any partition other than 1 with the active flag set. Not a partition type GUID.

The test machine is a MacbookPro 4,1 circa 2008.

--- Additional comment from Chris Murphy on 2013-09-20 21:04:59 EDT ---

Another test machine, MacBookPro8,2 circa 2011, also with working Fedora 19, is broken upon using parted-3.1-16.fc21 to set the hfs_esp flag on the Fedora ESP. Bootablity is restored by resorting the former partition type GUID.

--- Additional comment from bcl@redhat.com on 2013-09-23 13:02:09 EDT ---

Crap. Thanks for testing. That's going to make it hard to detect previous installs then. We could write something to our EFS that we can check for, but that means we have to mount them first instead of just checking GUID.

--- Additional comment from Chris Murphy on 2013-09-23 13:19:21 EDT ---

Yes, and to look for likely suspects you could discount >20GB partitions from being mounted and parsed, because those are unlikely to be what you're looking for, most likely to be an installed OS X system or user data volume.

I'm fundamentally opposed, even in Manual Partitioning, to the idea of users being responsible for creating required partitions like BIOSBoot and the ESP. I think the installer should just do that, and use a fixed size that would further allow you to use that as a check for likely, rather than unlikely, suspects. It would also eliminate hundreds of these really unhelpful "you have not created" error messages.

--- Additional comment from bcl@redhat.com on 2013-09-23 13:25:38 EDT ---

Another idea is to just set a label on it. Something like 'Fedora ESP'

--- Additional comment from Chris Murphy on 2013-09-23 13:26:20 EDT ---

Another thing you can do is set the partition name field in the GPT, and use that as an early search method. If still present (user hasn't renamed it), the search is faster. If nothing is found, then more searching is required, up to possibly mounting HFS+ file systems and searching for a key of some sort (e.g. a text file with hfs_esp GUID in it). So in order, something like this:

1. Search by partition type GUID + partition name.
2. Search by partition type GUID + fixed size.
3. Search by partition type GUID + size range (less than 20G).

When a search method gets a hit, mount that. If the mount is forced RO, which happens if it's a journaled HFS+ file system, then you know it's not what you're looking for, since you're creating non-journaled HFS+ for the ESP as journaled HFS+ is still not supported on linux for RW.

--- Additional comment from Chris Murphy on 2013-09-23 13:30:27 EDT ---

(In reply to Brian C. Lane from comment #14)
Yes but technically the partition name is user domain, so it's fair for it to be changed by the user, meaning you still need a search fallback if it's not found.

You could use the Apple Boot partition type GUID:
426F6F74-0000-11AA-AA11-00306543ECAC. 

Rather than the general HFS+/HFSJ/HFSX partitino type GUID:
48465300-0000-11AA-AA11-00306543ECAC

The occurrence of Apple Boot partition type GUID will be less common than the general partition type, and in a sense it's more appropriate anyway. If that seems reasonable let me know and I'll explore possible negative side effects of using it.

--- Additional comment from Mike Ruckman on 2013-09-25 12:50:42 EDT ---

Discussed in 2013-09-25 Blocker Review Meeting [1]. There's a question as to whether this affects only systems with two existing ESPs, or any system with an existing EFI OS installation. We will establish this and re-visit the bug next time.

[1]

--- Additional comment from Mike Ruckman on 2013-09-25 12:51:38 EDT ---

Here is the link for [1] in the ^^^ comment: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-25/

--- Additional comment from Chris Murphy on 2013-09-25 14:27:17 EDT ---

(In reply to Mike Ruckman from comment #17)
It always occurs using Guided Partitioning regardless of whether there are 0, 1 or 2 or more ESPs. The only way to use Guided Partitioning on Macs is:
a.) There is no partition scheme on the disk, or
b.) All existing partitions are deleted either individually one at a time, or using Delete All button, or clicking on the disk device and clicking Delete (in reclaim space partition listing).

If the existing GPT is preserved with 1+ partitions, this bug is triggered.

--- Additional comment from Chris Murphy on 2013-09-25 15:27:22 EDT ---

FWIW, this is an autopartitioning bug which occurs pretty much always in the Guided path, but is avoidable in the Manual partitioning path if the user does NOT click on the blue link to automatically create Fedora partitions.

The gotcha is that there's no assistance for the user to create the required /boot/efi mount point. If they don't do that, they likewise get the unhelpful message that's the summary of this bug. (See bug 1012132)

--- Additional comment from Chris Murphy on 2013-09-25 19:21:34 EDT ---

OK I think I know what's going on that explains all of the failure cases: On Macs, anaconda's check for existing ESPs is triggered by two partition type codes, the legit FAT32 ESP:
C12A7328-F81F-11D2-BA4B-00A0C93EC93B
And the faux HFS+ ESP:
48465300-0000-11AA-AA11-00306543ECAC

On a clean OS X only system, both are present. On a Fedora only system, the 2nd one is present. And even if I delete both the Fedora and OS X ESPs, but leave OS X there, it still fails because OS X's partition type GUID is likewise 48465300-0000-11AA-AA11-00306543ECAC.

<adamw> there's a significant difference between 'affects re-install over an >existing fedora install, can be worked around by deleting the old fedora ESP' and >'affects any attempt to auto-partition alongside an existing EFI OS'

The latter does fail.

<bcl> If it blocks installing to a clean system I'm +1

If clean means a GPT partition layout of: ESP, OS X, OS X Boot, 400GB free space, yes it fails to install to that. Let me know if you want logs.

--- Additional comment from bcl@redhat.com on 2013-09-27 18:22:23 EDT ---

Here's a fairly simple patch. It:
 * makes sure it is a hfs+ partition and meets other criteria for stage1 on Mac
 * Is smaller than 501.0MB
 * Is NOT labeled "OSX"

http://bcl.fedorapeople.org/updates/1010495.img

For me it works fine with both a clean install (shrunk OSX partition) and re-install where you reclaim space by deleting the previous install's partitions.

--- Additional comment from Chris Murphy on 2013-09-28 13:22:15 EDT ---

Thanks for the patch. Works for me.

--- Additional comment from Mike Ruckman on 2013-10-02 15:43:41 EDT ---

Discussed this in the 2013-10-02 Blocker Review Meeting [1]. This has been voted an AcceptedBlocker. This volates the following F20 beta release criterion for EFI system partitions on apple hardware: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation" [2].


[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/
[2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning

--- Additional comment from Luke Macken on 2013-10-02 16:12:21 EDT ---

After hitting this bug, I tested Brian's updates img from Comment #22 with Fedora 19 live installation on a Macbook, and it worked great.

--- Additional comment from Mike Ruckman on 2013-10-09 17:19:19 EDT ---

Discussed this in 2013-10-09 Blocker Review Meeting [1]. Waiting on more information. Will revisit next meeting.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-09/

--- Additional comment from Adam Williamson (Red Hat) on 2013-10-10 10:21:29 EDT ---

For the record - bcl informs me that the patch in its current form isn't complete and needs more refinement, so that's why this one isn't in POST or progressed further. He does have it on his todo list to improve and submit the patch.

--- Additional comment from Petr Schindler on 2013-10-24 09:41:39 EDT ---

I wasn't able to reproduce this bug with Beta TC5.

I had Mac with OsX. I shrinked main partition by gparted. Then I run anaconda and chose to use all available space (default with LVM).

Installation went well. Everything runs as it should.

Only one thing is wrong. During installation is created new system EFI HFS+ partition.

--- Additional comment from Chris Murphy on 2013-10-24 13:48:02 EDT ---

(In reply to Petr Schindler from comment #28)
>I shrinked main partition by gparted.
The ability to resize OS X volumes outside of OS X is unexpected.

> Only one thing is wrong. During installation is created new system EFI HFS+
> partition.

That's normal for Macs.

--- Additional comment from bcl@redhat.com on 2013-10-24 14:11:34 EDT ---

That is likely related to bug 1021258, it stopped reusing existing UEFI partitions on non-mac as well.

With that patch this should start to fail again.

--- Additional comment from Jaroslav Reznik on 2013-10-29 07:17:22 EDT ---

Petr, Chris - could you retry it with anaconda-20.25.4-1 as referenced in Brian's comment?

--- Additional comment from Petr Schindler on 2013-10-29 10:44:29 EDT ---

Confirmed. It fails now again :)

--- Additional comment from Chris Murphy on 2013-10-29 12:21:55 EDT ---

Mixed results with Desktop betaTC6 which has 20.25.4-1.

1. Bug is alive for Guided partitioning, reclaim space, delete prior Fedora partitions retaining the three OS X partitions: FAT32-ESP, HFSJ-OS X, HFSJ-RecoveryHD. I get "failed to find a suitable stage1 device" which is a different message than as originally reported.

2. Bug is NOT alive for custom partitioning when removing the same OS X partitions, then clicking the blue link "create them for me automatically". /boot/efi is created for me without error in this spoke, or upon returning to the hub.

--- Additional comment from bcl@redhat.com on 2013-10-29 19:46:20 EDT ---

Ok, give this a try (against TC6)

http://bcl.fedorapeople.org/updates/1010495.img

It uses a hfs+ partition with a name of 'Linux HFS+ ESP' so it will not detect current installs unless you add this name to your current Fedora ESP.

--- Additional comment from Chris Murphy on 2013-10-29 20:25:03 EDT ---

c34 updates image fixes c33 item 1, no regression on item 2. I did not click Begin Installation, I'm not ready to blow away this system just yet. But in all previous cases the bug has occurred by now.

I'll give it full install testing with the next TC or RC.

--- Additional comment from bcl@redhat.com on 2013-10-30 13:03:58 EDT ---

(note that fix also requires python-blivet-0.23.3-1)

--- Additional comment from Fedora Update System on 2013-10-30 20:38:52 EDT ---

python-blivet-0.23.3-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-blivet-0.23.3-1.fc20

--- Additional comment from Fedora Update System on 2013-10-31 13:39:00 EDT ---

Package python-blivet-0.23.3-1.fc20, anaconda-20.25.5-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-blivet-0.23.3-1.fc20 anaconda-20.25.5-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20387/anaconda-20.25.5-1.fc20,python-blivet-0.23.3-1.fc20
then log in and leave karma (feedback).

--- Additional comment from Chris Murphy on 2013-10-31 21:20:14 EDT ---

This bug is fricaceed. 

Tested with anaconda-20.25.5.boot.iso, using guided and custom installs to free space, along side OS X to completion. Install & reboot to prompt/shell successful.

Also tested installer behavior, without committing using "Begin Installation", install to:

"empty" 2nd HFSJ partition, along side OS X.
existing Fedora install, along side OS X.

Tested with and without preserving "macefi" in both paths.

No errors.

--- Additional comment from Kamil Páral on 2013-11-04 06:49:50 EST ---

(In reply to Chris Murphy from comment #39)
> This bug is fricaceed. 

What?

I tested with F20 Beta RC2. I shrunk Apple's partition and installed using guided part into the free space. The installation went fine, but Anaconda ignored Mac's ESP and created its own.

# parted -l
Model: ATA TOSHIBA MK5065GS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name                  Flags
 1      20.5kB  210MB  210MB   fat32        EFI system partition  boot
 2      210MB   452GB  451GB   hfs+         Customer
 4      452GB   452GB  210MB   hfs+         Linux HFS+ ESP
 5      452GB   452GB  524MB   ext4
 6      452GB   499GB  47.2GB                                     lvm
 3      499GB   500GB  650MB   hfs+         Recovery HD

sda[1-3] were available prior to installation, sda[4-6] were created by anaconda.

Is this considered "fixed"?

--- Additional comment from Chris Murphy on 2013-11-04 11:10:01 EST ---

>(In reply to Kamil Páral from comment #40)
>The installation went fine, but Anacondaignored Mac's ESP and created its own.
>  4      452GB   452GB  210MB   hfs+         Linux HFS+ ESP
> Is this considered "fixed"?

Yes.

--- Additional comment from Fedora Update System on 2013-11-07 00:03:49 EST ---

python-blivet-0.23.3-1.fc20, anaconda-20.25.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from Pedro Saraiva on 2014-11-08 16:24:30 EST ---

Hello,

I've tried install Fedora 21 Beta on my macbook but i'm getting this bug about the efi partition.

This is my partition table:

#diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *240.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage                         179.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                 Linux Swap                         511.7 MB   disk0s4
   5: 0FC63DAF-8483-4772-8E79-3D69D8477DE4               59.5 GB    disk0s5
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                 Apple_HFSX Mac                    *178.8 GB   disk1
                                 Logical Volume on disk0s2
                                 7C79EC16-0578-4A80-B09E-81D564C1AB14
                                 Unencrypted

On disk0s5 i've installed opensuse with efi using disk0s1 as efi boot.
But on fedora 21 installer it says that i've not specified a efi boot partition even if I tell it to mount disk0s1 as /boot/efi.

--- Additional comment from Adam Williamson (Red Hat) on 2014-11-08 17:30:48 EST ---

Can you please attach /tmp/program.log and /tmp/storage.log ? Thanks.

--- Additional comment from Pedro Saraiva on 2014-11-09 04:36:29 EST ---



--- Additional comment from Pedro Saraiva on 2014-11-09 04:38:57 EST ---

On anaconda.log there's this insteresting messages:

09:26:05,727 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda5) returning False
09:26:05,727 ERR anaconda: storage configuration failed: failed to find a suitable stage1 device
09:26:05,729 ERR anaconda: No valid bootloader target device found. See below for details.
09:26:05,730 ERR anaconda: For a UEFI installation, you must include an EFI System Partition on a GPT-formatted disk, mounted at /boot/efi.

--- Additional comment from Roman Dubtsov on 2014-11-09 11:52:03 EST ---

I ran into the same issue on my macbook air. Should I open a new bug since this one is closed?

--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:03:32 EST ---



--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:03:56 EST ---



--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:04:16 EST ---



--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:06:07 EST ---

09:25:23,016 DEBUG anaconda: _is_valid_format(sda1) returning False
09:25:23,016 DEBUG anaconda: is_valid_stage1_device(sda1) returning False
09:25:23,016 DEBUG anaconda: device.format.name is 'EFI System Partition'

--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:08:56 EST ---

class MacEFI(EFI):
    _boot_stage1_format_types = ["macefi"]
    _boot_efi_description = N_("Apple EFI Boot Partition")

--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:23:24 EST ---

MacEFIGRUB class modifies is_valid_stage1_device() thus:

    def is_valid_stage1_device(self, device, early=False):
        valid = super(MacEFIGRUB, self).is_valid_stage1_device(device, early)

        # Make sure we don't pick the OSX root partition
        if valid and getattr(device.format, "name", "") != "Linux HFS+ ESP":
            valid = False

        if hasattr(device.format, "name"):
            log.debug("device.format.name is '%s'", device.format.name)

looks like that's what we're hitting. It expects the ESP's device.format.name to be "Linux HFS+ ESP", in your case it's "EFI System Partition".

Per #c34 that may not be considered a bug exactly, but I'll leave it up to bcl to decide. If that's the case we may want to look at improving the error message (which I wrote, I know :>) for the Mac case.

--- Additional comment from Adam Williamson (Red Hat) on 2014-11-09 12:25:15 EST ---

Does it work if you create a new ESP as part of your Fedora layout? Does it work if you use automatic / 'guided' configuration? (You can 'delete' some existing partition or something to test the non-custom partitioning, it won't actually do it until you click Begin Install or whatever it's called on the hub, so it's safe as long as you don't do that).

--- Additional comment from Pedro Saraiva on 2014-11-09 13:42:08 EST ---

Yes it works if I create a new layout or use the automatic configuration.
Just don't understand why we can't use that EFI partition since it's a simple FAT32 with ESP flag partition.

--- Additional comment from Chris Murphy on 2014-11-09 18:53:27 EST ---

In order to see Fedora as a boot option in OS X's Startup disk panel, and the firmware option+bootchime boot manager menu, Fedora's bootloader (GRUB) needs to be on an HFS+ volume, which Apple's firmware can read directly unlike non-Apple UEFI systems. This is part of mactel-boot.

So the required "Linux HFS+ ESP" is what this error message is referring to. You need to create a standard partition, ~100-200MB in size, and set the type to Linux HFS+ ESP. That's where GRUB will go, and the installer will stop complaining.

This is why I filed bug 1022316. Users can't be expected to know this things, it's user hostile to require them to manually create mandatory partitions, even in manual partitioning. FAT ESP, HFS+ ESP, and BIOSBoot, should all be automatically created expressly because of all the confusion we continue to get around these things.

--- Additional comment from bcl@redhat.com on 2014-11-10 13:37:37 EST ---

(In reply to Pedro Saraiva from comment #43)
> Hello,
> 
> I've tried install Fedora 21 Beta on my macbook but i'm getting this bug
> about the efi partition.

Trying to triple boot a Mac is a situation we really don't support. Does it work if you create /boot/efi/ and set the type to 'Linux HFS+ ESP'?



(In reply to Chris Murphy from comment #56)
> This is why I filed bug 1022316. Users can't be expected to know this
> things, it's user hostile to require them to manually create mandatory
> partitions, even in manual partitioning. FAT ESP, HFS+ ESP, and BIOSBoot,
> should all be automatically created expressly because of all the confusion
> we continue to get around these things.

Chris, please stop referring to things as 'user hostile'. Custom is custom, you're expected to know what you are doing. Autopart should do the right thing, if it has the space. If it doesn't let's file a bug about that.



(In reply to Roman Dubtsov from comment #47)
> I ran into the same issue on my macbook air. Should I open a new bug since
> this one is closed?

If you aren't triple booting and you are using autopart or custom + correct /boot/efi/ type then yes. With individually attached logs.

--- Additional comment from Benito Mourelo on 2014-11-10 15:16:54 EST ---

(In reply to Pedro Saraiva from comment #55)
> Yes it works if I create a new layout or use the automatic configuration.
> Just don't understand why we can't use that EFI partition since it's a
> simple FAT32 with ESP flag partition.

Yes, you could as Ubuntu can do it with two or one OS. As reference https://help.ubuntu.com/community/MacBookPro11-1/Saucy.
The Fedora method is better in my opinion.

--- Additional comment from Adam Williamson (Red Hat) on 2014-11-11 02:19:47 EST ---

bcl: I'll see if I can come up with something to post a better error message for the Mac case (have to re-familiarize myself with the way the errors there work).
Comment 1 Sumit Rai 2014-11-26 03:06:08 EST
Created attachment 961526 [details]
Anacond program.log.
Comment 2 Sumit Rai 2014-11-26 03:10:02 EST
Created attachment 961529 [details]
Anacond storage.log.
Comment 3 Sumit Rai 2014-11-26 03:11:01 EST
Created attachment 961530 [details]
Anaconda ifcfg.log.
Comment 4 Sumit Rai 2014-11-26 03:11:26 EST
Created attachment 961531 [details]
dmesg
Comment 5 Sumit Rai 2014-11-26 03:15:33 EST
Created attachment 961532 [details]
parted logs.
Comment 6 Sumit Rai 2014-11-26 04:37:38 EST
The issue doesn't occur if you select just one disk instead of two. In my intance when I just selected the /dev/mmcblk0 as the disk with custom partitioning instead of /dev/mmcblk0 and /dev/sda.

It's very clear from the below logs that the anaconda don't query the
Linux EFI partition /dev/mmcblk0p1 for stage1 device as it should.
It just queries partitions of disk sda for stage1 device.

23:51:54,174 DEBUG anaconda: new disk order: []
23:52:19,707 DEBUG anaconda: stage1 device cannot be of type lvmvg
23:52:19,707 DEBUG anaconda: device.format.name is 'Unknown'
23:52:19,707 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora_20) returning False
23:52:19,708 DEBUG anaconda: stage1 device cannot be of type lvmlv
23:52:19,708 DEBUG anaconda: device.format.name is 'ext4'
23:52:19,708 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora_20-root) returning False
23:52:19,708 DEBUG anaconda: stage1 device cannot be of type disk
23:52:19,709 DEBUG anaconda: device.format.name is 'partition table (GPT)'
23:52:19,709 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda) returning False
23:52:19,710 DEBUG anaconda: _is_valid_disklabel(sda1) returning True
23:52:19,711 DEBUG anaconda: _is_valid_size(sda1) returning True
23:52:19,711 DEBUG anaconda: _is_valid_location(sda1) returning True
23:52:19,712 DEBUG anaconda: _is_valid_format(sda1) returning False
23:52:19,712 DEBUG anaconda: is_valid_stage1_device(sda1) returning False
23:52:19,712 DEBUG anaconda: device.format.name is 'EFI System Partition'
23:52:19,712 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda1) returning False
23:52:19,713 DEBUG anaconda: _is_valid_disklabel(sda2) returning True
23:52:19,714 DEBUG anaconda: _is_valid_size(sda2) returning True
23:52:19,714 DEBUG anaconda: _is_valid_location(sda2) returning True
23:52:19,714 WARN anaconda: sda2 not bootable
23:52:19,715 DEBUG anaconda: _is_valid_format(sda2) returning False
23:52:19,715 DEBUG anaconda: is_valid_stage1_device(sda2) returning False
23:52:19,715 DEBUG anaconda: device.format.name is 'hfs+'
23:52:19,715 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda2) returning False
23:52:19,716 DEBUG anaconda: _is_valid_disklabel(sda3) returning True
23:52:19,717 DEBUG anaconda: _is_valid_size(sda3) returning True
23:52:19,717 DEBUG anaconda: _is_valid_location(sda3) returning True
23:52:19,717 WARN anaconda: sda3 not bootable
23:52:19,718 DEBUG anaconda: _is_valid_format(sda3) returning False
23:52:19,718 DEBUG anaconda: is_valid_stage1_device(sda3) returning False
23:52:19,718 DEBUG anaconda: device.format.name is 'hfs+'
23:52:19,718 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda3) returning False
23:52:19,719 DEBUG anaconda: _is_valid_disklabel(sda4) returning True
23:52:19,720 DEBUG anaconda: _is_valid_size(sda4) returning True
23:52:19,720 DEBUG anaconda: _is_valid_location(sda4) returning True
23:52:19,720 WARN anaconda: sda4 not bootable
23:52:19,721 DEBUG anaconda: _is_valid_format(sda4) returning False
23:52:19,721 DEBUG anaconda: is_valid_stage1_device(sda4) returning False
23:52:19,721 DEBUG anaconda: device.format.name is 'hfs+'
23:52:19,721 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda4) returning False
23:52:19,722 DEBUG anaconda: _is_valid_disklabel(sda5) returning True
23:52:19,723 DEBUG anaconda: _is_valid_size(sda5) returning True
23:52:19,723 DEBUG anaconda: _is_valid_location(sda5) returning True
23:52:19,723 WARN anaconda: sda5 not bootable
23:52:19,723 DEBUG anaconda: _is_valid_format(sda5) returning False
23:52:19,724 DEBUG anaconda: is_valid_stage1_device(sda5) returning False
23:52:19,724 DEBUG anaconda: device.format.name is 'hfs+'
23:52:19,724 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda5) returning False
23:52:19,725 DEBUG anaconda: _is_valid_disklabel(sda6) returning True
23:52:19,725 DEBUG anaconda: _is_valid_size(sda6) returning True
23:52:19,725 DEBUG anaconda: _is_valid_location(sda6) returning True
23:52:19,726 WARN anaconda: sda6 not bootable
23:52:19,726 DEBUG anaconda: _is_valid_format(sda6) returning False
23:52:19,726 DEBUG anaconda: is_valid_stage1_device(sda6) returning False
23:52:19,726 DEBUG anaconda: device.format.name is 'physical volume (LVM)'
23:52:19,726 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda6) returning False
23:52:19,727 DEBUG anaconda: _is_valid_disklabel(sda7) returning True
23:52:19,728 DEBUG anaconda: _is_valid_size(sda7) returning True
23:52:19,728 DEBUG anaconda: _is_valid_location(sda7) returning True
23:52:19,728 WARN anaconda: sda7 not bootable
23:52:19,728 DEBUG anaconda: _is_valid_format(sda7) returning False
23:52:19,728 DEBUG anaconda: is_valid_stage1_device(sda7) returning False
23:52:19,729 DEBUG anaconda: device.format.name is 'physical volume (LVM)'
23:52:19,729 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda7) returning False
23:52:19,729 ERR anaconda: BootLoader setup failed: failed to find a suitable stage1 device
23:52:19,735 INFO anaconda: Thread Done: AnaExecuteStorageThread (140213584131840)
Comment 7 Kamil Páral 2014-11-26 08:35:56 EST
Fixing blocker fields - moving to proposed.

PS Sumit Rai: This bug would be easier to read if you simply created a new one and referenced to the old one, rather than cloning all existing comments. An idea for next time. Thanks.
Comment 8 Sumit Rai 2014-11-26 12:35:47 EST
> PS Sumit Rai: This bug would be easier to read if you simply created a new
> one and referenced to the old one, rather than cloning all existing
> comments. An idea for next time. Thanks.
You are right, I will take this into account while reporting bugs in future. Thanks.
Comment 9 Chris Murphy 2014-11-26 12:41:55 EST
"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration."

I'm not following this as described. The parted output shows both devices are fully partitioned, and I'm not seeing in the report that any existing partition has been deleted first. So how was /boot/efi added if there's not enough space?

The existing ESP's on the two devices cannot be used. Both of them have parted 'boot,esp' flags which is incorrect on Macs, even though the one on the sdcard is HFS+ it still won't work because the partitiontypeGUID is set to EFI System partition. Seems like a step removing existing partitions is missing?
Comment 10 Sumit Rai 2014-11-26 12:54:11 EST
(In reply to Chris Murphy from comment #9)
> "The installer must be able to create and install to any workable partition
> layout using any file system and/or container format combination offered in
> a default installer configuration."
> 
> I'm not following this as described. The parted output shows both devices
> are fully partitioned, and I'm not seeing in the report that any existing
> partition has been deleted first. So how was /boot/efi added if there's not
> enough space?

Partition /dev/mmcblk0 was marked for refromatting with Linux HFS+ ESP fs_type and /boot/efi as mount. I don't understand the rational behind deleting existing partitions and not reusing them.
Most OS installer I have used allows you to use existing partions after reformatting.

> 
> The existing ESP's on the two devices cannot be used. Both of them have
> parted 'boot,esp' flags which is incorrect on Macs, even though the one on
> the sdcard is HFS+ it still won't work because the partitiontypeGUID is set
> to EFI System partition. Seems like a step removing existing partitions is
> missing?

I was receiving this error even before the boot,esp flag was present on /dev/mmclkb0p1.

Trying to guess a workaround I marked /dev/mmcblk0p1 as boot,esp. But it didn't work.
Comment 11 Sumit Rai 2014-11-26 13:12:55 EST
Chris Murphy: I have reproduced this bug to answer your concerns.

Steps
1. Boot from live cd.
2. /dev/sda has one Mac OS X EFI partition. /dev/mmcblk0 has no partitions.
3. I selected custom partion, and created three partitions.
   a.) Root LV of size 10000MiB.
   b.) /boot of size 500MiB on /dev/mmcblk0p2.
   c.) /boot/efi of 200MiB on /dev/mmcblk0p1. FS Type set to Linux HFS+ ESP as required.
4. Click done and I get the error:-
No valid bootloader target device found. See below for details.
For a UEFI installation, you must include an EFI System Partition on a GPT-formatted disk, mounted at /boot/efi.
You have not specified a swap partition.  Although not strictly required in all cases, it will significantly improve performance for most installations.

Please find attachment titled 'Reproduced without boot,esp flag' with file
'anaconds_bug_reproduced.tar.gz' containing all the logs.

Thanks.
Comment 12 Sumit Rai 2014-11-26 13:14:04 EST
Created attachment 961749 [details]
Reproduced without boot,esp flag
Comment 13 Sumit Rai 2014-11-26 13:16:51 EST
Comment on attachment 961749 [details]
Reproduced without boot,esp flag

To answer Chris Murphy's concerns about boot,esp flag set on existing partition.
I have reproduced the bug w/o boot,esp flag set on more than one partition, and not existing partitions on /dev/mmcblk0. Marking old logs as obsolete.
Comment 14 Sumit Rai 2014-11-26 13:27:08 EST
Again, If I select only one disk instead of two the bug is not reprocuded.

Case 1. Two disks /dev/sda and /dev/mmcblk0 are used.
 MacEFIGRUB.is_valid_stage1_device() is never called on /dev/mmcblk0p1 which is stage1 device.

Case 1. Only one disk /dev/mmcblkp0 is used.
 MacEFIGRUB.is_valid_stage1_device() is called on /dev/mmcblk0p1 at some point and returns True. But even in this case Logical Volume 'fedora-root' and 'fedora-swap' are quried first.

I suggest you pick up the block device marked as /boot/efi in Anaconda GUI and call  MacEFIGRUB.is_valid_stage1_device() on that device to begin with.

It correctly finds /dev/mmcblk0p1 as stage 1 device.
12:29:12,262 DEBUG anaconda: updated device_container_raid_level to None
12:29:12,262 DEBUG anaconda: updated device_container_encrypted to False
12:29:12,262 DEBUG anaconda: updated device_container_size to 0
12:29:12,269 DEBUG anaconda: populate_raid: 2, None
12:29:14,921 DEBUG anaconda: new disk order: []
12:29:14,975 DEBUG anaconda: stage1 device cannot be of type lvmvg
12:29:14,975 DEBUG anaconda: device.format.name is 'Unknown'
12:29:14,975 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora) returning False
12:29:14,976 DEBUG anaconda: stage1 device cannot be of type lvmlv
12:29:14,976 DEBUG anaconda: device.format.name is 'ext4'
12:29:14,976 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora-root) returning False
12:29:14,977 DEBUG anaconda: stage1 device cannot be of type lvmlv
12:29:14,977 DEBUG anaconda: device.format.name is 'swap'
12:29:14,977 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora-swap) returning False
12:29:14,978 DEBUG anaconda: stage1 device cannot be of type disk
12:29:14,978 DEBUG anaconda: device.format.name is 'partition table (GPT)'
12:29:14,978 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(mmcblk0) returning False
12:29:14,979 DEBUG anaconda: _is_valid_disklabel(mmcblk0p1) returning True
12:29:14,980 DEBUG anaconda: _is_valid_size(mmcblk0p1) returning True
12:29:14,980 DEBUG anaconda: _is_valid_location(mmcblk0p1) returning True
12:29:14,981 WARN anaconda: mmcblk0p1 not bootable
12:29:14,981 DEBUG anaconda: _is_valid_format(mmcblk0p1) returning True
12:29:14,981 DEBUG anaconda: is_valid_stage1_device(mmcblk0p1) returning True
12:29:14,981 DEBUG anaconda: device.format.name is 'Linux HFS+ ESP'
12:29:14,981 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(mmcblk0p1) returning True
12:29:14,986 DEBUG anaconda: _is_valid_disklabel(mmcblk0p1) returning True
12:29:14,986 DEBUG anaconda: _is_valid_size(mmcblk0p1) returning True
12:29:14,987 DEBUG anaconda: _is_valid_location(mmcblk0p1) returning True
12:29:14,987 WARN anaconda: mmcblk0p1 not bootable
12:29:14,987 DEBUG anaconda: _is_valid_format(mmcblk0p1) returning True
12:29:14,987 DEBUG anaconda: is_valid_stage1_device(mmcblk0p1) returning True
12:29:14,987 DEBUG anaconda: device.format.name is 'Linux HFS+ ESP'
12:29:14,987 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(mmcblk0p1) returning True
12:29:14,988 DEBUG anaconda: _is_valid_disklabel(mmcblk0p2) returning True
12:29:14,988 DEBUG anaconda: _is_valid_size(mmcblk0p2) returning True
12:29:14,989 DEBUG anaconda: _is_valid_location(mmcblk0p2) returning True
12:29:14,989 DEBUG anaconda: _is_valid_partition(mmcblk0p2) returning True
12:29:14,989 DEBUG anaconda: _is_valid_format(mmcblk0p2) returning True
:
Comment 15 Scott Suehle 2014-11-26 14:50:25 EST
Discussed in 2014-11-26 Blocker Review Meeting [1]. Voted as a Punt. More information is needed to decide on this bug. Please retest this attempted to use the guided install.
 
[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-26/
Comment 16 Scott Suehle 2014-11-26 14:52:59 EST
Discussed in 2014-11-26 Blocker Review Meeting [1]. Voted as a RejectedBlocker. This bug doesn't violate any specific criteria due to sdcards not being a supported storage type. Supported storage types are SATA, PATA and SCSI for locally connected storage. We can revisit this for F22.
 
[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-26/
Comment 17 Chris Murphy 2014-11-26 16:19:23 EST
(In reply to Scott Suehle from comment #16)
I agree with the result in this case, but the rationale is a catch-22. For ARM we need to have either mmc/sdcard or USB supported because those boards only offer those connections - so that needs updating.

But on Macs, I've found mmc/sdcard is unreliable for booting due to, I think, proprietary firmware issues. I can install Fedora on mmcblk0 on my Mac, but booting from it fails even though I can boot OS X from that same sdcard. Everytime proprietary firmware isn't available I usually, but not always, get spurious errors preventing mmc/sdcard functionality. These errors never happen when the firmware is available. This is the same firmware required for wifi functionality, btw.

This bug is probably legitimate, but it's reasonable that it needs to be reproduced on supported storage types. Clearly the problem isn't using mmcblk0, because installation proceeds when only mmcblk0 is used; the bug is only triggered when there are two devices selected for installation.
Comment 18 Adam Williamson 2014-11-26 18:39:24 EST
I think I was intending, with the wording "Locally connected storage interfaces include PATA, SATA and SCSI.", to suggest that those weren't the *only* locally connected storage interface, just examples (of the most common ones). I agree with cmurf that it'd be a mistake to say only those interfaces can block.

I also agree with rejecting this as a blocker, though, because it seems to require just too many unusual conditions: installing to *both* a hard disk *and* an SD card, on a Mac. That's a bit of a lottery-winner situation, too rare to block on. (Why do it at all?)
Comment 19 Sumit Rai 2014-11-26 18:55:32 EST
(In reply to Chris Murphy from comment #17)
> (In reply to Scott Suehle from comment #16)
 
> But on Macs, I've found mmc/sdcard is unreliable for booting due to, I
> think, proprietary firmware issues.

Yes, from my experience mmc/sdcard on Mac does seem to have some issues.
e.g. https://bugzilla.kernel.org/show_bug.cgi?id=79301

>I can install Fedora on mmcblk0 on my
> Mac, but booting from it fails even though I can boot OS X from that same
> sdcard. Everytime proprietary firmware isn't available I usually, but not
> always, get spurious errors preventing mmc/sdcard functionality. These
> errors never happen when the firmware is available. This is the same
> firmware required for wifi functionality, btw.

However these problems have not prevented me from Booting Fedora Linux directly from mmc on my Mac. I used to boot an earlier version of Fedora from mmc all the time w/o any problems. In fact, flexibility to install Linux on USB/mmc is one of the things I find very useful about Linux, so do a lot of other Linux users in my opinion.

After installing Fedora 21 beta on mmc (via use only one disk workaround), I tried booting from mmc w/o any problems untill I hit the bug 
https://bugzilla.redhat.com/show_bug.cgi?id=1040669
In this case behaviour of mmc is not very different from internal ssd which also failed to boot Fedora 20 due to this LVM modules missing from initrd.

> This bug is probably legitimate, but it's reasonable that it needs to be
> reproduced on supported storage types. Clearly the problem isn't using
> mmcblk0, because installation proceeds when only mmcblk0 is used; the bug is
> only triggered when there are two devices selected for installation.

I do agree that the problem isn't mmcblk0. It's resonable from user prospective to expect that anaconda search the device configurated as /boot/efi for stage1 lable before initiating scan of all the supported devices and at least let it install the OS.

However, If you think it's reasonable to reproduce it on supported storage types. I wil try to reproduce it and get back to you soon.

Also, after looking at logs of 2014-11-26 Blocker Review Meeting I have a question.
>16:33:13 <sgallagh> Is this Guided or is it custom?

Could you please explain what you mean by Guided? By guided are you refering to
automatically configure partition option.
Current anaconda installer only gives two options when it comes to partitioning.
1. Automatically configure partitioning.
2. I will configure partitioning. (custom).

Option 1. Automatically configure cannot be considered guided since it by default uses free space to automatically create partitions w/o any inputs from user.
Comment 20 Sumit Rai 2014-11-26 19:02:01 EST
(In reply to Adam Williamson (Red Hat) from comment #18)
> I think I was intending, with the wording "Locally connected storage
> interfaces include PATA, SATA and SCSI.", to suggest that those weren't the
> *only* locally connected storage interface, just examples (of the most
> common ones). I agree with cmurf that it'd be a mistake to say only those
> interfaces can block.
> 
> I also agree with rejecting this as a blocker, though, because it seems to
> require just too many unusual conditions: installing to *both* a hard disk
> *and* an SD card, on a Mac. That's a bit of a lottery-winner situation, too
> rare to block on. (Why do it at all?)

I am trying to have my Fedora Linux Boot (stage1 and stage2) partition on Memory Card, and have my root partition on internal ssd so that I don't have to resize/repartition internal ssd and risk losing data.

How is this any different from situation where you want to install Linux with boot partition on primary master disk1, and root partition on secondary slave disk2?
Comment 21 Adam Williamson 2014-11-26 19:07:02 EST
"Option 1. Automatically configure cannot be considered guided since it by default uses free space to automatically create partitions w/o any inputs from user."

Guided is what we call it. It does require user input when sufficient unpartitioned space is not available.
Comment 22 Adam Williamson 2014-11-26 19:18:19 EST
"How is this any different from situation where you want to install Linux with boot partition on primary master disk1, and root partition on secondary slave disk2?"

Dunno, but I just tried that, and it works - I did an install in a UEFI VM (not a Mac) with /boot , /boot/efi and swap on one (VirtIO) disk and / on a second (VirtIO) disk, and the installer was fine with that, and the installed system boots.
Comment 23 Sumit Rai 2014-11-26 20:28:45 EST
(In reply to Adam Williamson (Red Hat) from comment #22)
> Dunno, but I just tried that, and it works - I did an install in a UEFI VM
> (not a Mac) with /boot , /boot/efi and swap on one (VirtIO) disk and / on a
> second (VirtIO) disk, and the installer was fine with that, and the
> installed system boots.

I tried it on non-Mac UEFI system with two disks sda and sdb and custom partitioning.

1. When /boot/efi partition is on disk sda. It let's you proceed with installation.
2. When /boot/efi partition is on disk sdb it fails with stage1 boot device not found error as sdb partitions are never queried using is_valid_stage1_device(dev) function. Again, I would expect anaconda to pick up 'dev' argument to is_valid_stage1_device() from
device corresponding to /boot/efi mount point specified in anaconda GUI rather than
defaulting to sda.

I do agree that it's very unlikely scenario and should not be a blocker. However, I would really appreciate it if it can be fixed in future.

Thanks.
Comment 24 Adam Williamson 2014-11-26 20:58:04 EST
I think you're misunderstanding that the is_valid_stage1_device() check is not somehow specific to UEFI, it's a much more generic check than that, so your recommended fix really just wouldn't work, because that's really just...not the way around that code works (AIUI anyway). But it's clearly a bug if the disk/partition which is expected to be the 'stage1' device is not always considered as a candidate, yes. I'll see if I can reproduce your result.
Comment 25 Adam Williamson 2014-11-26 21:07:05 EST
yeah, I can reproduce it with the ESP on the *second* disk of a two-disk system. Interesting, let me dig in.
Comment 26 Adam Williamson 2014-11-26 21:46:18 EST
Still looking into this, but for now, here's my reproducer:

* 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

It'll hit the error condition, as Sumit says. No valid stage1 device. I'll attach logs shortly. Logs have a 'crash' at the end which was just me triggering one so I could see if I could do any debugging from pdb, but of course it doesn't have the relevant environment...d'oh.
Comment 27 Adam Williamson 2014-11-26 21:51:19 EST
Created attachment 961841 [details]
anaconda.log from my reproduction with Final TC4
Comment 28 Adam Williamson 2014-11-26 21:52:36 EST
Created attachment 961842 [details]
storage.log from my reproduction with Final TC4
Comment 29 Adam Williamson 2014-11-27 14:56:19 EST
I'm still working on this one as it worries me a bit; so far I've worked out that we're failing when custom.py runs _do_check(). We hit the exception here:

        # set up bootloader and check the configuration
        try:
            self.storage.setUpBootLoader()
        except BootLoaderError as e:
            log.error("storage configuration failed: %s", e)

What happens there is blivet/blivet/__init__.py's setUpBootLoader() calls self.ksdata.bootloader.execute(), which is the execute() method in anaconda/pyanaconda/kickstart.py's Bootloader() class. By throwing some debug logs into *that*, I've determined that when it's run, self.bootDrive is not set, which causes it to just use the first disk as the bootDrive. I think that's the problem, I'd expect that *something* should have set bootDrive at that point. I'm now trying to figure out why that's not happening.

I also tested and found that this works in Fedora 20; it got broken somewhere between 20 and 21. That should help us narrow down the cause.
Comment 30 Adam Williamson 2014-11-27 15:02:26 EST
Ah, correction: it's broken in F20 as well, you just don't see the error until you get back to the hub in F20's design.
Comment 31 Adam Williamson 2014-11-27 15:31:30 EST
You can't work around this by going into the disk summary and picking Xdb as the boot drive before you enter custom partitioning, because that doesn't work. Somehow when you enter custom partitioning, gui/spokes/storage.py's _doExecute() is run, fails when it does try: doKickstartStorage() , and resets the bootDrive to "".

(As a side note, picking Xdb as the boot drive from the summary page and then using guided partitioning *does* work, by the looks of things - it looks like it would put /boot/efi on Xdb - but that's not really relevant here, just thought I'd test it.)
Comment 32 Adam Williamson 2014-11-27 17:48:42 EST
So, I have a change that fixes this, I think. AFAICS bootDrive has never really been set except by user interaction, so I decided trying to make that get set during partitioning was the wrong way to go, and instead I made the execute() method of the Bootloader() class smarter. Here it is:

=====================

diff --git a/pyanaconda/kickstart.py b/pyanaconda/kickstart.py
index 9c96d59..9dd6e44 100644
--- a/pyanaconda/kickstart.py
+++ b/pyanaconda/kickstart.py
@@ -379,9 +379,19 @@ class Bootloader(commands.bootloader.F21_Bootloader):
         if self.timeout is not None:
             storage.bootloader.timeout = self.timeout
 
+        disks = storage.disks
+        if platform.bootStage1ConstraintDict["mountpoints"]:
+            # reduce the set of possible 'boot disks' to the disks containing
+            # a valid stage1 mount point, if there are any
+            disks = [p.disk for p in storage.devices if getattr(p.format, "mountpoint", None) in platform.bootStage1ConstraintDict["mountpoints"]]
+            if not disks:
+                # but if not, just go ahead and use the set of all disks or
+                # else we'll error out later
+                disks = storage.disks
+
         # Throw out drives specified that don't exist or cannot be used (iSCSI
         # device on an s390 machine)
-        disk_names = [d.name for d in storage.disks
+        disk_names = [d.name for d in disks
                       if not d.format.hidden and not d.protected and
                       (not blivet.arch.isS390() or not isinstance(d, blivet.devices.iScsiDiskDevice))]
         diskSet = set(disk_names)

======================

there's probably a more elegant way to do the first bit (maybe sort disk_names with disks that have a stage1 mount point on them first?), but it gets the job done. If this is a platform where the stage1 device is a mounted partition, and there's at least one valid stage1 mount point configured, we use the set of disks that has valid stage1 mount points on it as the set of candidates for bootDrive.

If not, we just go back to using the full set of disks - if there's no valid mount point we'll never actually manage to set a valid stage1 device, but we still need execute() to run without crashing because it gets run when we first enter the custom part screen, and probably on other paths too. It might be cleaner to make execute() indicate inevitable failure somehow in this case, instead of returning a bootDrive for us to run some pointless is_valid_stage1_device() checks on, but I wanted to change existing behaviour as little as possible for now.

Really this whole behaviour is a bit bizarre for the UEFI case as there's no such thing as the 'boot disk' in that case, it's all a bit artificial.
Comment 33 Adam Williamson 2014-11-27 17:49:52 EST
Sumit: can you please test with https://www.happyassassin.net/updates/updates-1168118.img ? Boot a Final TC4 install image with this parameter:

inst.updates=https://www.happyassassin.net/updates/updates-1168118.img

and see if it works. Thanks!
Comment 34 Adam Williamson 2014-11-27 18:11:37 EST
I'm re-proposing this as at least a freeze exception issue. You can argue it's a blocker under Final "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration.", but we found it a bit late and we appear to have shipped F20 with this bug and it hasn't ended the world. But it *is* pretty bad.
Comment 35 Sumit Rai 2014-11-28 06:01:32 EST
(In reply to Adam Williamson (Red Hat) from comment #33)
> Sumit: can you please test with
> https://www.happyassassin.net/updates/updates-1168118.img ? Boot a Final TC4
> install image with this parameter:
> 
> inst.updates=https://www.happyassassin.net/updates/updates-1168118.img
> 
> and see if it works. Thanks!

I tried to reproduce it on non-Mac UEFI system by booting the Fedora-Live-Workstation-x86_64-21-TC4.iso with the parameter you mentioned. Your patch seems to fix the issue. Thanks.

Title: TC4 With Patch 1168118
Log File: anaconda_TC4.tar.gz 

For the sake of being through before reporting back to you, I tried to reproduce this bug on Fedora-Live-Workstation-x86_64-21-TC4.iso
WITHOUT your patch. I was able to successfully reproduce it.
But, I was able to workaround the issue, it's interesting to note that the same workaround didn't work for you on RHEL 7, but it works on Fedora 21 TC4.

From Bug 1168777:

"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,..."

I went back to "Full disk summary" page and set the disk sdb as boot disk before going back into custom, and it seems to find the stage1 device now.

Title: TC without Patch
Log: anaconda_TC4_workaround.tar.gz

I will try to reproduce it on my original Mac + mmc setup soon with your patch as well as the workaround and get back to you.
Comment 36 Sumit Rai 2014-11-28 06:03:17 EST
Created attachment 962428 [details]
TC4 With Patch 1168118
Comment 37 Sumit Rai 2014-11-28 06:04:04 EST
Created attachment 962430 [details]
TC4 without Patch
Comment 38 Vratislav Podzimek 2014-11-28 07:03:10 EST
New anaconda build with the patch included is available at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8251513

I'm intentionally not creating a bodhi update for it so that it doesn't affect the current release process before it is officially tested and approved as necessary and applicable for F21 Final.
Comment 39 Kamil Páral 2014-11-28 08:06:38 EST
Petr Schindler tested this today, the new anaconda build from comment 38 fixes the problem, according to him.

I vote +1 FE.
Comment 40 Petr Schindler 2014-11-28 10:37:56 EST
Yep. I reproduced this without fix and then I tested updated anaconda from koji. It fixes this bug.

+1 FE
Comment 41 Adam Williamson 2014-11-28 12:25:32 EST
Sumit: are you able to test this on the originally-affected Mac configuration? I strongly believe the problem there is the same as the non-Mac reproducer, but it'd be good to have confirmation.
Comment 42 Adam Williamson 2014-11-28 12:41:41 EST
Testing the 'workaround' a bit more, you can workaround this from the "Full disk summary" screen indeed, at least in the following way:

1. Trigger the bug, after the warning about the layout is shown, just click Done again and it'll let you back to the hub, with the Installation Destination spoke in the error state
2. Go back into Installation Destination, go to the summary screen, pick Xdb as the boot disk
3. Go back through custom part, changing nothing

this works, but it's messy and unnecessarily difficult. For me, trying to do it by going into the summary screen *before* you go to custom partitioning the first time definitely doesn't work. If we want to ship RC1 or anaconda folks decide patching this is a bad idea so late after all, we can document it at least.
Comment 43 Adam Williamson 2014-11-28 16:18:35 EST
https://www.happyassassin.net/updates/updates-1168118-rc1.img is a slightly different version of the fix (generated against 21.48.18, the anaconda in Final RC1) which I like a bit more. It would be great if folks can test that, and also test cases *other* than the reproducer of the bug - this codepath is hit on absolutely all install attempts, so it'd be very good for folks to test it with a range of different scenarios (normal UEFI installs, BIOS installs, really any kind of install at all) and make sure it didn't inadvertently break anything.

https://www.happyassassin.net/updates/updates-1168118-tc2.img is the same fix against anaconda 21.48.16, as included in F21 PPC TC2 - this new version of the fix should solve the same problem for PPC users with the prepboot/appleboot partition. Testing of that would also be helpful. The PPC reproducer is very similar to the UEFI case, just put the prepboot partition on a disk other than the first and don't explicitly choose a boot disk.
Comment 44 Sumit Rai 2014-11-28 19:15:12 EST
Created attachment 962606 [details]
Anaconda GUI Manual Partitioning screen

Mount point /boot is not updated on partiotion map box to the left even after clicking update settings.
Comment 45 Sumit Rai 2014-11-28 19:22:26 EST
Adam: I was testing update 1168118-rc1.img on my origninal Mac setup and I have come across another bug.

FYKI
#cat /proc/cmdline
BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-T4 ro rd.live.image inst.updates=https://www.happyassassin.net/updates/updates-1168118-rc1.img

I selected both mmc and internal ssd, and proceeded to manual partitioning.
I accidently set the mountpoint of partition /dev/mmcblk0p2 to / instead of /boot. When I changed the mountpoint back to /boot and clicked "Update Settings" icon, it still shows mountpoint as / in the left part of screen. I have attached GUI snapshot in my above comment and will upload full anaconda logs below.
Comment 46 Adam Williamson 2014-11-28 19:23:13 EST
Please don't. If it's reproducible, please file it as a new bug. We deal with one bug per bug report, anything else is unmanageable.
Comment 47 Sumit Rai 2014-11-28 19:24:26 EST
Created attachment 962607 [details]
All anaconda logs + dmesg

Logs for GUI "Update Settings" Bug.
Comment 48 Sumit Rai 2014-11-28 19:34:34 EST
Comment on attachment 962606 [details]
Anaconda GUI Manual Partitioning screen

Removing this attachment since it's not SOP to mix up two bugs.
Comment 49 Sumit Rai 2014-11-28 20:01:13 EST
I have not been able to reproduce stage 1 partition not found issue on MacBook with two disks(mmc + ssd) with updates-1168118-rc1.img.

However issue is not fixed in updates-1168118-tc2.img.
Comment 50 Adam Williamson 2014-11-28 20:06:48 EST
The tc2.img is the same code as rc1.img but built against a different anaconda, so I could test it on PPC64, where the latest available images were based on an older anaconda. There's no need to test the tc2 image on Final RC1 for x86. I think we can count your experience as a +1 for the patch.
Comment 51 Sumit Rai 2014-11-28 20:07:30 EST
Created attachment 962610 [details]
Anaconda logs for updates-1168118-tc2.img

[liveuser@localhost tmp]$ cat /proc/cmdline 
BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-T4 ro rd.live.image quiet rhgb inst.updates=http://www.happyassassin.net/updates/updates-1168118-tc2.img
Comment 52 Sumit Rai 2014-11-28 20:11:22 EST
Adam: +1 for the patch.
Comment 53 Adam Williamson 2014-11-28 20:12:22 EST
those logs look like somehow the updates.img was not applied, if you had used it then there should be "Disks with potentially valid stage1 volumes:" messages in anaconda.log (even if the fix didn't actually work), but there aren't. check if /tmp/updates exists and has a pyanaconda/kickstart.py with this bit in it:

            # sort the list of disks with those that contain possibly-valid
            # stage1 partitions first, so we'll pick a disk with one as
            # bootDrive if it has not been explicitly set: RHBZ #1168118
Comment 54 Sumit Rai 2014-11-28 20:51:04 EST
(In reply to Adam Williamson (Red Hat) from comment #53)
> those logs look like somehow the updates.img was not applied, if you had
> used it then there should be "Disks with potentially valid stage1 volumes:"
> messages in anaconda.log (even if the fix didn't actually work), but there
> aren't. check if /tmp/updates exists and has a pyanaconda/kickstart.py with
> this bit in it:
> 
>             # sort the list of disks with those that contain possibly-valid
>             # stage1 partitions first, so we'll pick a disk with one as
>             # bootDrive if it has not been explicitly set: RHBZ #1168118

I tried again, I found "Disks with....." string in anaconda logs as well as pyanaconda/kickstart.py in tmp/updates. I could not reproduce e bug this time. +1.
Comment 55 Mike Ruckman 2014-12-01 12:04:02 EST
Discussed in 2014-12-01 blocker review meeting. Accepted as a FE: people are understandably worried about tweaking this at this point, but the affected case is clearly bad behaviour and would be good to improve, and there's a reasonable consensus the patch is unlikely to cause bugs or unexpected behaviour changes.
Comment 56 Adam Williamson 2014-12-01 17:35:50 EST
The fix for this was reverted by the anaconda team today. Setting back to ASSIGNED, and to CommonBugs, unless we need an RC3 and a fix for this is included, we will need to document the bad behaviour of anaconda with stage1 target partitions on devices beyond the first in CommonBugs.
Comment 57 Adam Williamson 2014-12-04 19:09:17 EST
Moving to Rawhide, this is still valid there. Latest version of the patch, a substantially changed version of my v2 by Anne:

https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-December/014909.html
Comment 58 Jaroslav Reznik 2015-03-03 12:09:08 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 59 Adam Williamson 2015-03-03 15:53:54 EST
So I tried a bit more to get this through. I revived and slightly revised the patch Anne and I came up with to be more conservative (applying only to platforms where stage1 must be a partition with a particular mount point):

https://github.com/rhinstaller/anaconda/pull/21

However, dlehman is still not sure. We discussed one of the complicating factors on IRC and he would like to fix that first.

To re-explain that, as this bug is long. This does not work:

0. Boot a UEFI system with two empty disks, vda and vdb
1. Enter INSTALLATION DESTINATION, select both disks as targets
2. Click 'Full disk summary and boot loader...'
3. Select vdb and click 'Set as Boot Device', click Close
4. Click "I will configure partitioning."
5. Click Done
6. Create /boot
7. Create /boot/efi, click 'Modify...', allow it to be only on vdb, click Update Settings
8. Create swap and /
9. Click Done

You would expect "PROFIT!" to be step 10, right? No. What happens is:

10. Orange warning bar appears which says "Error checking storage configuration. Click for details or press Done again to continue."
11. Clicking the bar shows the error message "No valid boot loader target device found. See below for details. For a UEFI installation, you must include an EFI System Partition on a GPT-formatted disk, mounted at /boot/efi."

To actually make anaconda happy, you now have to do this:

12. Click Done again
13. Click Accept Changes

(you are now at the hub, with INSTALLATION DESTINATION in an error condition: "Error checking storage configuration")

14. Click INSTALLATION DESTINATION
15. Click "Full disk summary and bootloader..."

vda, not vdb, is shown as the boot disk at this point.

16. Select vdb and click 'Set as Boot Device', click Close
17. Click Done (to go back to the custom partitioning screen)
18. Change nothing, click Done
19. Click Accept Changes

*Finally*, you are now at the hub and anaconda is happy.

I believe I figured out what was going on in this case: when you try and set vdb as the 'boot disk' before running through custom partitioning, anaconda runs the is_valid_stage1_device() checks when you enter custom partitioning and rejects your choice because vdb does not yet contain a 'valid' stage1 target device (i.e. a partition of type EFI mounted at /boot/efi). So it resets the 'boot disk' to vda. Effectively it's a catch 22: you can't set the boot disk as vdb until you've created a valid /boot/efi on vdb, but putting /boot/efi on vdb will always cause anaconda to complain until you've selected vdb as the 'boot disk'.

If we could somehow 'fix' that so it at least works to select the disk on which you want to place /boot/efi as the 'boot disk' *before* entering custom partitioning, and avoid the need to click through scary warnings *then* set the 'boot disk' *then* click through custom partitioning again, that would definitely be an improvement. But I still believe it is an artificial and unnecessary requirement to require the user to select a 'boot disk' on platforms where the stage1 device must be a mounted partition in any case.
Comment 60 Adam Williamson 2015-03-03 17:41:54 EST
So I don't ever have to reconstruct the codepath that leads to the behaviour seen in #c59 again (twice was enough), here it is:

1. At step 5 in the reproducer, pyanaconda/ui/gui/spokes/storage.py class StorageSpoke method _doExecute calls doKickstartStorage(self.storage, self.data, self.instclass) , wrapped in a try/except block.

2. doKickstartStorage() is in pyanaconda/kickstart.py (at the bottom). It calls ksdata.bootloader.execute(), which leaves bootDrive set to vdb and sets storage.bootloader.stage1_disk to vdb. doKickstartStorage() then calls storage.setUpBootLoader(), without early=True.

3. That's actually blivet/__init__.py setUpBootLoader(). It calls ksdata.bootloader.execute() again (which just does the same thing it did before), then calls self.bootloader.set_stage1_device().

4. That's pyanaconda/bootloader.py class BootLoader method set_stage1_device(), which runs self.is_valid_stage1_device() on all storage devices on vdb (because it was set as bootloader.stage1_disk in step 2).

5. is_valid_stage1_device() determines that none of them is valid - because none of them has a mount point yet! - and so set_stage1_device() raises BootLoaderError.

6. The exception gets back to StorageSpoke _doExecute(), which unsets self.data.bootloader.bootDrive, as it's written to do that when it encounters a BootLoaderError exception.

7. We finish doing our partitioning and click Done. The sanity check method pyanaconda/ui/gui/spokes/custom.py class CustomPartitioningSpoke _do_check() is run on completion of the screen.

8. The sanity check code runs setUpBootLoader() again. setUpBootLoader() calls ksdata.bootloader.execute(). Because bootDrive was unset at step 6, execute() guesses vda. (If my patch is applied, this is the point at which it kicks in and guesses vdb instead and makes things work.)

9. setUpBootLoader() calls self.bootloader.set_stage_1_device() as before, it now checks all the partitions on vda, determines that none of them is valid, and raises BootLoaderError again.

10. _do_check() catches the BootLoaderError exception and sets the "Error checking storage configuration." message which we see in step 10 of the reproducer.

If the user goes through steps 12 to 19 of the reproducer, then because the /boot/efi mount point is now set, set_stage1_device() works each time it's called and things become happy.
Comment 61 William 2015-03-25 21:22:37 EDT
I use Fedora since version 2. I've been very happy using especially version 4. But since version 5 I never was happy with Fedora, which I use to this day, always in trouble, even in the versions considered "stable".

Every time I lose time in installation and after updates. This issue is ridiculous. Never Anaconda was worse. Can not work with two disks? Ridiculous. should be mature 

For me the solution above did not solve. I am outraged and leaving aside the Fedora in version 21. I was very patient, but always had to spend much time in all versions with matters which should long be mature. Especially me currently interested spin JAM, but there ubuntu studio making fame now right? I will follow with my JAM in opensuse.

I concluded that the problem is not in Fedora, but the current development pattern. I'm tired.

This time I can not apologize.
Comment 62 an0nym 2015-07-05 03:26:21 EDT
I agree with William. I am not abandoning Fedora yet though. 

I literally spent whole evening, night and morning trying to reinstall Fedora 21 into 22 on a two-internal-disk (i. e. not an SD card or USB flash) Mac Mini with striped btrfs over luks. I've added second disk after installing Fedora 21, for some reason it became sda (and the main one became sdb), but it worked. So I could not even think disk bootloader placement could be the problem (but it turned out Anaconda looked for bootloader on the first disk and EFI partitions - both standard and HFS+ - were on second disk). 

And actually such a situation (not this exact bug) occurs for the second time. When I installed Fedora 21 I spent somewhat similar amount of time understanding why standard EFI partition was not working. Considering the common error message that gives not a single hint about HFS+ necessity, I had no clue it was the problem. Until being exhausted I found a similar bug report and an explanation how to workaround. 

I understand Macs are effing ugly in the way they implement UEFI and everything but still Anaconda installer leaves a perception of an alpha version for 3 releases in a row and it seems not to be getting better. 

So I fully support what William said as I can relate to his words. 

Adam, thank you for your time. Your workaround worked after a sleepless night.
Comment 63 Chris Murphy 2015-07-05 11:47:07 EDT
The underlying assumption of the installer's custom UI is provably wrong:
- "Custom is custom, you're expected to know what you are doing", and therefore the user must always manually create an ESP mount point. See bug 1022316.

So long as there's no change in that assumption, users will continue to fall into boot loader traps.
Comment 64 Shivam Gupta 2015-08-15 14:27:26 EDT
I am a new user to Fedora but this bugzilla report seems to my issue as well.. I had fedora 20 installed which during the installation process for Fedora 21 I removed it by accepting changes during installation process of Fedora 21 and I am really fond of Fedora now so I really need to install it .

Issue ::

1) I am using USB bootable to boot fedora 21 and install it. It freezes but it worked however when I install with manual partition in it chosen automatic partition method LVM, installation completes itself though it completes but I am not able to get into Fedora 21 boot menu.

2) After installation process gets complete when trying to get into boot menu removing USB it gets into grub rescue console every time. I have re-configured as per the instructions mentioned above but still can't able to make it work.

Installation process gets complete with lots of lagging and freezing of screen.

I am not very much technical with Linux but looking for assistance to get it installed.

Using Fedora_21_x86_64.iso to boot and install.

Thank you for any help.
Comment 65 an0nym 2015-08-23 11:19:38 EDT
Shivam Gupta, post you hardware and filesystem config. Like how many disks, which one gets initialized as sda, sdb, etc, what partitions you created on what disks, have you created LVM yourself or just removed all the partitions in the installer and let it create them, have you created luks (cryptography), manually or using installer? 

I don't guarantee I will be able to help you but this information is necessary to start trying to help you.
Comment 66 Shivam Gupta 2015-09-03 02:32:06 EDT
Thank you for reply, I got it fixed actually secure boot is enabled on my system so it requires gpt disk partition for UEFI firmware to boot. So i converted my disk from MBR to GPT and it boots. Now I am using Fedora 22.
Comment 67 Mike McCune 2016-03-28 18:28:36 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 68 Fedora End Of Life 2016-07-19 14:51:42 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 69 Adam Williamson 2016-11-27 20:05:50 EST
I don't believe this was ever fixed. dlehman did have plans to work on it at one point, IIRC.
Comment 70 Adam Williamson 2016-11-27 20:06:39 EST
*** Bug 1384627 has been marked as a duplicate of this bug. ***
Comment 71 ZarakaAngel 2017-02-24 18:36:00 EST
Please fix this already, I just spent two hours figuring this out on Fedora 25 Live install
Comment 72 Fedora End Of Life 2017-02-28 04:38:53 EST
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 73 Michael Deffenbaugh 2017-10-05 03:08:39 EDT
It also fails if your /boot partition is not on the primary disk even if your /boot/efi is. (My test case had /boot in mdadm raid1 between both disks)
Comment 74 Yaroslav Nikitenko 2017-10-22 13:45:09 EDT
Installed Fedora 26 on MacBook Pro. Faced this problem. After hours of pain read carefully this post and in the middle of that found 
"So the required "Linux HFS+ ESP" is what this error message is referring to. You need to create a standard partition, ~100-200MB in size, and set the type to Linux HFS+ ESP. That's where GRUB will go, and the installer will stop complaining."
This solved the problem (just used this partition type instead of ESP). However I must add that on my another (HP) laptop the ESP is called EFI System Partition and that caused no problems with an installation of Fedora Core 24 before.

The maintainers should make the error message in Anaconda very clean and precise to save people's time, and avoid new/(incompatible with previous versions) behaviour.
Comment 75 Fedora End Of Life 2018-05-03 04:08:14 EDT
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 76 Fedora End Of Life 2018-05-29 07:50:53 EDT
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 77 Denis Leroy 2018-07-19 08:28:05 EDT
This bug stil exists today in Fedora 28. Very difficult to install Fedora on a brand new Dell G5, as it has, like many laptops today, two internal disks, an on-board 128G SSD and a regular 2.5"" disk. Trying to use the internal SSD to hold the ESP is nearly impossible as it's mapped as sdb by the linux kernel, triggering that false positive "No EFI partition error" by Anaconda.

Note You need to log in before you can comment on or make changes to this bug.