Description of problem:
F13 could not be installed on gpt disk (on system with standard BIOS, not EFI), anaconda says "sda must have a MSDOS disk label." but it dont have to be a msdos disk label, cause i've instaled (some time ago) and used F11/12 on this disk for about a year.
Version-Release number of selected component (if applicable):
F13 Alpha Live CD and F13 Alpha netinstall images.
Try to install F13 on GPT disk on BIOS (not EFI) system.
Steps to Reproduce:
I cant install F13.
F13 installed and working on GPT disk, same as F11/12.
*** Bug 574660 has been marked as a duplicate of this bug. ***
I believe dlehman has something in the works for handling GPT disk labels better. Reassigning.
I'm seeing this as well when attempting to install F13-Alpha on a slightly older-model MacBook Pro where Fedora 10 and 11 and 12 have previously been installed.
I'm happy to provide system details, remote access to the machine, etc. to help get this problem resolved. Please don't hesitate to ask if there's anything I can do to help!
(In reply to comment #0)
> Description of problem:
> F13 could not be installed on gpt disk (on system with standard BIOS, not EFI),
> anaconda says "sda must have a MSDOS disk label." but it dont have to be a
> msdos disk label, cause i've instaled (some time ago) and used F11/12 on this
> disk for about a year.
F11 did not have support for booting from a GPT disk on a BIOS system. Neither did F12. To set that up you need to use gptsync, which anaconda does not do. The basic reason is that grub (the BIOS bootloader) does not understand GPT disklabels.
The only work planned (for F14, most likely) is to make sure we create a disklabel of the correct type for the boot disk if, and only if, the user chooses "use entire drive" or "use all space" for that disk.
In my case, I also tried completely wiping the disk and setting up a GPT disk (using gparted from a F13-Alpha livecd). The installation still failed with the message "sda must have a MSDOS disk label".
Any status update here? We're getting closer to the release of F13, and I'd be happy to do some additional testing, if it helps make F13 a more solid release.
The only thing planned for F13 that is possibly related to your problems is bug 572488. I will be completely honest: I'm not even sure what the difference is between the two. I am so fed up with EFI/GPT/BIOS interoperability problems that I have unfortunately stopped caring as much as I should.
I too would also like to plead that this functionality not be removed in F13.
(In reply to comment #4)
> F11 did not have support for booting from a GPT disk on a BIOS system. Neither
> did F12.
I chose to use GPT on the 750 GB drive on my BIOS desktop at home. I can boot f11 or f12 from partitions on that disk (I'm running f12 ATM).
> To set that up you need to use gptsync, which anaconda does not do.
> The basic reason is that grub (the BIOS bootloader) does not understand GPT
Is there a communication disconnect here? Anaconda and GRUB did work just fine on my setup in f11 and f12 until someone decided to disaallow it in anaconda. If there's a good reason to remove that functionality, then I'm hosed, and I guess I'll have to live with it.
But for those of us who have been using gpt on BIOS systems, it is a royal pain to have to back up all our data (hey, I used GPT because it's a big drive), switch back to nasty old DOS partition table and restore everything. For me, removing this functionality is a huge regression.
I would also be happy to test any changes, since I can't install f13.
So, the thing is, some BIOS machines work with GPT, some work only with some really ugly hacks, and some don't work at all. And there's absolutely no way to tell which is which. So right now there's no way to actually support this functionality.
If it worked in the past, that's because we weren't properly checking to see if you were doing something we can't actually be sure will work.
(In reply to comment #10)
> So, the thing is, some BIOS machines work with GPT, some work only with some
> really ugly hacks, and some don't work at all. And there's absolutely no way
> to tell which is which. So right now there's no way to actually support this
> If it worked in the past, that's because we weren't properly checking to see if
> you were doing something we can't actually be sure will work.
I'm having this issue too. I was running Fedora 11 on it just fine with a GPT disklabel. And, you know, I have this disk, and it has all this data on it, and I can't just abandon it because I somehow got a disklabel type to work on it that you now are too cautious to support.
So, why not have an override button or something so I can force it even though the installer now doesn't want to use GPT because it can't be sure it'll work.
I second the override suggestion. I'm basically stuck on my Mac with very limited partitioning scheme options, where I would gain a lot of flexibility with GPT.
I don't mind it would be a use-at-your-own-risk option.
I attempted to do a fresh install of F13 beta on my MacBook Pro (2,2) yesterday. The idea is to have OS X and F13 installed in dual boot setup.
It appears that the new limitations make this effectively impossible.
I can boot from the install disk, but anaconda plainly refuses to go past the partitioning step with an error along the lines of "Can't install on non-mbr disk".
I tried to prepartition so anaconda only has to use the partitions, not modify the partition setup, but the result stays the same.
Next I ran gptsync on the disk so a valid mbr is created and then run the installer again. But even then, anaconda refuses to continue.
So as far as I can see, it is now impossible to install Fedora alongside OS X on my MacBook Pro, because anaconda is clever enough to detect a gpt partition table, but ignores the mbr compatibility table.
As I suppose this goes for all apple hardware, this seems like a bad regression over Fedora 12.
Ok, disregard my last two comments. F13RC3 allows the installer to continue on gpt partitioned disks. This is also what bug 572488 was about.
I'm not sure if this bug report should remain open. It seems a duplicate of bug 572488.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.