On Thu, Nov 17, 2016 at 10:50 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
