I'm not yet filing a bug because I think this mostly "works as designed" however it's a flawed design, in my view. It results in a hideous user experience. Part of the bug, in my opinion, is due to parted's behavior. But anaconda has a role in this also because it comes up with yet a different message than parted, but it's still wrong. This problem was originally found by a user, using F16. I've reproduced it using F17 beta TC1. The setup: ----------- Disk has a valid MBR, and a perfectly bootable Windows 7 system. Upon launching Fedora installer (F16 or F17 beta TC1), after choosing "Basic Storage Devices" I get a message: The storage device below may contain data. [lists the disk type size connection etc] We could not detect partitions or filesystems on this device. This could be because the device is blank, unpartitioned, or vitual. If not, there may be data on the device that can not be recovered if you use it in this installation....... Yes, discard any data = DESTROYS the MBR and the Windows 7 installation if proceeding beyond installation type selection and writing changes. No, keep any data = failure to install. The result: ------------ 1. I can blow away Windows. 2. I can quit the installer. 3. I get no 3rd option. This is a truly hideous user experience, across the board. None of the explanations in the anaconda dialog are true. The disk is not blank. It is not unpartitioned. It is not virtual. (OK original user report is a real hard drive, but I reproduced this with a VM.) Here's how I can reproduce the problem. Steps to reproduce the problem: -------------------------------- 1. Brand new unpartitioned disk. 2. Install Fedora 16/17, which causes by default a GPT scheme to be used. 3. Realize you should have installed Windows 7 first. 4. Blow away Fedora with the Windows 7 installer, which by default creates an MBR scheme, but does not blank out the GPT. 5. Try to install Fedora. Result: Major fail, per above. parted has this to say about the disk: --------------------------------------- Warning: /dev/sda contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partitiontable. Is this a GPT partition table? yes/no? Yes treats it as GPT, with the full GPT data intact. No treats it as unknown, with no partitions at all intact. I separately have mentioned the following complaints about parted's behavior, on the bug-parted@ list, but I'll list a summary here: 1. The message is bogus and confusing. It says the disk has GPT signatures, but then later says maybe they've been deleted. Which is it? In fact the GPT is not corrupt, and not deleted. 2. UEFI spec suggests a valid legacy MBR shouldn't be treated as GPT. It's an MBR disk unless it has a valid protective MBR, which this disk does not have. 3. parted appears to have no way to handle this situation, made more common now that Fedora is defaults to GPT on "Use All Space" and new unpartitioned disks. So those are the facts. Next it's a question on how to improve the result, or at the very least not produce totally bogus error messages that don't tell the user what the problem really is, or how to fix it. What fixes this is deleting the GPT and rerunning the installer. fixparts and gdisk can do this. I'm not finding anything in parted that can help, but I have by no means done an exhaustive search. Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
