Re: F17 bogus "could not detect partitions" error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mar 16, 2012, at 3:13 PM, Adam Williamson wrote:
> 
> We're talking about how to 'fix the bug' here, assuming there is one at
> all. As far as I can see, the only actual identified bugs here are in
> Windows (not nuking the GPT disk label when it creates a new MS-DOS
> label, leaving the disk in an entirely non-standard configuration) and
> parted (not being able to read this particular cracktastic,
> Microsoft-produced disk layout).

The reality is, a valid GPT requires a protective MBR, which has a particular entry. This disk doesn't have that. It has a valid legacy MBR. It passes the test for a valid legacy MBR in the UEFI spec.



>>> It has tried its hardest, but nothing doing.
>> 
>> That's debatable. 
> 
> I'm describing the *current situation*, not arguing about how it could
> possibly be improved. The point I'm trying to get you to understand is
> that you have identified one specific scenario here, but the code path
> you're hitting in anaconda is one that handles many other scenarios in
> addition to this one. You can't consider this situation in isolation in
> analyzing what anaconda is doing. You're only going to fully understand
> what's actually going on, and therefore be able to propose a good 'fix',
> if you grok that.

Likewise, you're only going to fully understand when you stop suggesting the current situation's partition table is invalid, wrong, non-standard, corrupt, cracktastic, or nonsensical. 

First we need to agree that this is a valid legacy MBR. Second, that there is no rational argument that legacy tools that create MBR partition schemes can possibly be held responsible for wiping out GPTs.

Third whether the solution is better dealt with in parted or anaconda. And for that parted devs need to accept or deny responsibility for parted's present behavior. If parted won't ever deal with this confusion rationally, anaconda will need to itself or depend on other tools that can deal with the confusion.

Personally, I think in the meantime, Fedora should walk back GPT disks on BIOS hardware. Anything less than 2.2TB probably should be MBR. Anything bigger should be GPT.


> The scenario you've identified is clearly a problem, and we can
> certainly consider how to fix it. I'm just trying to make sure you
> understand that the message you're seeing in anaconda is one that is
> also displayed in _all sorts of other scenarios_.

It should be more generic, in that case. It's not obvious it's generic by the language used. And "If not" is a poor way to say "Or". I should see how that was translated into other languages.


Chris Murphy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux