Bug 503149 - Add features to Anaconda to aid installation on Apple computers
Add features to Anaconda to aid installation on Apple computers
Status: CLOSED DUPLICATE of bug 746901
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
15
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: FutureFeature, Triaged
: 505128 505817 521527 525765 530654 547976 579826 582398 597317 604488 640133 641531 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-29 05:24 EDT by csvanefalk
Modified: 2011-12-07 12:53 EST (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-07 12:53:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description csvanefalk 2009-05-29 05:24:54 EDT
Suggest that a feature is added to Anaconda to
 
1. allow the disk bootloader installer to install GRUB to a root partition, as well as 
2. use the gptsync utility to handle MBR/GPT hybrid tables. 

It might also be beneficial it it was possible to flag partitions directly in the partitioner during install.

This would greatly help users of Macintosh Intel-based computers to install Fedora on a blank-slate (firmware-only, no data on hard drives) Macintosh, as these otherwise seem to need much extra tweaking (I myself have a Macbook Pro and understand this scenario) and possible reliance on proprietary software (OSX).
Comment 1 Chris Lumens 2009-05-29 14:15:47 EDT
What extra tweaking is currently required?  I'd like to understand the problem here before we start doing some modifications.
Comment 2 csvanefalk 2009-06-02 10:27:19 EDT
(In reply to comment #1)
> What extra tweaking is currently required?  I'd like to understand the problem
> here before we start doing some modifications.  

Hi Chris, sorry for the late reply.

The ONLY way I have been able to get Fedora to run on my Macbook has been bý using Boot Camp (which should not be necessary at all, see the article below). It appears that trying redirect the boot process to hand the reins over to GRUB is not working any other way (the system simply tells me it cannot find a bootable device, or simply gives me a black screen with a flickering cursor). 

This article gives some good pointers on how this could be resolved, but it has not worked on my side:

http://www.tuxation.com/linux-on-mac.html

I need some info here: does formatting a given partition in Anaconda remove any flags on that partition? For example: assume I use a live version of Fedora (which I have succesfully managed to do), and run parted to flag a partition as "boot". I then try to boot an install dvd of Fedora, and when setting up the disc, I format that partition as "/", but with another file system. Would this kill the boot flag?

In light of the above, it appears that the core of the problem is in the EFI of the Mac, which apparently looks for the boot loader in the wrong place. I am not sure how Boot Camp works around this, but if we only could try and install GRUB somewhere else during install, it could very well be solved. 

As a reference, I believe the OpenSUSE 11.1 installer allows such installs. Sadly, I cannot even run that installation on the Mac due to a silly systime-check on the SUSE dvd which aborts the installation.
Comment 3 csvanefalk 2009-06-02 10:46:52 EDT
(In reply to comment #1)
> What extra tweaking is currently required?  I'd like to understand the problem
> here before we start doing some modifications.  

Addition to last post:

I forgot to point out my platform, we can use it as a reference:

Macbook Pro 1.1 (2006)
Intel Dual Core 2.16 (not Core 2 Duo)
2 GB DDR2 667Mhz
ATI X1600, 256MB

As mentioned in the article I supplied before, Macs differ from PC:s as they use EFI instead of an ordinary BIOS. They also use firmware, but I dont believe the firmware itself is the root of the problem.
Comment 4 Chris Lumens 2009-06-05 11:50:14 EDT
Jeremy - you mentioned the other day that we used to take care of the problems in this bug.  Could you refresh my memory on what those fixes are so I can bring them back into the new storage code?
Comment 5 Jeremy Katz 2009-06-07 21:53:50 EDT
It looks like the old commits were e16aec2d0892f391da7cfb8d2474602b5e924698 and 43567ab91550fe33b2c8a7b0e6bd4ea595f79fbf
Comment 6 Bug Zapper 2009-06-09 12:45:54 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Andy Lindeberg 2009-06-10 14:36:44 EDT
*** Bug 505128 has been marked as a duplicate of this bug. ***
Comment 8 Jeremy Katz 2009-07-08 11:12:50 EDT
*** Bug 505817 has been marked as a duplicate of this bug. ***
Comment 9 Bill McGonigle 2009-07-08 11:32:06 EDT
In the preupgrade/anaconda place, simply leaving the partition table alone if no alterations are specified would be a big help.

Current F10->F11 upgrades leave an unbootable system until gptsync is run, but I'm unaware of a need to alter the partition table in that case.
Comment 10 Chris Lumens 2009-09-09 10:49:07 EDT
*** Bug 521527 has been marked as a duplicate of this bug. ***
Comment 11 W. Michael Petullo 2009-09-29 21:42:29 EDT
For the record, the following steps allowed me to install Fedora 11 on my MacBook aluminum. I have no Mac OS X install, just Fedora, directly on a MSDOS partition table on the laptop's disk.

1. Install Fedora x86_64 using network install CD.

2. Provide the kernel with the "text" argument.

3. Early in the install process (as soon as a command prompt is provided on a VT), use parted to create an msdos partition table on the disk.

4. Add to the kernel command line:

vga=0x318
all_generic_ide (to allow DVD's to play)

5. After the install is done, boot using the DVD and run "grub-install /dev/sda."
Comment 12 Chris Lumens 2009-10-07 11:35:38 EDT
*** Bug 525765 has been marked as a duplicate of this bug. ***
Comment 13 Fabian Deutsch 2009-10-09 10:33:32 EDT
(In reply to comment #11)
> For the record, the following steps allowed me to install Fedora 11 on my
> MacBook aluminum. I have no Mac OS X install, just Fedora, directly on a MSDOS
> partition table on the laptop's disk.

Really an MSDOS parttable or an vfat partition?

AFAIK it is necessary to have an fat32 partition containing all that efi.bin stuff, so i wonder if you got it to work without an fat32 partition or if anacoda created it ...
Comment 14 W. Michael Petullo 2009-10-10 08:56:10 EDT
> > For the record, the following steps allowed me to install Fedora 11 on my
> > MacBook aluminum. I have no Mac OS X install, just Fedora, directly on a MSDOS
> > partition table on the laptop's disk.

> Really an MSDOS parttable or an vfat partition?
> 
> AFAIK it is necessary to have an fat32 partition containing all that efi.bin
> stuff, so i wonder if you got it to work without an fat32 partition or if
> anacoda created it ...  

An MSDOS partition label:

(parted) print
Model: ATA FUJITSU MHZ2250B (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  210MB  210MB  primary  ext3         boot
 2      210MB   250GB  250GB  primary               lvm

Here is my grub.conf:

default=0
timeout=0
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.31.1-56.fc12.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.31.1-56.fc12.x86_64 ro root=/dev/mapper/VolGroup-lv_root quiet vga=0x318 all_generic_ide SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	initrd /initramfs-2.6.31.1-56.fc12.x86_64.img
title Fedora (2.6.31.1-48.fc12.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.31.1-48.fc12.x86_64 ro root=/dev/mapper/VolGroup-lv_root quiet vga=0x318 all_generic_ide SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	initrd /initramfs-2.6.31.1-48.fc12.x86_64.img
title Fedora (2.6.31-40.fc12.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.31-40.fc12.x86_64 ro root=/dev/mapper/VolGroup-lv_root quiet vga=0x318 all_generic_ide SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	initrd /initramfs-2.6.31-40.fc12.x86_64.img
Comment 15 Fabian Deutsch 2009-10-10 10:38:27 EDT
I suppose you have got bootcamp installed?

The correct way would be to use an gpt pt, with an fat16 partition, holindg the efi stuff an don some secondary partitions fedora.
Comment 16 W. Michael Petullo 2009-10-11 00:44:30 EDT
> I suppose you have got bootcamp installed?
> 
> The correct way would be to use an gpt pt, with an fat16 partition, holindg the
> efi stuff an don some secondary partitions fedora.  

No Bootcamp. No Mac OS X. No Apple software or EFI stuff on the hard drive. Just Fedora. It works for me with the notes in comment #11. I added this configuration to this bug report as a reference.
Comment 17 Adam Williamson 2009-10-21 11:41:37 EDT
This was discussed at the blocker review meeting today. It can't block the release, it's a feature request that was not put on the official feature list, and you _can_ install to these machines per comment #11.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Chris Lumens 2009-10-21 11:50:04 EDT
This is not a feature request.  This is a bug report to fix booting issues on machines that used to work but haven't since the storage rewrite.

Comment #11 is a hack all the way around, especially since it mentions text mode installation which we don't even recommend or particularly want people to use.
Comment 19 Bill McGonigle 2009-10-21 14:56:03 EDT
Also, comment #1 specifies a blank-slate machine, which isn't the common situation.  I think something was lost when this bug got spun off from the other one.  We used to be able to install to a partition on a GPT disk, leaving the other OS'es alone.  This worked through Fedora 10.
Comment 20 Adam Williamson 2009-10-21 18:54:22 EDT
chris: ah, it wasn't clear that this was something that worked okay before the storage rewrite, I understood that it had never really worked this way.

still, would this be a big change to land after beta?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Bill McGonigle 2009-10-22 18:40:16 EDT
FYI, bug 194001 was the original (in F6), before the storage rewrite regression.
Comment 22 Chris Lumens 2009-10-26 10:44:10 EDT
*** Bug 530654 has been marked as a duplicate of this bug. ***
Comment 23 Chris Lumens 2009-12-16 15:47:53 EST
*** Bug 547976 has been marked as a duplicate of this bug. ***
Comment 24 Rafael Ávila de Espíndola 2009-12-16 16:20:38 EST
Just copying over some info from 547976:

The install fails *with bootcamp installed*. Syncing the mbr using refit didn't help. Reinstalling grub to /dev/sda3 failed.

I managed to install ubuntu, but it uses grub2 so it is hard to see what it is doing different.
Comment 25 Debarshi Ray 2010-01-15 03:25:39 EST
The situation just got worse with Fedora 12. Once I finish installing Fedora on my rEFIt + MacOSX system with GRUB installed on /dev/sda3 (not the MBR), Fedora fails to boot (as before with F11). However this time running gptsync does not retrieve the situation and the kernel just panics. I have tried this twice (the second time with the updates repository enabled) and the result is the same.

I had initially filed the bug about the problems with F11 at: https://bugzilla.redhat.com/505817 which got marked as a duplicate of this bug.
Comment 26 Aaron Hamid 2010-02-12 18:26:08 EST
FWIW, I can't get my brand new macbook pro 5,3 w/ rEFIt to even boot either the x64 Live CD or x64 Install DVD.  The Install DVD isn't even recognized (i checked the sha and burned twice, i'm pretty sure the disc is ok), and attempting to boot the Live CD just drops me directly into a GRUB prompt, and I can't do anything from there.
Comment 27 Benjamin Kosnik 2010-03-02 13:38:25 EST
In same boat with intel macmini2,1. Since F10, nada. Now trying to get F12 up. Agree with #18 that this is a bug, not a feature of the rewrite.

Using gpt partitions from 10.6, f12 unity respins of x86 and x86/64, no boot camp no refit. default installs don't work, can't even get a boot disk with option at boot, but gptsync will get the boot partition, but selecting it leads to blank screen with blinking cursor.

note that karmic does work on this hardware. The partitions that comes up with are much different than fedora:

(parted) p                                                               
Model: ATA Hitachi HTS54168 (scsi)
Disk /dev/sda: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name                  Flags
 1      20.5kB  210MB   210MB   fat32           EFI System Partition  boot
 2      210MB   40.1GB  39.9GB  hfs+            mac
 3      40.1GB  40.1GB  1000kB                                        bios_grub
 5      40.1GB  76.4GB  36.3GB  ext4
 6      76.4GB  78.0GB  1603MB  linux-swap(v1)


this boots. what is bios_grub and how can I get grub installed there for f12?
Comment 28 Debarshi Ray 2010-03-02 13:52:38 EST
Well, this is how I got Fedora 12 too boot:
http://debarshiray.wordpress.com/2010/01/15/fedora-11-12-on-an-intel-macbook-getting-it-to-boot/
Comment 29 Aaron Hamid 2010-03-02 13:57:43 EST
I was able to get Fedora 12 to *start* to boot via a Live image on USB drive, however the installer always freezes after a graphical glitch almost immediately after booting into it (after the text-mode progress bar).  I tried various workaround kernel/boot options regarding text mode and VGA driver.  No go.  I don't want to nuke my OS X partition, so I guess I'll just wait until there is a real solution.
Comment 30 Benjamin Kosnik 2010-03-02 14:14:16 EST
From:
http://www.gnu.org/software/parted/manual/parted.html

‘bios_grub’
    (GPT) - Enable this to record that the selected partition is a GRUB BIOS partition.
Comment 31 Benjamin Kosnik 2010-03-02 17:17:05 EST
bios_grub is only in grub2, which fedora is not using. So no wonder.
Comment 32 Chris Lumens 2010-04-07 09:05:24 EDT
*** Bug 579826 has been marked as a duplicate of this bug. ***
Comment 33 Benjamin Kosnik 2010-04-13 16:06:37 EDT
Update for f13b, live 86_64. On install, get error:

The following errors occurred with your partitioning:
sda must havea MSDOS disk label

This can happen if there is not enough space on your hard drive(s) for the installation.

Press 'OK' to choose a different partitioning option.

Only choice, really, and from there we get back to the "Which type of installation would you like" page, on which "replace existing linux systems" is firmly checked.
Comment 34 Chris Lumens 2010-04-14 16:00:45 EDT
*** Bug 582398 has been marked as a duplicate of this bug. ***
Comment 35 David Lehman 2010-04-14 18:57:46 EDT
(In reply to comment #33)
> Update for f13b, live 86_64. On install, get error:
> 
> The following errors occurred with your partitioning:
> sda must havea MSDOS disk label

Is it appropriate that you should need an msdos disklabel on the boot disk? I think that translates to "have you configured your system to boot through the BIOS?"

> 
> Only choice, really, and from there we get back to the "Which type of
> installation would you like" page, on which "replace existing linux systems" is
> firmly checked.    

I'm working on a change that will almost certainly NOT make F13, which will create the appropriate type of disklabel on the boot disk IFF you have selected "Use All Space".
Comment 37 Bug Zapper 2010-04-27 10:34:02 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 38 Rafael Ávila de Espíndola 2010-05-26 01:33:28 EDT
I managed to install F13. It is not nice, but it works:

 * Install as normal
 * In the rEfit menu, sync the partition tables
 * Boot the dvd in rescue mode
 * chroot
 * rpm -e grub
 * yum install grub2
 * grub2-config > /boot/grub2/grub.conf
 * grub2-install /dev/sda3 --force
 * cd /boot
 * rm -rf grub
 * ln -s grub2 grub

I am not sure if all those steps are necessary, but they worked for me.
Comment 39 Fabian Deutsch 2010-05-26 07:05:43 EDT
For years I'm a single-boot user. Is it still required to install rEFIt?

The above procedure seems awkward, why do we need to install grub2?
Comment 40 Rafael Ávila de Espíndola 2010-05-26 16:44:51 EDT
The above procedure was for keeping a dual boot system. I single boot might be simpler.

I needed to install grub2 because grub fails :-) I don't know exactly why, but both the regular install and running grub-install /dev/sda3 fails.
Comment 41 Chris Lumens 2010-05-28 13:12:59 EDT
*** Bug 597317 has been marked as a duplicate of this bug. ***
Comment 42 Jurgen Kramer 2010-05-28 13:47:30 EDT
My system is still dual boot (Mac OS X / F13) as well. I only need(ed) to sync partition tables with refit to make it work. Grub works just fine from /dev/sda3.
Comment 43 Rafael Ávila de Espíndola 2010-05-29 13:32:30 EDT
Maybe the issue is where /dev/sda3 starts? Mine starts at 1.5T.
Comment 44 Benjamin Kosnik 2010-06-07 21:45:43 EDT
I changed this From F11 to F13.

Is there a boot option to use grub2 instead of grub? That would be useful for testing #38, and for the grub2 transition.
Comment 45 Chris Lumens 2010-06-16 10:42:06 EDT
*** Bug 604488 has been marked as a duplicate of this bug. ***
Comment 46 Manuel Faux 2010-08-19 16:45:25 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 47 Benjamin Kosnik 2010-09-14 13:45:03 EDT
Updating. I have a successful dual-boot install on a mac mini with snow leopard 10.6/F13 x86_64, although this is kind of a workaround as I didn't do partitioning in linux.

Here's what I did:

1) wipe drive in os x. So, you have to use the internal drive as booting from an external drive (be it flash, usb, firewire) is dicey. So, go utitlities->Disk Utility and select drive to work on. You want a GUID partition for the mac side, and a second partition of type "Free Space" as partition two. Do it now, reboot.


2) in a linux live disk, clear out the MBR if necessary. This is symptomatic of past failed Fedora installs that installed the boot loader onto the MBR instead of the linux boot partition. Symptoms include refit finding too many linux partitions in the graphical boot, or truncated GRUB boots like GRU at boot time.

Verify this with refit Partition Inspector utility

http://refit.sourceforge.net/help/windows_boots_linux.html

if it says: MBR contents, GRUB then you need to do this:

dd if=/dev/zero of=/dev/sda bs=446 count=1

from
http://www.linuxquestions.org/questions/linux-software-2/using-linuxs-fdisk-to-erase-or-fix-a-mbr-300256/


3) in linux install, install on free space only, put boot loader on sda3 or whatever, not MBR. FYI /boot partition can be ext4. Looks like:

 1      20.5kB  210MB   210MB   fat32              boot, hidden
 2      210MB   40.1GB  39.9GB  hfs+         mac   hidden
 3      40.1GB  40.6GB  524MB   ext4               boot
 4      40.6GB  80.0GB  39.4GB                     lvm

4) restart, in refit menu sync MBR, restart. Select "Windows" and that will boot fedora. At this point I believe refit is optional.

tried this with f14 alpha x86_64 live, and f13 x86_64 dvd install, worked in both
Comment 48 Chris Lumens 2010-10-04 21:45:55 EDT
*** Bug 640133 has been marked as a duplicate of this bug. ***
Comment 49 Chris Lumens 2010-10-11 14:26:05 EDT
*** Bug 641531 has been marked as a duplicate of this bug. ***
Comment 50 Rafael Ávila de Espíndola 2010-11-08 00:58:49 EST
Very similar issue with f14. This time I was able to use the live cd in vesa mode, but still had to do the same steps as before:

* sync gpt/mbr
* install grub2
Comment 51 Michael Tiemann 2011-05-29 08:56:08 EDT
Somehow I managed to get F14 working on a MacBook Pro 2,1 with some, but not too much magic.  But F15 has me totally stumped.  I have tried both the methods of c38 (https://bugzilla.redhat.com/show_bug.cgi?id=503149#c38) and c47 (https://bugzilla.redhat.com/show_bug.cgi?id=503149#c47), and neither has worked for me.  Even getting to the point where I could boot to the installer from the DVD required the -no-emul-boot, but that's not Very Hard, as I was able to do it.

When I attempt to boot my freshly installed, refit-sync'd F15 setup (boot on sda3, lvm on sda4), I get to the grey refit penguin splash screen and that's as far as it goes.  I have tried everything I've ever done to make Fedora happy on this ancient MacBook Pro, and absolutely nothing is working.

Should I file a fresh bug report, or is this really part of the same chain of problems--that Anaconda is ultimately not presenting reasonable options for the user to choose?
Comment 52 Bug Zapper 2011-06-02 14:03:50 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 53 Jurgen Kramer 2011-06-02 14:30:34 EDT
I think we should keep this open as installing on/booting macs still has some issues.
Comment 54 Aaron Hamid 2011-06-02 19:00:33 EDT
I should say that I no longer have the macbook, so to be fair this is no longer relevant for me (although I still think it would be great to have Fedora running on these machines).
Comment 55 Fabian Deutsch 2011-10-13 07:33:54 EDT
(In reply to comment #53)
> I think we should keep this open as installing on/booting macs still has some
> issues.

Maybe those issues could be described more in detail in a fresh bug entry? This bug seems to be very general.
Comment 56 Chris Murphy 2011-10-14 22:23:08 EDT
The problem occurs when the user chooses an installation type that requires the GPT to be updated. Any addition  or subtraction of any partition to GPT causes an existing hybrid MBR to be blown away in favor of a protective MBR. And then I will guess that gptsync isn't being called to create an updated MBR so that the computer is then bootable.

I'm finding that Apple's CSM appears to expect three things exactly, for a partition to show up in the startup disk selection menu, revealed with option-key @ powerup/restart:

1. code in the first 440 bytes of the disk
2. hybrid MBR or full MBR (no GPT); i.e. not a protective MBR
3. the partition for booting marked as bootable in the MBR.

On a Macbook Pro 8,2 I just tried changing the hybrid MBR to protective MBR, and making that single partition entry, MBR hex EE, bootable. The result was that neither Mac OS nor Fedora boot volumes were displayed in the option key startup disk menu. Restoring the hybrid MBR with linux boot partition set as bootable in the MBR. 

(It may be Apple's EFI startup disk boot menu only looks for the boot flag being set on a partition other than MBR hex EE, I haven't tried setting some arbitrary non-bootable partition with the boot flag. I suspect it would be "good enough" for EFI to proceed with initiating the CSM, which then behaves just like BIOS - blindly reads the first 440 bytes, and at that point control is handed to Grub regardless of what boot flag is set. BUT I haven't tested this.)

The GPT "Legacy BIOS Boot" flag is apparently ignored by Apple's EFI startup disk boot menu, as such a disk with only protective MBR, but with the boot partition's attribute set to "Legacy BIOS Boot" in GPT does not apparently alter any behavior. Sad, because this would be a great way to avoid hybrid MBR, and at least in my imagination is expressly why that attribute exists.

Conclusion: Presently, whether installing Fedora 16 beta either with "Use Free Space" or "Use All Space" installation types (dual boot Mac OS + Fedora, or single boot Fedora only), the resulting installation is not  immediately bootable. It does not appear as an option in the Apple startup disk boot menu (option key). After creating the hybrid MBR, it appears as "Windows" (technically that "Windows" option is for Grub in this context, not a command to boot from a specific partition)

I found some related issues and put them in this bug report:
http://bugzilla.redhat.com/show_bug.cgi?id=744496
Comment 57 Chris Murphy 2011-10-14 22:36:28 EDT
Failed to complete a thought...
"Restoring the hybrid MBR with linux boot partition set as bootable in the MBR."

Doing this restored the dual boot ability from the Apple startup disk menu selector.

So the things I think need to be fixed, other than the LiveCD installing boot loader failure that occurs when there is a previous system (Mac OS in that case) since that already has its own bug ID:

a.) linux boot partitions need to be set to the correct GUID, presently they're getting an EFI Partition GUID instead of a linux system GUID, which means on Apple computers with a pre-existing Mac OS with users intending to create a dual boot computer, end up with *two* EFI Partitions on the same disk. (Mentioned in the above bug ID but is probably unrelated to that problem; and also doesn't affect bootability of linux or Mac OS.)

b.) Something needs to create an appropriate hybrid MBR post-install.

c.) Something needs to set, in that MBR, one of the partition's boot flag, post-install. It may not matter which as long as it's not the EFI Partition, I can vouch for setting the linux boot (mounting on /boot) as bootable in the MBR. That works. But I suspect any of the three partitions in the MBR could be flagged bootable.

Also, in all of my testing I am not using rEFIt, or gptsync. Only gdisk 0.7.2. And I only choose the boot disk from the built-in startup disk boot menu, accessed by holding the option key down at startup.
Comment 58 Chris Murphy 2011-10-15 01:13:27 EDT
Additional booting tests:

1. I do not think it's appropriate to assume the user has, or should have, rEFIt. The correct behavior should produce a bootable disk from the Apple startup disk menu (option key at startup). This will also work with rEFIt. 

2. On a MBP 4,1 with Lion and Fedora 16beta (total of 6 partitions) I found I can get two additional successful configurations to the one previously described:

a.) Instead of linux boot partition marked bootable, mark linux lvm bootable (yet it is not, there is no boot partition within that LVM).

b.) Instead of the linux boot partition and linux lvm partition separately listed in the MBR (with the remaining partitions in the protected MBR); place the linux boot partition also in the protected MBR, with the linux lvm (as the 2nd MBR partition) marked bootable.

And this is reproducible on a Macbook Pro 8,2 as well so it appears to be pretty consistent. All of this is different for EFI booting. So far I'm assuming CSM mode based booting.
Comment 59 Chris Murphy 2011-10-15 01:24:32 EDT
This might need a separate bug report but I'll stick it in here for now. Consistently I'm finding the partition type GUID is wrong in a number of cases:

The first ext4 partition listed in GPT (whether it's the 2nd partition entry or the 5th) is thus far always the GUID for "EFI System Partition" GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. This is definitely incorrect, it should be GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4 "Linux filesystem". The net result of this bug is that there are two EFI System Partitions on a dual boot system, one of which is the real EFI System partition, and the other is the partition mounting as /boot. Probably not a good idea, should be fixed.

Subsequent partitions either ext4, btrfs, or xfs have partition type GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Microsoft Windows basic data". This was done for a long time under MBR, using the same partition type hex code as Windows but linux filesystems have their own GUID which is 0FC63DAF-8483-4772-8E79-3D69D8477DE4. So it's a minor point, but ought to be fixed.

"BIOS Boot" has the correct partition type GUID.
"Linux LVM" partitions also have the correct partition type GUID.

Last, all of my comments apply to F16 beta, so the version for this bug should be changed to 16. Now that I've inundated everyone with multiple comments, I'll remove the needinfo flag and await comments/questions on next steps.
Comment 60 Chris Murphy 2011-10-16 13:04:48 EDT
http://lists.gnu.org/archive/html/bug-parted/2011-06/msg00045.html

If anaconda is using parted to create/modify partitions, I think this is what's occurring. Anaconda is incorrectly setting the 'boot' flag for /boot partitions, which then causes the partition type GUID to be set to "EFI System" partition.
Comment 61 Adam Williamson 2011-10-17 15:36:43 EDT
Chris, I think we're getting confused by volume and crossover between this report and https://bugzilla.redhat.com/show_bug.cgi?id=744496 .

Can you please separate out each individual issue you've found and file a new bug report, with a comprehensive description and recommended fix in a *single* description post, for each issue? I think that'll make it much easier for the anaconda team to fix the problems you've identified. Please link all the bugs from both this bug and 744496. Thanks!
Comment 62 Chris Murphy 2011-10-18 04:00:50 EDT
Linux boot GUID problem moved to Bug 746895.
Lack of MBR with boot flagged partition problem moved to Bug 746901.

This bug 503149 can be considered a duplicate of Bug 746901.
Comment 63 Adam Williamson 2011-10-18 14:48:43 EDT
is it a dupe of that bug _as this bug is initially reported_ - i.e. "Suggest that a feature is added to Anaconda to

1. allow the disk bootloader installer to install GRUB to a root partition, as
well as 
2. use the gptsync utility to handle MBR/GPT hybrid tables." ?
Comment 64 Adam Williamson 2011-12-07 12:53:12 EST
Now I understand this a bit better, yes, it is effectively a duplicate of that bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** This bug has been marked as a duplicate of bug 746901 ***

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