Bug 574551 - Cannot install F13 Alpha on GPT disk.
Cannot install F13 Alpha on GPT disk.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 574660 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-17 15:08 EDT by Krzysztof Urbaniak
Modified: 2011-06-27 11:11 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 11:11:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Krzysztof Urbaniak 2010-03-17 15:08:25 EDT
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.

How reproducible:
Try to install F13 on GPT disk on BIOS (not EFI) system.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
I cant install F13.

Expected results:
F13 installed and working on GPT disk, same as F11/12.

Additional info:
Comment 1 Chris Lumens 2010-03-18 01:58:46 EDT
*** Bug 574660 has been marked as a duplicate of this bug. ***
Comment 2 Chris Lumens 2010-03-19 09:45:11 EDT
I believe dlehman has something in the works for handling GPT disk labels better.  Reassigning.
Comment 3 Jared Smith 2010-03-23 12:09:01 EDT
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!
Comment 4 David Lehman 2010-03-24 11:39:08 EDT
(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.
Comment 5 Jared Smith 2010-03-28 20:25:16 EDT
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".
Comment 6 Jared Smith 2010-05-05 17:22:40 EDT
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.
Comment 7 David Lehman 2010-05-05 17:38:57 EDT
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.
Comment 8 Barry Roberts 2010-05-06 23:55:16 EDT
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
> disklabels.

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.
Comment 10 Peter Jones 2010-05-07 14:08:07 EDT
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.
Comment 11 Eric Hopper 2010-05-07 19:55:37 EDT
(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
> 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.    

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.
Comment 12 info@kobaltwit.be 2010-05-15 12:34:13 EDT
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.
Comment 13 info@kobaltwit.be 2010-05-17 09:12:58 EDT
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.
Comment 14 info@kobaltwit.be 2010-05-19 12:04:35 EDT
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.
Comment 15 Bug Zapper 2011-06-02 12:06:49 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2011-06-27 11:11:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.