Hide Forgot
Created attachment 548317 [details] Detailed description of the install with references to other attached files. Description of problem: Fedora 16 release version was installed on the 2nd (empty) fixed disk of a Dell M6600 laptop. The install was performed using an error free ISO image of the Fedora 16 x86_64 Install DVD that was stored on the 1st (Windows 7) fixed disk. The DVD was used to boot to the stored image file. At the end of the install when the REBOOT button is "clicked", the display immediately goes dark and the machine hangs. After boot: linux askmethod noselinux nogpt is invoked, 3 (white on black) messages are displayed before reaching the 1st blue background (select a language) screen. (See attached file early-msgs.txt.) The Standard Storage Device, Custom, NoLVM installation proceeds with no error message being displayed at any time. I will try to attach a number of files to this bug the 1st one being f16install-details.txt. This file provided details of the why, when, how; pertaining to the other attached files. Version-Release number of selected component (if applicable): Fedora 16 Release x86_64 How reproducible: Very. Same install method used > 2 times with same result. Steps to Reproduce: 1. At boot prompt enter: boot: linux askmethod noselinux nogpt 2. Perform the install. 3. When installation has finished "click" on REBOOT button. Actual results: Display immediately goes dark and the machine hangs. Expected results: Machine should reboot to Fedora 16 Additional info: This is the first bug I have reported. Am not sure how easy it is to attach multiple files. Hopefully I will be able to.
Created attachment 548318 [details] File /mnt/sysimage/root/install.log 2nd and 3rd to last lines refer to "grubby" errors.
Created attachment 548319 [details] File /tmp/anaconda.log File /tmp/anaconda.log obtained before trying to reboot.
Created attachment 548320 [details] /tmp/program.log File /tmp/program.log obtained before trying to reboot.
Created attachment 548321 [details] File /tmp/storage.log File /tmp/storage.log obtained before trying to reboot.
Created attachment 548322 [details] Contains the first 3 messages produced by the installation program. I am not sure if these messages are relevant.
Created attachment 548323 [details] Output of grub2-install invocation.
Created attachment 548324 [details] Output of grub2-install --recheck invocation.
Created attachment 548325 [details] Output of grub2-probe invocation.
Created attachment 548326 [details] Rescue mode messages displayed before the system hung after reboot.
Created attachment 548424 [details] File SystemSummary.pdf contains basic laptop specs generated from Windows 7.
A few notes, just for your information: 1. If you're going to choose custom partitioning you can just do that straight away. None of the other settings on that screen have any effect whatsoever on custom partitioning layouts. 2. A BIOS Boot partition is only needed on disks that use the GPT or GUID partition table. If your disk contains extended or logical partitions it is NOT using the GPT/GUID partition table, so you don't need the BIOS Boot partition. 3. The grubby errors in install.log are expected, and do not indicate any meaningful failure. It is not clear to me what the cause of your problem is. One thing worth trying would be to format sdb1 as something other than BIOS boot. It shouldn't matter, but it still might.
1. Thank you for your comments David. 2. Have tried another install without a BIOS Boot partition. This also failed with the same symptoms when the machine attempted to reboot after installation, and after a RESCUE. 3. In case it helps the partition setup used was: Device Boot Start End Blocks Id System /dev/sdb1 * 2048 1050623 524288 83 Linux /dev/sdb2 1050624 135268351 67108864 83 Linux /dev/sdb3 135268352 177211391 20971520 83 Linux /dev/sdb4 177211392 1465147391 643968000 5 Extended /dev/sdb5 177215488 214308863 18546688 82 Linux swap / Solaris Where sdb1 was mounted as /boot, sdb2 was mounted as /home, sdb3 was mounted as /, and sdb5 was mounted as a swap partition.
It's possible we had some race with umounting the install source at reboot time. Have you tried this scenario with F17?
Hi Jesse Thank you for your comment. First my apology for not posting this many weeks ago. 1. Comment 4 of Bug 753681 pointed me to the main problem. My BIOS setting for SATA operation was set to RAID On, and even though the machine was not configured to use a RAID array this seems to have prevented the machine from rebooting (and possibly other things). 2. After setting the SATA operation to the AHCI option, the installation was (mainly) successful. Post installation the machine will still not reboot, however it does cold boot up to a usable system. 3. I have installed Fedora 17. It has the same problem i.e., the running system will not reboot correctly but it does cold boot up to a usable system. 4. I will list the last few lines of text that are written to the console before the machine hangs after rebooting in Fedora 16. The following appear as white text on a black foreground. [2096.274536] md: stopping all md devices [2097.274708] sd 1:0:0:0: [sdb] Synchronising SCSI cache [2097.316749] sd 0:0:0:0: [sda] Synchronising SCSI cache [2097.349033] xhci_hcd 0000:0a:00.0: PCI INT A disabled [2097.349119] ehci_hcd 0000:00:1d.0: PCI INT A disabled [2097.349162] ehci_hcd 0000:00:1a.0: PCI INT A disabled [2097.418065] e1000e 0000:00.19.0: PCI INT A disabled [2097.418213] Restarting system [2097.418239] machine restart
Ok, that sounds like a kernel or hardware issue thing, so I'll kick it over to kernel. They may close it out as buggy hardware.
Avon, is your machine rebooting properly with the 3.4 or 3.5 kernel updates?
(In reply to comment #16) > Avon, is your machine rebooting properly with the 3.4 or 3.5 kernel updates? Hi Josh; After reading your comment, I rechecked to see if I could reboot in Fedora 17. The Fedora 17 kernel that I am using is 3.5.1-1.fc17.x86_64. I was surprised to find that I can now reboot from: the console, an xterm terminal, Ctrl-Alt-Del (-> Restart -> enter root password), or the user's local menu -> Power Off (-> Restart -> enter root password). Commands used from the console and xterm were: # shutdown -r now $ sudo shutdown -r now I believe that this bug is now fixed Josh. Thank you!
Thanks for letting us know.