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): anaconda-16.16-1.fc16 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.
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.
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.
Created attachment 522299 [details] anaconda.log
Created attachment 522300 [details] anaconda.program.log
Created attachment 522301 [details] anaconda.storage.log
Ok the warning is "There was an error installing the bootloader. The system may not be bootable." which turns out to be true.
Can you attach /boot/grub2/device.map, please? If in rescue mode that'd be /mnt/sysimage/boot/grub2/device.map
Created attachment 522647 [details] device.map
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).
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.
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.
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?
Yeah, I just tried installing RC3 x86_64 Live and it still just boots into PXE search. (I chose "Use whole disk".)
(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.
Created attachment 526013 [details] anaconda.log
Created attachment 526014 [details] anaconda.program.log
Created attachment 526015 [details] anaconda.storage.log
Created attachment 526016 [details] device.map unchanged
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.
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.
Ah I guess in that case it falls back to msdos partioning?
I may try updating my BIOS later to see if that should help.
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.
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.
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.
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?
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.
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.
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.
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.
Another affected system: http://forums.fedoraforum.org/showthread.php?t=270675 there's a link there to an interesting page: http://www.rodsbooks.com/gdisk/bios.html 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?
Found some other cross-reference information for ThinkPad T420s from around the net (I have the same problem with a brand new 420). http://forums.freebsd.org/showthread.php?t=26304 http://forum.thinkpads.com/viewtopic.php?f=9&t=98078
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?
*** Bug 741056 has been marked as a duplicate of this bug. ***
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.
Adam, I've been gone but plan to test this weekend. Will report back.
Created attachment 528097 [details] dmidecode output from a Thinkpad X220
Created attachment 528107 [details] dmidecode output. Output from a Thinkpad T420S
Created attachment 528126 [details] dmidecode
^^ Sorry, for a T520.
Created attachment 528138 [details] dmidecode ThinkPad W520
Created attachment 528140 [details] dmidecode output for T420s Pretty similar to Nick's I guess, but older BIOS and product version numbers for comparison.
Created attachment 528154 [details] dmidecode output for Thinkpad X120e Here's the dmidecode output for the Thinkpad X120e
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..
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..
(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.
No luck with "nogpt" option added to F16 TC1 x86_64 live iso on a Lenovo T520, with BIOS 1.29
Rod's first workaround described in comment 33 does not help here
(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.)
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.
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.
This should either go on the common bugs page or in the release notes -- probably both.
David, did the nogpt patch make it into the just released 64bit installs? The ones here: http://dl.fedoraproject.org/pub/alt/stage/16.TC1/Fedora/x86_64/iso/ Thanks
Andy: no. See comment #51.
anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.22-1.fc16
Any update on how anaconda is fixing this issue?
(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.
Yeah, that's what I was looking for, your the man thanks!
we _could_ also simply blacklist all lenovos back to using msdos, but that's still being discussed.
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: https://admin.fedoraproject.org/updates/FEDORA-2011-14624 then log in and leave karma (feedback).
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.
I can confirm Fedora 16 Final TC2 x64 supports "nogpt" boot option now and actually creates MSDOS partition table! Thanks!
*** Bug 741120 has been marked as a duplicate of this bug. ***
*** Bug 751718 has been marked as a duplicate of this bug. ***