On Thu, Nov 17, 2016 at 10:50 AM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On 2016-11-17 10:30 AM, Chris Murphy wrote:
>
> Not exactly. I do the same tests every cycle and assumed I had done
> those tests, and I still think I did, but it's possible there's some
> unusual nuance in my particular setup that caused me to not hit the
> bug. But I'm not traveling with my Mac at the moment so I still
> haven't been able to do an autopsy on what testing I have done, or how
> the layout of that machine could affect the outcome of the bug. The
> bug is really straightforward as I understand it, so I'm still kinda
> mystified how I didn't run into it other than just being distracted
> with a new non-Mac laptop.
What I suspect is that you didn't do a fresh dual-boot install, but always
installed over an existing Fedora install. I did not look into exactly what
the old code does in that case.
That is the most logical explanation, but the thing is, I previously
have always done clean install tests.
I'm fairly sure in that case it would identify *both* the real
existing
'macefi' partition and the OS X system partition as 'macefi' partitions.
For some time now, the system partition is not HFS+ and not
identifiable as HFS+ and cannot be mounted on Linux in any way. The
default installation uses Core Storage (Apple's LVM like thing), and
even converts non-Core Storage systems upon upgrade so that they use
it. The one thing that remains HFS+ on these systems is the Recovery
HD partition, which is approximately like a hybrid between a Linux
/boot volume and Live image. There's enough ambiguity here that I
simply can't account for how I missed it, except that there was
something about the system that was not "out of the box" - otherwise
it's pretty clear I'd have hit the bug. But for this to go one for an
entire release... quite unexpected. Usually I install Rawhide a couple
times per year, and either alpha or beta or both, cleanly. It is a
side effect of my entire mantra here, is that the installer is just
not trustworthy and has all kinds of regressions (not just bugs for
new features).
But
it only needs to pick *one* of them to be /boot/efi. I did not bother
figuring out how it makes that decision. My best guess is that it happens to
pick the 'real' macefi partition in that case - either reliably, or it's
unpredictable/random but it happened to pick the right one in your case -
and then the install would work OK.
It must've picked a previous LInux HFS+ ESP, which I normally
obliterate when doing testing for exactly the reason in this bug. I'm
aware that the code tries to reuse this partition rather than create a
new one. And aware that it won't use the FAT32 one.
--
Chris Murphy