Bug 744496

Created attachment 527061 [details]
anaconda log

Error installing the bootloader message occurred at 19:03ish in this log. At that time the only message recorded is:
19:03:00,106 ERR anaconda: would have run ['--quiet', '--nostart', '-f', '--service=ssh']

Created attachment 527062 [details]
messages log

At the time of the error installing bootloader message, these suspicious items were recorded:

First:
Oct  8 21:02:56 localhost program: grubby fatal error: unable to find a suitable template

Second (actual writing of bootloader)
Oct  8 21:03:00 localhost program: Running... grub2-set-default Fedora Linux, with Linux 3.1.0-0.rc6.git0.3.fc16.x86_64
Oct  8 21:03:00 localhost program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg
Oct  8 19:03:01 localhost dbus-daemon[995]: Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0x1376050> ignored
Oct  8 21:03:02 localhost program: Generating grub.cfg ...
Oct  8 21:03:02 localhost program: cat: /boot/grub2/video.lst: No such file or directory

Third (many entries including these):
Oct  8 21:03:05 localhost kernel: [ 1178.449285] attempt to access beyond end of device
Oct  8 21:03:05 localhost kernel: [ 1178.449292] sda4: rw=2048, want=57835, limit=2048
[repeating]

Oct  8 21:03:05 localhost kernel: [ 1178.449783] attempt to access beyond end of device
Oct  8 21:03:05 localhost kernel: [ 1178.449785] sda4: rw=0, want=57853, limit=2048
Oct  8 21:03:05 localhost kernel: [ 1178.449787] FAT-fs (sda4): Directory bread(block 57852) failed
[repeating]

sda4 is the small partition flagged as bios_grub.

When I redo this with a blank GPT, and use the "Use All Space" option, and reinstall, I end up with the 1st and 2nd errors listed in comment 2, but none of the third series of errors (which consume quite a bit of space in the posted messages files).

It seems the partition code is set incorrectly by the installer for the 500MB ext4 boot partition no matter whether I use the Use All Space or Use Free Space option. It is set to EF00, according to gdisk, which is EFI System, GUID code C12A7328-F81F-11D2-BA4B-00A0C93EC93B. It seems that it should be set to 8300, Linux filesystem, GUID code 0FC63DAF-8483-4772-8E79-3D69D8477DE4.

Presently, the installer using "Use Free Space" is causing two EFI System partitions to exist on the disk simultaneously.

If I change the partition code for sda2 (the 500MB ext4 boot partition) from EF00 to 8300, it makes no difference, the computer is still not bootable.

If I change the protective MBR to hybrid MBR, no change, computer is still not bootable.

***If I set the 500MB ext4 boot partition boot flag in the MBR to "bootable", computer is now bootable.***

I think possibly Apple's EFI may only present a disk to the CSM for BIOS boot if it detects both MBR and a boot flagged partition.

Consolidation of issues in this bug report:

1. When starting from a blank disk, the installer consistently makes a GPT only disk with the 500MB ext4 /boot partition set to type EF00 instead of 8300. This clearly seems like a bug.

2. "error installing bootloader message" when there is a pre-existing Mac OS installation, and using "Use Free Space" to install Fedora 16 beta. Error does not occur when starting with a blank disk. This also seems like a bug.

3. In any case (Fedora only or dual OS), at least this particular Apple model (Macbook Pro 4,1), seems to require an MBR-only or hybrid MBR (not protective MBR) with the MBR boot flag set for the 500MB ext4 linux boot partition. Using a GPT-only disk with the linux boot partition set to GPT attribute "Legacy BIOS boot" is insufficient, the resulting disk is still not bootable.

I just downloaded Fedora-16-Beta-x86_64-DVD.iso and issue 2 is not reproducible (with pre-existing Mac OS installation). 

Issues 1 and 3 are still present. And if I use the workaround mentioned above: change linux boot from EF00 to 8300, change protective MBR to hybrid MBR*, set boot flag in MBR for linux boot partition - I now have a dual boot machine. By holding down option at start, Fedora 16 is booted via the "Windows" disk icon (actually first drops me into GRUB2's menu as expected).

* specifically, starting with the same six partitions in Description, and using gdisk 0.7.2, the three GPT partitions added to the hybrid MBR are 4, 5, and 6. Thus MBR partition 1 is the GPT itself + GPT partitions 1, 2, and 3. MBR 2, 3, 4 are GPT 4, 5, 6 respectively. And MBR 3's boot flag is set.

Please attach the install logs from /tmp/*log (or from /var/log/anaconda/*log after the install).

As noted in one of your other bugs the live media currently isn't EFI capable yet.

If you boot it in CSM mode it is going to treat it like a BIOS system and a variety of things won't be setup correctly (eg. /boot/efi and efibootmgr won't be run).

When you installed using the DVD did you boot in CSM or EFI mode?

Created attachment 527293 [details]
anacondalog from LiveCD /tmp post install

Created attachment 527294 [details]
ifcfglog from LiveCD /tmp post install

Created attachment 527295 [details]
programlog from LiveCD /tmp post install

Created attachment 527296 [details]
storagelog from LiveCD /tmp post install

(In reply to comment #7)
Four logs found postinstall in /tmp while still booted from LiveCD. Steps to reproduce as listed 1-6 in Description.

For LiveCD and full DVD boot it's CSM* (choosing the Windows disc icon from the option key startup).

 I am only doing CSM boot on this hardware because its EFI and nouveau conflict preventing X from starting (have discussed with Ben Skeggs, this model and many others are effectively CSM only for non-Mac OS booting).

My expectations are the same as for F13, F14, and F15. The big difference in F16 is that for Apple hardware, Fedora (single OS or dual boot OS) is non-bootable after installation because there is no hybrid MBR after installation. Even if it started with a hybrid MBR, if the installer makes any changes to partitioning it appears to blow away the hybrid MBR in favor of a protective MBR. So while Apple hardware will continue to boot Mac OS after installing Fedora, in no case will it boot Fedora without manual creation of a hybrid MBR. And that's new with F16 on hardware that previously was bootable right after Fedora installed.

I don't do Windows, but my understanding is Windows on BIOS hardware can optionally use GPT for secondary disks. But depends on MBR for the boot disk. So if the Fedora 16 installer is blowing away full or hybrid MBRs in favor of GPT (plus protective MBR) I can see how this might cause dual boot problems for Windows users as well. The perversion that is hybrid MBR is something that some systems apparently aren't going to be able to live without.

Please let me know if I should file a separate bug report for the incorrect partition type GUID being used for the linux boot partition (/boot). Installer is presently setting it to EFI System GUID instead of a Linux filesystem GUID. And if so what component and who to cc.

I can confirm this also affects MacBook5,2. Using both, 32-bit and 64-bit, liveCD. I'm currently unable to get a working Fedora on it. Hope this gets fixed in time before release.

>(In reply to comment #14)

Let's see if I've got this figured out or not. Please boot from the Live CD, in Terminal use "su" to become root, and "yum install gdisk" then "gdisk -l /dev/xxx" for the disk and report the table information. Also "fdisk -l /dev/xxx" for the same disk and report that table information as well. Ideally the full table (device, start, end, ID/code), minus the header.

>(In reply to comment #14)
And just to confirm, you have a pre-existing Mac OS X system on the MBP, and you've installed Fedora 16beta, and you got the "error installing the bootloader" message at the end of your installation?

(In reply to comment #15)
> >(In reply to comment #14)
> 
> Let's see if I've got this figured out or not. Please boot from the Live CD, in
> Terminal use "su" to become root, and "yum install gdisk" then "gdisk -l
> /dev/xxx" for the disk and report the table information. Also "fdisk -l
> /dev/xxx" for the same disk and report that table information as well. Ideally
> the full table (device, start, end, ID/code), minus the header.


[root@localhost liveuser]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 4DDBCF67-5BEE-4937-B1D6-10AF14322DAA
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2349 sectors (1.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  
   2            4096         1028095   500.0 MiB   EF00  ext4
   3         1028096       488396799   232.4 GiB   8E00  


[root@localhost liveuser]# fdisk -l /dev/sda

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   488397167   244198583+  ee  GPT

(In reply to comment #16)

I have tried both ways, with Mac OS X installed, and formatting the whole thing and installing Fedora only. As you can see the HD info currently shows the later option.

(In reply to comment #18)
OK so when you had Mac OS on the disk also, and you installed Fedora 16 as a 2nd option, did you get the "error installing the bootloader" error message?

I'll tell you what, let's leave this bug for the "error installing bootloader" problem. I'll leave it up to the devs if they would find it helpful if you can reproduce (or not) the exact steps in the Description post (very top).

In the meantime, if you could combined comments 14 and 17, and post to:
https://bugzilla.redhat.com/show_bug.cgi?id=503149

I will post a gdisk sequence that should get your current installation booting Fedora.

(In reply to comment #19)
That's correct.

I'm currently installing Mac OS X again and will try again. Ideally I would like to dualboot, I formatted the disk before to see if at least worked that way. I'll post gdisk info with the bootcamp setup in a sec.

Oh, and no, I'm not using Fedora 16 Beta but yesterday's nightly build.

(In reply to comment #17)
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048            4095   1024.0 KiB  EF02  
>    2            4096         1028095   500.0 MiB   EF00  ext4
>    3         1028096       488396799   232.4 GiB   8E00 

Just want to point out to anaconda devs that gdisk's info command will report #2 partition type GUID as C12A7328-F81F-11D2-BA4B-00A0C93EC93B which is for "EFI System." If anaconda uses parted for GPT modifications, I surmise that anaconda is incorrectly having parted set the 'boot' flag for this partition. Parted translates the 'boot' flag for GPT disks into the GUID for "EFI System."

A separate bug with parted, is that without the 'boot' flag set, the partition type GUID is set to EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Microsoft basic data" which is also incorrect, but at least has some historical precedent from the MBR world where this was done, and that habit has apparently carried over to GPT. I'll look for a bug report on this and if none I'll file it separately.

Reproduced the issue on MacBook5,2. At the end of the installation I got this error "There was an error installing the bootloader.  The system may not be bootable."

gdisk/fdisk output:

[root@localhost liveuser]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 55C82901-E1FF-4A1A-A2EF-C06ACDF33132
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 8-sector boundaries
Total free space is 2349 sectors (1.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       243679271   116.0 GiB   AF00  Untitled 1
   3       243681280       243683327   1024.0 KiB  EF02  
   4       243683328       244707327   500.0 MiB   EF00  ext4
   5       244707328       488396799   116.2 GiB   8E00  


[root@localhost liveuser]# fdisk -l /dev/sda

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   488397167   244198583+  ee  GPT

(In reply to comment #23)
See comment 7 and post the logs if you like. I'm not sure if they're needed or if the ones I submitted are adequate.

To fix this so you can dual boot requires multiple steps because not only is the MBR incorrect to get Apple hardware to boot into grub, but grub2 probably didn't correctly install. I can help fix your problem since I've already done it but I'm reluctant to clutter this bug report with something that's unlikely to help the devs further on this problem. I suggest posting the full dual boot problem and failures and partition maps to fedoraforum.org either in Rawhide or Mac forums, and then private email me the post URL and I'll respond with the write up so others can benefit also.

added a chunk to Summary which I hope accurately describes the problem, Chris?

proposing as a blocker so we can kick it around, specifically the implications for Win7 dual-boot scenarios.

(In reply to comment #25)
> added a chunk to Summary which I hope accurately describes the problem, Chris?

Well if anaconda uses parted for modifying partitions, then it's actually parted that's blowing away the hybrid MBR. Dropping the hybrid MBR isn't necessarily a bad thing, it's just that if it's really needed (question 1 which is hardware specific), it needs to be replaced with something sensible.

Does anaconda know make/model of the target system? It might make it possible to create a heuristic that does the right thing as we are in a nasty transitory arena with BIOS, EFI and CSMs right now. I would not be surprised if other Intel EFI (non-UEFI) systems or those with CSMs, maybe even certain BIOS implementations, want to see an MBR with at least one partition flagged as bootable.

Chris: can you please do what I asked in 503149 and split out all these different issues you've reported into separate bugs, so we can get past the confusion and noise in these two overlapping reports? that'd make it easier to follow up on things. thanks.

(In reply to comment #12)
> I don't do Windows, but my understanding is Windows on BIOS hardware can
> optionally use GPT for secondary disks. But depends on MBR for the boot disk....

With a system that already has Windows only on it, and Fedora is going to be an additional system, the disk is almost certainly MBR only. No GPT. And I do not think anaconda or parted will change the disk from MBR to GPT. I am pretty sure it keeps the MBR, in which case, there is no issue dual booting Windows. Further, I think there'd be overflowing forums and bug reports if there were.

Issue arrises only if the user wants/expects (historically?) to install Fedora first, and then Windows second. Windows installer would see a GPT disk and refuse to install, whereas with F15 and older, Windows installer would see an MBR disk and allow Windows to be installed. Is this ever an expected or desirable installation order? I would think not just because the Windows installer will blow away Grub stage 1 (Grub2 boot.img) leaving the end user having to fix this situation with a rescue disk, and reinstall grub themselves.

Should I refile bug 744496 as a new bug? 

There is really only one bug here as originally reported which is the ""There was an error installing the bootloader. The system may not be bootable." message, when installing Fedora on a disk with a pre-existing (foreign) operating system.

you mentioned three apparently separate issues in comment #5.

Yeah I will split out 1 and 3 into separate reports as they relate to bug 503149. Comment #5, bug 2 is the primary bug for bug 744496. So is it cleaner to open a new bug with just that specific issue, and mark this bug 744496 as a duplicate?

I think so, yes, this has gotten so long and confused.

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

*** Bug 836896 has been marked as a duplicate of this bug. ***