Description of problem: After performing a clean normal install onto both standard HDD and USB flash drive, Fedora 16 fails to boot in both cases on the HP ProBook 4430s. Then restored a clean Fedora 15 image onto the USB flash drive and that boots normally. After upgrading the Fedora 15 install to Fedora 16, without modifying the boot loader, it again fails to boot on either the HP ProBook or the Thinkpad. On the HP ProBook, the Fedora 16 fails with standard boot or using the UEFI option. Version-Release number of selected component (if applicable): 16 How reproducible: Boot attempt from HDD or USB. Steps to Reproduce: 1. Install or upgrade to Fedora 16. 2. Reboot Actual results: Infinite loop back to BIOS, in the case of clean Fedora 16 install on HDD. Missing file error message in the case of Fedora 16 install on USB. Expected results: Normal boot. Additional info: All versions of Fedora have booted normally on these systems. This is the first Fedora release that has failed to boot. On the HP ProBook, the Fedora 16 fails with standard boot or using the UEFI option. Strongly suspect the new GPT format. (?)
Fix component.
What happens if you install with 'nogpt'?
Using the 'nogpt' argument at the install command line does create an 'msdos' partition table and F16 boots successfully on the HP ProBook 4430s. I assume that it will boot on the Thinkpad as well. Installed using a mounted DVD ISO, the following command line and selected the standard (non-test) updates at the install GUI: > vmlinuz initrd=initrd.img repo=ftp://192.168.1.20/pub/inst/Disk1 nogpt Recommend setting msdos as the default partition table format or giving an option on the disk formatting screen until the BIOS developers catch up. The average user should not have to deal with the installer command line.
I am having this issue with F16 on a Lenovo Thinkpad 520, which does have a GPT/EFI disk. Tried nogpt option as well as making the GPT device bootable with fdisk (both suggested at http://fedoraproject.org/wiki/Common_F16_bugs#Some_systems.2C_particularly_Apple_Macs.2C_cannot_boot_GPT-labelled_disks) but it did not work. Basically, the Anaconda install goes through fine without a single hickup, then the system can't boot from HDD, returning to the boot order screen to pick another device to boot from. If I put the LiveUSB back in (which is how I had installed it), it goes back into the install process and the STDOUT log displayed upon the boot and before the new install indicates that some g_hash_table != NULL assertion is failing, which i guess means that it is NULL. i have no clue what this means cause i didn't know how to pause the process at that stage to examine the STDOUT.
also, a huge thread on Fedora i initiated about this and going now into 72 hrs: http://forums.fedoraforum.org/showthread.php?p=1548003#post1548003 thanks
another related thread: https://bugzilla.redhat.com/show_bug.cgi?id=752063
On Thinkpads msdos should be used automatically. Please attach the logs from /tmp/*log of the failed install to this bug as individual plain/text attachments so we can get a look at what's going on.
thanks, Brian how do i access /tmp/log before the OS is installed? do i just go into the shell from Anaconda by hitting ctrl-alt-F2 like i did to use fdisk and then ctrl-F6 to go back to GUI installer? thanks
Yes. The best time is after the install looks like it finished, but before rebooting.
thanks, Brian. i am busy with something else right now, will get back this evening. your help is appreciated
I am having the same problem on a Samsung NP-RF11-A02DX. Strange thing is when the computer posts there is a key you can press (F4) That would normally boot the Samsung recovery partition. If I press this then F16 Boots as expected. If I don't press this then I get boot errors and no Grub at all. I have also tried UEFI Enabled and Disabled. I am Just trying the nogpt option to see if that works as it should.
We don't do gpt by default any more with F17 so this problem should "go away". We can't really fix the hardware platform.