Bug 979205

Created attachment 766360 [details]
anaconda.log

Created attachment 766361 [details]
packaging.log

Created attachment 766362 [details]
program.log

Created attachment 766363 [details]
storage.log

Created attachment 766364 [details]
storage.state

Version-Release number of selected component (if applicable):
Fedora-19-x86_64-DVD.iso
anaconda-19.30.13-1
mactel-boot-0.9-8

just to be clear, if you actually go ahead and manually create an EFI system partition, does it work?

Do you hit this if you use guided partitioning rather than custom partitioning+autopart?

Before 19.30.10 (and blivet 0.17) we weren't catching missing /boot/efi in manual partitioning, and we weren't reusing existing ESP's. The log line about skipping should mean that it is using the existing one.

(In reply to Adam Williamson from comment #7)
> just to be clear, if you actually go ahead and manually create an EFI system
> partition, does it work?

No. To further qualify the answer:

1. Guided partitioning/reclaim space, if I leave an existing /boot/efi set to preserve, I still get the error.

2. Manual partitioning, I'm not allowed by the UI to reuse an existing /boot/efi (options to set it as a mount point are grayed out). If I click + to manually add one, then the blue link to automatically creating partitions vanishes.

"1. Guided partitioning/reclaim space, if I leave an existing /boot/efi set to preserve, I still get the error."

That's a case we just need to test a bit harder in general, I think. Not exactly what I asked.

"2. Manual partitioning, I'm not allowed by the UI to reuse an existing /boot/efi (options to set it as a mount point are grayed out). If I click + to manually add one, then the blue link to automatically creating partitions vanishes."

Well, sure, that's just how it works - as soon as you create any partition, you lose the ability to use autopart. I was more thinking of you doing autopart *then* reducing the size of one partition and adding an ESP. But just manually creating the whole layout would also be valid. I'm just trying to establish if you can actually create a working setup and the problem is just that we're not smart enough to help you do it very well, or if you're really stymied.

Before writing any commonbugs notes here I'd want to do an awful lot more investigation of how we're behaving on multi-boot UEFI installs in general. I'm sure there's lots of wackiness there.

(In reply to Adam Williamson from comment #10)
> I was more thinking of you doing
> autopart *then* reducing the size of one partition and adding an ESP.

I get the error message immediately upon clicking the blue link to partition automatically. No partitions are created when I click this, only the error message.

> But
> just manually creating the whole layout would also be valid. I'm just trying
> to establish if you can actually create a working setup and the problem is
> just that we're not smart enough to help you do it very well, or if you're
> really stymied.

With or without an existing system, guided partitioning is broken, manual partitioning's automatic option is also broken. 

Manual partitioning performed manually does work.


> 
> Before writing any commonbugs notes here I'd want to do an awful lot more
> investigation of how we're behaving on multi-boot UEFI installs in general.
> I'm sure there's lots of wackiness there.

The use case is completely removing the prior OS, and installing Fedora 19. I used to be able to do that with guided+reclaim space, now I can't. So it's not multiboot, but rather a replacement scenario.

I just did regression testing in an existing working VirtualBox UEFI VM, and the problem is not reproducible. It seems this is limited to Macs.

Thanks. But if the use case is 'completely removing the prior OS, and installing Fedora 19' I'm confused at the reference to 'if I leave an existing /boot/efi set to preserve'. If you just wipe all existing partitions in 'reclaim space', does it work?

(In reply to Adam Williamson from comment #12)
> Thanks. But if the use case is 'completely removing the prior OS, and
> installing Fedora 19' I'm confused at the reference to 'if I leave an
> existing /boot/efi set to preserve'. If you just wipe all existing
> partitions in 'reclaim space', does it work?

Yeah that was confusing: I wasn't considering one instance of OS X and one instance of Fedora to be multiboot because they don't share boot managers or boot loaders. They're completely segregated, even down to having separate ESPs.

So what I think is happening for the first time due to the recent changes, is anaconda is finding the real FAT32 ESP created by Apple's partitioning tool (disk utility), and thinks it doesn't have to create an hfs+ one, but then mactel-boot code is mad because an hfs+ one hasn't been created.

If I set the hfs+ /boot/efi to preserve or delete, autopartitioning fails (this bug).

If I set the FAT32 EFI System partition to preserve or delete, autopartitioning fails.

Autopartitioning is only working if I set the whole disk from preserve to delete, or if I nuke the GPT.

Yeah so it doesn't matter if the state of the two ESPs is preserve/preserve or delete/preserve or preserve/delete or delete/delete, autopart fails. Only if I set the disk to delete (thereby deleting all partitions) does autopartitioning work. Weird.

"So what I think is happening for the first time due to the recent changes, is anaconda is finding the real FAT32 ESP created by Apple's partitioning tool (disk utility), and thinks it doesn't have to create an hfs+ one, but then mactel-boot code is mad because an hfs+ one hasn't been created."

Yeah, that sounds about right. As  bcl mentioned in comment #8, we did include a change late that tries to re-use a pre-existing ESP. Sounds like that needs some tweaking. There's always another damn corner case.

bcl, do we need logs from any of the different cases mentioned above?

(In reply to Adam Williamson from comment #16)

I'm unsure of the interaction between anaconda and mactel-boot, but it seems that  mactel-boot would be a modifier of anything anaconda does. So it may be that the fix belongs in mactel-boot. And that also ought to protect non-Mac installs from being adversely affected by a fix, should it come before release.

If it comes to a vote on blocking, I'd really be on the fence just because it's so late. I'm leaning -1 even though it'll be a really icky bug for Mac users.

We're already past go/no-go meeting, any attempt to 'block release' for this would involve a major policy change and have to happen at a much higher level than in-bug voting.

As you describe the issue it doesn't seem to be so much that 'we try and write some configuration and it fails', it's more just a logic failure in anaconda's check for a valid ESP, and that check is definitely in anaconda not in mactel-boot, I think. But I should probably stop speculating and just get some data. I'm going to get our guys in Brno to test this with our test Mac hardware and see if they can reproduce, and if so, probably attach more logs. I'm sure the devs should be able to figure it out from there.

Understood.

Is it possible there can be an updates image available that'd fix this if applied when booting media? And if so could that reference be put in common bugs?

FWIW I've tested this on two Macs of different vintages, and both exhibit the same problem. While it's not reproducible at all with VirtualBox UEFI.

"Is it possible there can be an updates image available that'd fix this if applied when booting media? And if so could that reference be put in common bugs?"

Yeah, we all already thought of that separately, it'll probably happen if we can identify a clear fixable bug here. Mjg also suggests that people can simply install Beta and update.

True, although the small problem with recommending beta is that neither gnome method of updating worked, so if "use beta" is the recommended work around for this bug then we'll also need to recommend a one time update with yum.

Somehow missed this off of common bugs. It'd be really nice if someone else could test and confirm cmurf's results before I write it up.

re: the write up. For the less initiated user, there's a really unfortunate collision of bugs that makes a recommended work around more difficult.

1. Most (probably all) Macs lack wireless upon a Fedora install due to needing b43 proprietary firmware, so updates image isn't available unless it's on a USB stick.

2. Beta has two bugs that causes the two Gnome update methods to not work.

If we recommend final release, they either have to use custom partitioning or be instructed how to use an updates image on a USB stick. If we recommend beta, they need to be instructed to copy b43 firmware, reboot, and then do the first software update using yum. In any case, they'll have to deal with the command line at some point.

On quite a few laptops, the two USB ports are so close to each other that it's often not possible to get two USB sticks inserted at the same time, and as the install media will almost certainly have been dd'd, it means the updates image on a usb stick approach will require two sticks. So at the moment my suggestion is two work arounds:

A. If you have ethernet, use the final release with updates image via network.

B. If you don't have ethernet, use beta release, install b43 firmware, do the first software update with yum.

Just a thought. Also, I've reproduced the bug on three Macbook Pro vintages 2008, 2011, and 2012.

Created attachment 768522 [details]
dmesg.log

Apple Inc. MacBookPro9,2/Mac-6F01561E16C75D06, BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012

Created attachment 768523 [details]
storage.log

MacBookPro9,2 (2012)
Same problem as the other models. No matter how much free space I have, or free up through Reclaim Space, if I don't choose the whole disk device for deletion, I get this bug.


23:29:29,831 INFO blivet: skipping unneeded stage1 hfs+ request
...
23:29:29,981 DEBUG blivet: failed to set bootloader stage1 device: failed to find a suitable stage1 device
23:29:29,987 ERR blivet: you have not created a bootloader stage1 target device

Chris: a thought on issue #1: can you bring up the wireless adapter successfully when booting from a live image?

(In reply to Adam Williamson from comment #26)
> Chris: a thought on issue #1: can you bring up the wireless adapter
> successfully when booting from a live image?

No, it doesn't even see the interface existing because the firmware isn't there at boot time. I'm 90% certain (or 100% wrong) that I've made media with a persistent overly, added the firmware, and that does allow wireless to become available. But that requires access to something that can run livecd-tools.

So, I'm a bit confused on the scope here...

My reading of comment #15 is that if you specify wiping the entire disk and autopartition it works and you get a completed install? Or did I read that wrong?
(This of course doesn't help anyone who wants to keep osx around)

And we think this is All apple hardware? Or a subset?

(In reply to Kevin Fenzi from comment #28)
> My reading of comment #15 is that if you specify wiping the entire disk and
> autopartition it works and you get a completed install?

Correct.

> And we think this is All apple hardware? Or a subset?

I think it's all hardware that mactel-boot identifies as needing an hfs+ EFI System partition created, which ought to be all Apple hardware.

So far it happens on all the models I've tested: MacbookPro models dating 2008, 2011, and 2012.

I don't think this is hardware related at all. I think it's an interaction between anaconda and mactel-boot but I don't fully understand the logic or what part thinks an ESP hasn't been created. But it's triggered by the presence of either the FAT32 ESP (created by the OS X Disk Utility whenever it GPT partitions a disk), or the hfs+ ESP created by anaconda+mactel-boot from a prior Fedora.

So the bug is triggered merely by having any ESP on the disk.

Hum, then it's actually less bad than I thought. mjg59 and I seemed to be reading it as 'any non-custom install attempt on a UEFI Mac will fail' up till now, I think.

A non-custom install attempt on EFI Mac attempting to preserve any prior OS X or Fedora installation will fail.

Common bugs entry added: Chris, please advise me of (or simply correct) any inaccuracies you see. thanks!

FYI it is possible to use livecd-iso-to-disk with overlay to create a stick with persistently functioning wireless. Once the proprietary firmware is added to /lib/firmware, it's found on subsequent reboots, and NetworkManager even remembers, and automatically connects to, recent wireless connections.

I am encountering this bug.

I need to do custom partitioning in order to preserve my /home partition from my current Fedora 14 set up.

As far as I can tell from reading the comments here, it's not possible. is that right?

(In reply to Colin Adams from comment #34)
This is on a Mac? Custom partition is one of the work arounds for the bug, but you need to create a /boot/efi mountpoint (which on Macs should default to hfs+ format) in addition to /. You should be able to locate the partition for the prior home, click on it, and set its mount point to /home.

This is on a MacBook Air (version2)

I don't understand what "create a /boot/efi mountpoint (which on Macs should default to hfs+ format)" involves.

In Manual partitioning, you click +, and in the resulting dialog choose the mountpoint /boot/efi and set the size to 100MB. See the commonbugs entry and if that's not clear then comment on the points of confusion so that it can be fixed.

https://fedoraproject.org/wiki/Common_F19_bugs#Apple_EFI_Macs:_EFI_install_alongside_existing_EFI_installed_OS_.28including_OS_X.29_results_in_you_have_not_created_a_bootloader_stage1_target_device_error

That doesn't work. It says there is not enough space on the device.

And that's after deleting a 3.8GB Swap partition, and a 500MB /boot partition. The free space remains at 1.05MB, which is what it is to start with.

(In reply to Colin Adams from comment #38)
Fedora 19 requires 10GB free space, so the message that there isn't enough space, give your description of what you've deleted, seems correct. This bug is about EFI System partition issues, not space issues. If you need help with creating enough free space for Fedora to install, I suggest posting in:
http://www.forums.fedoraforum.org/forumdisplay.php?f=51

But there's a 50GB / partition. I marked it to be formated.

(In reply to Colin Adams from comment #40)
See what you did? You didn't say that originally. Start over and create /boot/efi first so that there's enough space to create it. Doesn't seem difficult to figure out that if you don't have enough space to create /boot/efi that the installer will tell you that there's not enough space.

But as I explained, I deleted a 500MB /boot partition, and a 3.8GB swap partition. That should be plenty to fit a 100MB partition into.

(In reply to Colin Adams from comment #42)
Except the installer is apparently confused if it's still showing 1MB free after you've deleted 3.85GB. That would be a different bug, which would be a good idea to file, just make sure you save out program.log and storage.log so you can attach them to the new bug report. Then if you start over and specify /boot/efi, /boot, swap, /, then reuse the old home by specifying a mount point.

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

May fix this issue. It changes 2 things in blivet:

1) allow 'efi' on Mac so that pre-existing vfat ESP's can be selected in custom and mounted to /boot/efi

2) Set the mountpoint for pre-existing hfs+ ESP to /boot/efi so that autopart will work.

Note that I have tested #1 (my air was setup for bootcamp so the ESP was vfat). These patches haven't been reviewed, may eat your data, etc. But you can give them a try and see if they help.

You can create a usb stick using livecd-iso-to-disk --efi --format --updates 979205.img /path/to/iso /path/to/usb

so that you don't need network to get the updates.img

(In reply to Brian C. Lane from comment #44)
> 1) allow 'efi' on Mac so that pre-existing vfat ESP's can be selected in
> custom and mounted to /boot/efi
 
> 2) Set the mountpoint for pre-existing hfs+ ESP to /boot/efi so that
> autopart will work.

At least you need to make sure that if both vfat and hfs+ ESPs are present, that the hfs+ one is favored or it results in an unbootable system.

However, because Apple's firmware ignores bootloaders on vfat ESPs if there's no NVRAM entry; and also it always favors hfs+ bootable volumes even if its NVRAM boot order entry is after a vfat ESP located bootloader. This is why mactel-boot creates hfs+ ESPs for grub. I honestly don't see the use case for relying on the existing vfat ESP. On three of my Macs, it's only workable if NVRAM is devoid of any other entry except for Fedora. And no advantage to just creating the hfs+ one if it's not present.
 
> Note that I have tested #1 (my air was setup for bootcamp so the ESP was
> vfat).

I don't follow this. Boot Camp is an OS X application, so if you have grub on the vfat ESP, then Fedora isn't a boot option in either the OS X System Preferences Startup disk panel, and isn't available in the firmware's boot time disk selector. The only way mactel-boot works is by virtue of the ESP being hfs+, and grub files being installed there.

Also, Boot Camp creates hybrid MBRs which is the antithesis of mactel-boot. So I'm pretty confused at this point. I'll try the updates image in some scenarios and report back.

Attempt 1: Guided partitioning to free space on a Mac that has 3 partitions: a fat32 ESP, OS X, and OS X recovery.

With updates.img in comment 44, the error in this bug isn't triggered. However on a MBP4,1 Fedora doesn't boot after installation, OS X does. And Fedora isn't a boot option in either the System Preferences Startup Disk panel, or in the firmware's boot (time) options menu. So Fedora isn't bootable at all. Further investigation reveals that an hfs+ ESP was not created, rather the existing fat32 ESP was used.

I think using an existing fat32 ESP on Apple hardware is untenable for either guided or custom partitioning, with or without OS X.

Why would OS X be able to boot from a FAT32 ESP but Fedora not? That doesn't seem to make sense.

OS X doesn't boot from a FAT32 ESP.

yeah, nevermind. Those patches didn't help things. And the bootcamp thing was irrelevant.

rEFIt shows two options on the flash drive, grub and boot. Booting grub with 'quiet' and 'rhgb' removed and with 'selinux=0', 'noefi', and 'nogpt' eliminates this problem. This is tested on a late 2009 MacBook Pro. Install completes and device boots.

(In reply to Rudi Plesch from comment #50)
> rEFIt shows two options on the flash drive, grub and boot. Booting grub with
> 'quiet' and 'rhgb' removed and with 'selinux=0', 'noefi', and 'nogpt'
> eliminates this problem. This is tested on a late 2009 MacBook Pro. Install
> completes and device boots.

After thinking about it for a bit, I think this can only be used to install a legacy bootloader and will only work with bootcamp.

This is still a bug with Fedora 20 alpha RC4. It prevents testing Fedora on Macs unless the user is willing to delete all existing partitions. Closing this bug as duplicate of new bug 1010495.

*** This bug has been marked as a duplicate of bug 1010495 ***