Description of problem: New Lenovo T430 laptop, tried installing FC19-TC5. The install completed, but the resulting linux would not load/boot. Just printed a message about no OS found (something like that). I think grub2 was complaining that it could not find a kernel/root to load. Version-Release number of selected component (if applicable): FC19-TC5. How reproducible: 100%. Two installs both fail the same way. Steps to Reproduce: 1. Install on a Lenovo T430. Actual results: Could not load/boot linux. Expected results: Boot linux. Additional info: The hard drive is partitioned with Windows on half and the rest for FC19. The install itself did not indicate any errors. After completing the install, the reboot went directly to Windows. Rebooted into the DVD linux rescue kernel and parted showed the Windows partition was still marked as the boot partition. Changed it to make Linux the boot partition, but then the reboot complained about no OS found. Looks like grub2 was unhappy. FWIW, the laptop has UEFI, Secure Boot not enabled. An install using Open SuSE 12.2 successfully installed and booted into Linux. That should indicate the problem is not hardware/bios. I have not tried earlier versions of Fedora to see if this is a regression.
Please attach the logs from /tmp/*log to this bug as individual text/plain attachments. After the install you can find them in /var/log/anaconda/
Since I don't want to wipe up out the working SuSE install, I am trying to reproduce the problem on a similar laptop provided by corporate IS, to get the requested debugging information.
Note that a T410 laptop installs & boots correctly. The T410 is non-UEFI. When install completes on a T430 and "reboot" is pressed, only one line is printed ("4m[terminated]") and nothing else. The laptop did not reboot. <ctrl><alt><delete> would not reset it. Had to hold the power button to power it off. <ctrl><alt>F3 show a last message of "ERR anaconda: Problems running the window manager: 1". <ctrl><alt>F4 shows "INFO systemd: Stopping Anaconda System Services". When powered back on it boots into Windows. Rebooting into rescue mode to get the log files...
The log files were still in /tmp/, not in /var/log/anaconda/, if that is a clue. I will attach the non-zero size *.log files. linux$ ls -l tmp/ total 292 -rw-r--r-- 1 rja oldiag 370 Jun 24 16:07 anaconda.log -rw-r--r-- 1 rja oldiag 5 Jun 24 16:07 firstaidkit-qs-1030.item -rw-r--r-- 1 rja oldiag 0 Jun 24 16:07 ifcfg.log -rw-r--r-- 1 rja oldiag 0 Jun 24 16:07 packaging.log -rw-r--r-- 1 rja oldiag 44604 Jun 24 16:07 program.log -rw-r--r-- 1 rja oldiag 108452 Jun 24 16:07 storage.log -rw-r--r-- 1 rja oldiag 20480 Jun 24 16:07 storage.state -rw-r--r-- 1 rja oldiag 107416 Jun 24 16:07 syslog drwx------ 2 rja oldiag 4096 Jun 24 16:07 tmux-0
Created attachment 764785 [details] program.log
Created attachment 764786 [details] storage.log
Wait, those look like the rescue linux /tmp files, not files from the install. The rescue kernel mounted the installed hard drive partition in /mnt/sysimage. /mnt/sysimage/var/log shows no anaconda/ directory. the messages file has size of 0. /mnt/sysimage/tmp just has yum.log. Could the installer have failed to sync the files and crashed? /mnt/sysimage/boot shows: ------------------------------------------------------------------- -rw-r--r--. 1 root root 127669 Jun 11 19:46 config-3.9.5-301.fc19.x86_64 -rw-------. 1 root root 10223616 Jun 24 2013 initramfs-0-rescue-83852fe7b23a4fb596e8162c952a958e.img -rw-------. 1 root root 11893696 Jun 24 2013 initramfs-3.9.5-301.fc19.x86_64.img -rw-r--r--. 1 root root 557925 Jun 24 2013 initrd-plymouth.img -rw-------. 1 root root 2594764 Jun 11 19:46 System.map-3.9.5-301.fc19.x86_64 -rwxr-xr-x. 1 root root 0 Jun 24 2013 vmlinuz-0-rescue-83852fe7b23a4fb596e8162c952a958e -rwxr-xr-x. 1 root root 5055896 Jun 11 19:46 vmlinuz-3.9.5-301.fc19.x86_64 grub2: total 2 drwxr-xr-x. 3 root root 1024 May 9 2012 themes lost+found: total 0 ------------------------------------------------------------------- No grub.cfg file (etc). So it does not look bootable even if the linux disk partition was set as the boot partition.
The "4m[terminated]" isn't related. If you wait long enough it will actually reboot. Try doing the install again and pull the logs from /tmp/ before pressing reboot. It sounds like grub didn't get installed at all.
It looks like the long delay is due to NetworkManager repeatedly timing out. Yes, a few minutes later it does finally pull reset, but it looked hung long enough that people like me would assume the reboot failed and press the power button. Trying to reproduce the problem to get the debug info hit BZ 978065.
"but it looked hung long enough that people like me would assume the reboot failed and press the power button." doesn't really matter if you do. install is complete at that point. it won't have any negative consequences. neither log gives any indication of any kind of attempt to set up a bootloader. are you sure you didn't pick the 'don't install a bootloader' option?
I'll take your word that hitting the power button did not have any negative consequence, though I was tempted to blame the power off for the failure. Must be something else. I am sure I did not pick 'don't install a bootloader' option because I wanted to use the defaults, to keep things simple.
This may be the same issue as BZ 978430 and BZ 978065, Anaconda not supporting UEFI with msdos format hard drives.
*** This bug has been marked as a duplicate of bug 978430 ***