Bug 741056

Summary: F16 Beta RC2 fails to boot after DVD Installation
Product: [Fedora] Fedora Reporter: Andy Lawrence <dr.diesel>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: anaconda-maint-list, awilliam, cra, jonathan, redhat, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-13 19:39:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
parted.log
none
dmesg dump
none
anaconda.log
none
storage.log none

Description Andy Lawrence 2011-09-24 19:13:16 UTC
Description of problem:

After installation of DVD install, all defaults, whole disk installation.  Minimal install to help speed testing, same happened with Gnome.  System is a Thinkpad T520, SSD, BIOS set to attempt boot with both Legacy and UEFI.  I've tried by forcing both with no luck.

Please see attached log files.

Comment 1 Andy Lawrence 2011-09-24 19:13:39 UTC
Created attachment 524740 [details]
parted.log

Comment 2 Andy Lawrence 2011-09-24 19:14:01 UTC
Created attachment 524741 [details]
dmesg dump

Comment 3 Andy Lawrence 2011-09-24 19:14:24 UTC
Created attachment 524742 [details]
anaconda.log

Comment 4 Andy Lawrence 2011-09-24 19:26:08 UTC
Created attachment 524743 [details]
storage.log

Comment 5 Andy Lawrence 2011-09-24 19:34:16 UTC
Additional info:

F15 installed/worked normally.  This F16 install doesn't find any boot device, no grub fallback prompt etc.

Comment 6 Adam Williamson 2011-09-24 20:34:48 UTC
I can't see anything that's wrong there...it's a GPT-labelled disk, it has the BIOS boot partition, it has the 'boot' flag. storage.log shows it wrote a bootloader to /dev/sda, or at least seems to. so...I'm kinda lost as to why the BIOS would think it's not bootable.

Comment 7 Andy Lawrence 2011-09-24 20:45:47 UTC
When I boot to a live cd and list /boot, the directory is empty?

How do I go a grub2-install from a live cd?

Comment 8 Andy Lawrence 2011-09-24 21:05:58 UTC
Mmmmm, so I have another UEFI box with SSD, which boots just fine with F16.  I yanked it and installed in my T520 and it won't boot either, same exact problem.  I wonder if this is a BIOS bug on Lenovo's side?

Getting support from them is likely impossible....Is it possible to force grub1 for F16 during install?

Comment 9 Adam Williamson 2011-09-25 01:32:15 UTC
if /boot is empty that somehow seems worse than a BIOS issue of some kind, as /boot should contain the kernels. But I've no idea what's going wrong...

no, you can't really force grub :/ you can install f15 and yum update to f16, but that's about all.

Comment 10 Adam Williamson 2011-09-29 05:26:56 UTC
it was pointed out to me that there's a BIOS update for the t520 with this changelog:

"(Fix) Fixed an issue where the computer might not be booted from bootloader program."

so you might want to try that.

Comment 11 Charles R. Anderson 2011-09-29 08:24:22 UTC
I have a Lenovo ThinkPad T520 as well.  I tested installing to an UltraBay hard drive, using the F12 boot menu in order to boot from ATA HDD1 instead of the normal internal SSD.  I made the following observations:

1. Regular (non-EFI) install failed to boot from GPT (using whole disk install, when using F12 menu to select ATA HDD1).
2. EFI install (via efidisk.img written to USB) also failed to boot from GPT (when using F12 menu to select ATA HDD1).
3. Updating the BIOS from v1.29 to the latest Lenovo T520 v1.31 at first didn't appear to help with the above 2 issues (but may have--see below).
4. It didn't matter if I selected UEFI or Legacy, nor which boot order in the BIOS setup program.
5. A custom install to a pre-partitioned disk with a traditional DOS partition table boots fine.

I retried the boot by letting it boot up on its own (not using F12 Boot Menu to select ATA HDD1) and this time it booted the "Fedora" entry via EFI to the UltraBay disk.  Adam explained to me this is "normal" for EFI.  It puts a "Fedora" entry right into the BIOS boot order which shows up in the boot menu and boots fine when selecting it, or letting it boot automatically if you select UEFI first, then Legacy in the BIOS setup boot order.

You can see what is in the EFI Boot Menu (which is built into the BIOS, but modified by Anaconda) by running:

efibootmgr -v

So, if I had to guess what happened here is a combination of my unfamiliarity with how EFI works, perhaps the BIOS update did help matters, and perhaps right after the install powering down the system and then doing a fresh boot from full off (without interfering via F12) is what allowed it to work.  That and the fact that apparently EFI boot is required when using GPT partition tables on this hardware.

Final advice:

To confirm that you are actually booting in EFI mode, make sure you see the graphical GRUB 0.97 menu when booting the EFI installer and the final installed system, not the text-based SysLinux or GRUB2 menu.  The installer will also show graphical Tux Penguins across the top of the screen when booting in EFI mode.  The only way this worked for me is to write efidisk.img to a USB stick, or boot the DVD via a physical optical disc.  Using netinstall.iso written to a USB stick did not boot via EFI for me.

Comment 12 Andy Lawrence 2011-09-29 22:29:51 UTC
(In reply to comment #10)
> it was pointed out to me that there's a BIOS update for the t520 with this
> changelog:
> 
> "(Fix) Fixed an issue where the computer might not be booted from bootloader
> program."
> 
> so you might want to try that.

Thanks Adam.  My testing was done with the latest 1.31v which has the fixes mentioned above.

I was also not using F12 to pick my boot drive, it was just normal booting that didn't work.

Comment 13 Adam Williamson 2011-10-04 21:07:57 UTC
This could well be the same as https://bugzilla.redhat.com/show_bug.cgi?id=735733

can you try the workaround listed in https://bugzilla.redhat.com/show_bug.cgi?id=735733#c19 and see if that helps your system?

Comment 14 Adam Williamson 2011-10-13 19:39:00 UTC
let's just make this a dupe, I'm 99.9% sure it is.

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