Bug 735733 - system BIOS does not allow boot from GPT-labeled disk
Summary: system BIOS does not allow boot from GPT-labeled disk
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
: 741056 741120 751718 (view as bug list)
Depends On:
Blocks: F16Blocker, F16FinalBlocker
TreeView+ depends on / blocked
Reported: 2011-09-05 08:50 UTC by Jens Petersen
Modified: 2012-04-15 07:33 UTC (History)
17 users (show)

Fixed In Version: anaconda-16.22-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-20 04:04:03 UTC
Type: ---

Attachments (Terms of Use)
anaconda.log (14.42 KB, text/x-log)
2011-09-09 10:52 UTC, Jens Petersen
no flags Details
anaconda.program.log (128.23 KB, text/x-log)
2011-09-09 10:53 UTC, Jens Petersen
no flags Details
anaconda.storage.log (230.91 KB, text/x-log)
2011-09-09 10:53 UTC, Jens Petersen
no flags Details
device.map (107 bytes, text/plain)
2011-09-12 05:28 UTC, Jens Petersen
no flags Details
anaconda.log (14.66 KB, text/x-log)
2011-10-03 10:22 UTC, Jens Petersen
no flags Details
anaconda.program.log (201.19 KB, text/x-log)
2011-10-03 10:23 UTC, Jens Petersen
no flags Details
anaconda.storage.log (439.10 KB, text/x-log)
2011-10-03 10:25 UTC, Jens Petersen
no flags Details
device.map (107 bytes, application/octet-stream)
2011-10-03 10:27 UTC, Jens Petersen
no flags Details
dmidecode output from a Thinkpad X220 (14.38 KB, text/plain)
2011-10-13 20:25 UTC, Luke Macken
no flags Details
dmidecode output. (13.88 KB, text/x-log)
2011-10-13 21:28 UTC, Nick Cross
no flags Details
dmidecode (14.24 KB, text/x-log)
2011-10-13 23:56 UTC, Andy Lawrence
no flags Details
dmidecode (15.54 KB, text/plain)
2011-10-14 02:14 UTC, eric
no flags Details
dmidecode output for T420s (13.97 KB, application/octet-stream)
2011-10-14 02:24 UTC, Jens Petersen
no flags Details
dmidecode output for Thinkpad X120e (14.51 KB, application/octet-stream)
2011-10-14 05:35 UTC, jonathan
no flags Details

Description Jens Petersen 2011-09-05 08:50:03 UTC
Description of problem:
I am struggling to get F16 installs to boot on my Thinkpad T420s.
Both F16 Live and Net install fine but then rebooting and *nothing* happens.

More weird is if I remove the install HD and place it in another
older laptop it sees the GPT partition fine and shows the grub2 menu.
Is my laptop too new or what could be going wrong?
What information can I provide to debug this?
I guess I should start by attaching anaconda logs...

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1. install F16 Live or Net onto Thinkpad T420s
2. reboot
3. wait for Fedora to boot up
Actual results:
3. Fedora menu does not appear - machine fails to boot.

Expected results:
3. Fedora boot menu to appear and Fedora to boot up.

Additional info:
F15 installs and boots fine on T420s.
I have only tried x86_64 if that should matter.

Comment 1 Chris Lumens 2011-09-05 19:17:11 UTC
Yeah, logs would be a good start to get us going here.  They're in /var/log/anaconda/ post installation, or /tmp/anaconda.log, /tmp/syslog, and /tmp/program.log during installation.

Comment 2 Jens Petersen 2011-09-09 10:51:40 UTC
Ok 16.17-1 looks better, but I got a final popup message
saying something like "bootloader could not be setup
your system will not boot up".  Indeed there are grub2
error messages in the attached logs below.

Comment 3 Jens Petersen 2011-09-09 10:52:35 UTC
Created attachment 522299 [details]

Comment 4 Jens Petersen 2011-09-09 10:53:11 UTC
Created attachment 522300 [details]

Comment 5 Jens Petersen 2011-09-09 10:53:50 UTC
Created attachment 522301 [details]

Comment 6 Jens Petersen 2011-09-09 11:04:42 UTC
Ok the warning is "There was an error installing the bootloader.
The system may not be bootable." which turns out to be true.

Comment 7 David Lehman 2011-09-09 19:56:18 UTC
Can you attach /boot/grub2/device.map, please? If in rescue mode that'd be /mnt/sysimage/boot/grub2/device.map

Comment 8 Jens Petersen 2011-09-12 05:28:03 UTC
Created attachment 522647 [details]

Comment 9 Jens Petersen 2011-09-12 10:57:56 UTC
I suspect the new summary may be too simplified.

I can't boot F16 install on a new Lenovo Thinkpad T420s
but install boots fine on an old IBM Thinkpad X60.

I suspect this is related to grub2 and that T420s BIOS supports UEFI
(though I have disabled UEFI boot in BIOS settings).

Comment 10 David Lehman 2011-09-28 17:49:10 UTC
Jens, can you try with more recent F16 Beta RCs? This should be resolved in anaconda-16.19-1, which is in F16-Beta-RC3.

Comment 11 David Lehman 2011-09-28 17:51:07 UTC
At least part of the problem here seems to be that we're trying to install grub2 to the MBR of the USB (guessing here) device holding your install media. Obviously that's not sensible on anaconda's part.

Comment 12 Jens Petersen 2011-09-29 05:49:13 UTC
Sorry I meant to update earlier...
well it was still broken post Beta RC2 - I even tried
USB installing with overlaid anaconda-16.19 and
latest grubby FWIW.  I will try RC3 again but not
too optimistic.

As a data-point, still the only way I can get it to boot
is to first install F15 (Live) and then install F16 Live
over that - then it works.  Directly installing F16 never
seems to boot.

Is there any more information I can provide to help?

Comment 13 Jens Petersen 2011-09-29 07:16:28 UTC
Yeah, I just tried installing RC3 x86_64 Live and it still
just boots into PXE search.  (I chose "Use whole disk".)

Comment 14 Jens Petersen 2011-10-03 10:17:38 UTC
(In reply to comment #11)
> At least part of the problem here seems to be that we're trying to install
> grub2 to the MBR of the USB (guessing here) device holding your install media.
> Obviously that's not sensible on anaconda's part.

"Trying" I don't know - at least the USB still boots fine after
installation has completed so it is not being affected anyway.

Comment 15 Jens Petersen 2011-10-03 10:22:46 UTC
Created attachment 526013 [details]

Comment 16 Jens Petersen 2011-10-03 10:23:47 UTC
Created attachment 526014 [details]

Comment 17 Jens Petersen 2011-10-03 10:25:10 UTC
Created attachment 526015 [details]

Comment 18 Jens Petersen 2011-10-03 10:27:20 UTC
Created attachment 526016 [details]


Comment 19 David Lehman 2011-10-03 14:56:44 UTC
So you are no longer getting any errors about bootloader install?

It looks like anaconda is doing everything right and I see no evidence of grub2 complaining, eiher. I have heard that there may be some BIOSes that just cannot boot from a GPT-labeled disk. You apparently have one of these broken BIOSes. I have a patch that forces the use of MSDOS disklabels, which I will provide for you to try out. Just add the following to the boot command line:

  updates=http://dlehman.fedorapeople.org/updates-735733.0.img nogpt

  (don't forget the "nogpt" -- it's important)

Let me know how it goes.

Comment 20 Jens Petersen 2011-10-04 03:10:49 UTC
Thanks David - I will try your updates-735733.0.img soon.

I am still wondering though why installing F16 over an F15 image boots,
but not a fresh install of F16 using the whole HD?  The former seems
to be using GPT.

I just verified again:

1. I had to install F15 using the whole HD (after an F16 install)
   otherwise it wouldn't boot.
2. Then I installed F16 over the existing Linux partitions (the default)
   and it boots fine with grub2.
3. If instead I install F16 over the whole HD - it fails to boot.

Comment 21 Jens Petersen 2011-10-04 03:17:47 UTC
Ah I guess in that case it falls back to msdos partioning?

Comment 22 Jens Petersen 2011-10-04 03:18:42 UTC
I may try updating my BIOS later to see if that should help.

Comment 23 David Lehman 2011-10-04 03:29:18 UTC
F15 uses msdos disklabels, so that's what you had after installing it. F16 does not create a new disklabel unless you use the whole disk, which you didn't do. So that install worked because it was not using gpt. The third case fails to boot because it is creating a gpt disklabel. If you had chosen to use the whole disk when installing F16 on top of F15 you would have had another failure. The only thing about the F15 install that makes any difference is the msdos disklabel it leaves behind.

Comment 24 Jens Petersen 2011-10-04 06:52:09 UTC
Thanks for the explanation - finally it all makes sense.

>   updates=http://dlehman.fedorapeople.org/updates-735733.0.img nogpt

Yes I tested this via Live actually: booted passing nogpt to kernel,
and gaves updates= arg to liveinst and it worked!
So this looks like a good workaround for modern machine like mine
with a broken BIOS for GPT.

Comment 25 Jens Petersen 2011-10-04 08:48:47 UTC
Searching the web didn't give too much detailed information but
http://forums.freebsd.org/showthread.php?t=26304 suggests
that even the latest T420s BIOS doesn't fix this problem.

Comment 26 Adam Williamson 2011-10-04 21:09:40 UTC
I think https://bugzilla.redhat.com/show_bug.cgi?id=741056 may be another case of this bug (indicated the T510 is also screwed).

Doesn't RH have a moderately functional relationship with Lenovo? Couldn't we lean on them to fix this with a BIOS update at least?

Comment 27 Andy Lawrence 2011-10-04 22:10:42 UTC
Note, bug 741056 is from a T520, not a T510, but I'd guess the same problem.  I am willing to test said BIOS if you could get Lenovo to play along.

I also have a spare 2.5" SSD on the way, I'll attempt comment 19 when it arrives.

Comment 28 Jens Petersen 2011-10-05 03:46:27 UTC
Ok, just chiming in with the EFI comments in bug 741056:

I just managed to do an EFI install of F16 Beta with efidisk.img
from a USB stick and (dodging a couple of repo time issues in anaconda)
it successfully boots into a GPT install of F16
via UEFI, without updating my BIOS.

Anyway it might be good to add a "Use GPT" checkbox in anaconda
(under the LVM, encryption, etc, choices) maybe with a tooltip explanation,
rather than people having to work out the nogpt kernel bootline workaround?

I hope someone at Red Hat could also report this issue directly to Lenovo.

Comment 29 Adam Williamson 2011-10-05 05:12:53 UTC
we don't generally include 'workaround' options like that. the LVM and encryption checkboxes aren't workarounds, exactly, but features. LVM is a checkbox now kinda because we're expecting it to be unnecessary with BTRFS in future. A GPT checkbox would be pretty unclear to a lot of people.

current plan is either to have a whitelist, if anyone feels like writing one, or document the nogpt parameter in relnotes / common bugs.

Comment 30 jonathan 2011-10-06 07:35:36 UTC
Just wanted to note that the Thinkpad x120e is also affected by this problem. A normal install attempt with the Fedora 16 Beta install DVD resulted in an unbootable system. Trying again with the workaround from comment 19 worked just fine.

Comment 31 Adam Williamson 2011-10-12 00:31:27 UTC
Another affected system:


there's a link there to an interesting page:


which documents some known problematic bios/gpt interaction cases. The first one looks like it might be what's affecting us here. Does someone want to try Rod's workaround #1?

Comment 32 Nick Cross 2011-10-12 10:25:55 UTC
Found some other cross-reference information for ThinkPad T420s from around the net (I have the same problem with a brand new 420).


Comment 33 Adam Williamson 2011-10-12 18:04:02 UTC
Should we have anaconda do what Rod recommends as a first workaround - "mark the EFI GPT protective partition entry in the MBR as active/bootable" - by default when formatting a disk with GPT disklabel?

Comment 34 Adam Williamson 2011-10-13 19:39:00 UTC
*** Bug 741056 has been marked as a duplicate of this bug. ***

Comment 35 Adam Williamson 2011-10-13 19:39:51 UTC
Can those affected by this bug please provide the output of 'dmidecode' run as root on the affected system? We need to be able to identify known affected systems more precisely than just by the model number. thanks!

It would also really help if someone can try the workaround mentioned in comment #33 on an affected system and see if it helps.

Comment 36 Andy Lawrence 2011-10-13 20:15:21 UTC
Adam, I've been gone but plan to test this weekend.  Will report back.

Comment 37 Luke Macken 2011-10-13 20:25:55 UTC
Created attachment 528097 [details]
dmidecode output from a Thinkpad X220

Comment 38 Nick Cross 2011-10-13 21:28:09 UTC
Created attachment 528107 [details]
dmidecode output.

Output from a Thinkpad T420S

Comment 39 Andy Lawrence 2011-10-13 23:56:26 UTC
Created attachment 528126 [details]

Comment 40 Andy Lawrence 2011-10-13 23:56:54 UTC
^^ Sorry, for a T520.

Comment 41 eric 2011-10-14 02:14:30 UTC
Created attachment 528138 [details]

ThinkPad W520

Comment 42 Jens Petersen 2011-10-14 02:24:18 UTC
Created attachment 528140 [details]
dmidecode output for T420s

Pretty similar to Nick's I guess, but older BIOS and product version numbers
for comparison.

Comment 43 jonathan 2011-10-14 05:35:34 UTC
Created attachment 528154 [details]
dmidecode output for Thinkpad X120e

Here's the dmidecode output for the Thinkpad X120e

Comment 44 Pasi Karkkainen 2011-10-15 17:31:05 UTC
Hmm.. is support for "nogpt" boot option supposed to be already in F16 final TC1? 
I just tried TC1, and "nogpt" doesn't seem to help..

Comment 45 Pasi Karkkainen 2011-10-16 11:52:40 UTC
F16 final TC1 seems to be using Anaconda 16.21.

I tried two things with F16 final TC1:

- I started installation with the "nogpt" boot option and I accepted the default partitioning layout. After installation I checked the disk, and there was a GPT partition table and the "biosboot" (bios_grub) partition created.

- I started installation with the "nogpt" boot option, but I did manual partitioning in the hopes of getting the old MSDOS partition table. I created first partition as /boot (ext3), and the second partition as LVM PV. Root filesystem (ext4) and swap were created as LVM volumes. In the end of partitioning I got an error:

Partitioning Errors
The partitioning scheme you requested caused the following critical errors.
you have not created a bootloader stage1 target device.
You must correct these errors before you continue your installation of Fedora.

So it seems it's still not possible to create an old-style MSDOS partition table..

Comment 46 Andy Lawrence 2011-10-16 19:13:13 UTC
(In reply to comment #35)
> It would also really help if someone can try the workaround mentioned in
> comment #33 on an affected system and see if it helps.

I installed a spare WD spinning HD and installed F16 Alpha RC5 (cause the TC1 64 bit ISOs are not yet available) and it booted fine, without the work-a-round and without using the nogpt option?  Can't explain it.

When the TC1 x64 ISOs arrive I will blast by SSD and see what happens.  This setup will be the same as Bug 741056.

Comment 47 Pádraig Brady 2011-10-17 01:30:34 UTC
No luck with "nogpt" option added to F16 TC1 x86_64 live iso on a Lenovo T520, with BIOS 1.29

Comment 48 Pádraig Brady 2011-10-17 01:41:50 UTC
Rod's first workaround described in comment 33 does not help here

Comment 49 Jens Petersen 2011-10-17 05:44:19 UTC
(I /think/ TC1 is broken in other ways, but) note you can also install
from a Live USB using EFI, if you create your live usb stick with the --efi
option to livecd-iso-to-disk.

(A working nogpt option would be nice though.
Also slightly annoying to have to reformat USB to
an EFI partitioning to do an EFI install.)

Comment 50 Nick Cross 2011-10-17 07:58:51 UTC
For what its worth I got the system running by using the workaround suggested in comment 12 - install F15 first to get the MSDOS based disk labels and drop F16 into those partitions.

Comment 51 Adam Williamson 2011-10-17 16:36:31 UTC
I think the 'nogpt' patch missed tc1 as dlehman was on vacation last week. You'll still need to use the updates.img from comment #19, if it works against TC1.

Comment 52 David Lehman 2011-10-17 18:37:54 UTC
This should either go on the common bugs page or in the release notes -- probably both.

Comment 53 Andy Lawrence 2011-10-17 19:12:33 UTC
David, did the nogpt patch make it into the just released 64bit installs?

The ones here:



Comment 54 Adam Williamson 2011-10-17 20:45:24 UTC
Andy: no. See comment #51.

Comment 55 Fedora Update System 2011-10-19 18:43:58 UTC
anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16.

Comment 56 Andy Lawrence 2011-10-19 20:42:38 UTC
Any update on how anaconda is fixing this issue?

Comment 57 David Lehman 2011-10-19 21:09:20 UTC
(In reply to comment #56)
> Any update on how anaconda is fixing this issue?

You mean how is anaconda going to fix your broken BIOS? That we cannot do. However, the nogpt patch will be in the next released fedora 16 trees/isos, in anaconda-16.22-1.

Comment 58 Andy Lawrence 2011-10-19 21:13:03 UTC
Yeah, that's what I was looking for, your the man thanks!

Comment 59 Adam Williamson 2011-10-19 21:17:17 UTC
we _could_ also simply blacklist all lenovos back to using msdos, but that's still being discussed.

Comment 60 Fedora Update System 2011-10-20 02:25:37 UTC
Package anaconda-16.22-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-16.22-1.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 61 Fedora Update System 2011-10-20 04:04:03 UTC
anaconda-16.22-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 62 Pasi Karkkainen 2011-10-22 13:11:19 UTC
I can confirm Fedora 16 Final TC2 x64 supports "nogpt" boot option now and actually creates MSDOS partition table! Thanks!

Comment 63 Adam Williamson 2011-10-24 15:16:45 UTC
*** Bug 741120 has been marked as a duplicate of this bug. ***

Comment 64 Bernard Ladenthin 2011-11-07 11:20:59 UTC
*** Bug 751718 has been marked as a duplicate of this bug. ***

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