On Thu, Nov 17, 2016 at 10:50 AM, Adam Williamson
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
'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
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.