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.
Created attachment 524740 [details]
Created attachment 524741 [details]
Created attachment 524742 [details]
Created attachment 524743 [details]
F15 installed/worked normally. This F16 install doesn't find any boot device, no grub fallback prompt etc.
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.
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?
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?
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.
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.
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:
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.
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.
(In reply to comment #10)
> it was pointed out to me that there's a BIOS update for the t520 with this
> "(Fix) Fixed an issue where the computer might not be booted from bootloader
> 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.
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?
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 ***