Description of problem:
grub finds no bootable image after save image to disk from Fedora-19 i686 live iso
Attempting to boot results in a "grub>" prompt and 100% cpu load shown on virt-manager.
Propose FC18 blocker!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install live image on virtual machine
2. save to hard drive
Boot into installed Fedora-19
does *not* have the same issue. I have been able to install Fedora-19 x86_64.
That should read "Fedora-19 blocker"
Please attach /var/log/anaconda/anaconda.log and /var/log/anaconda/program.log from your installed system to this bug report.
Sorry, I don't know how to do that since the system is unbootable.
Can I mount the img from another virtual machine? How?
Created attachment 731147 [details]
from just before reboot from live image
Created attachment 731148 [details]
from just before reboot from live image
00:26:51,125 INFO program: Generating grub.cfg ...
00:26:51,130 INFO program: Found theme: /boot/grub2/themes/system/theme.txt
00:26:51,130 INFO program: Found linux image: /boot/vmlinuz-3.9.0-0.rc4.git0.1.fc19.i686
00:26:51,131 INFO program: Found initrd image: /boot/initramfs-3.9.0-0.rc4.git0.1.fc19.i686.img
00:26:51,132 INFO program: Found linux image: /boot/vmlinuz-0-rescue-38ce06a405934ff891289d37cbacaa17
00:26:51,132 INFO program: Found initrd image: /boot/initramfs-0-rescue-38ce06a405934ff891289d37cbacaa17.img
00:26:51,133 INFO program: error: syntax error.
00:26:51,134 INFO program: error: Incorrect command.
00:26:51,134 INFO program: error: syntax error.
00:26:51,134 INFO program: Syntax error at line 152
00:26:51,134 INFO program: Syntax errors are detected in generated GRUB config file.
00:26:51,136 INFO program: Ensure that there are no errors in /etc/default/grub
00:26:51,136 INFO program: and /etc/grub.d/* files or please file a bug report with
00:26:51,136 INFO program: /boot/grub2/grub.cfg.new file attached.done
Could you also grab /etc/default/grub from this system and attach it as well? THanks.
There are files in /etc/grub.d/* Do you need those too?
Can't hurt to have them.
Created attachment 731697 [details]
/mnt/sysimage/etc/default/grub - 20130403.16-1 just before reboot into installed image
Created attachment 731698 [details]
/mnt/sysimage/var/log/anaconda/anaconda.log - 20130403.16-1 just before reboot into installed image
Created attachment 731699 [details]
/mnt/sysimage/var/log/anaconda/anaconda.program.log - 20130403.16-1 just before reboot into installed image
Created attachment 731700 [details]
tar of /mnt/sysimage/etc/grub.d - 20130403.16-1 just before reboot into installed image
Is a tar file OK?
Still no go:
Still no go:
Is no one else seeing this? Seems very quiet for such a major bug! Does it only affect KVM installs?
Still no go:
Still no go with:
But OK with minimal install from:
Was that the tboot issue? https://bugzilla.redhat.com/show_bug.cgi?id=955750
Possibly. From comparing the Description in Bug#95570 with Comment#6 here it seems likely, although I don't quite understand how it got to a "tboot issue" ?
For me also the problem only affects 32 bit systems.
Does the "tboot issue" explain why it affects Live images, but not the DVD image?
I hit this too on install with the Live iso (Fedora-Live-Desktop-i686-19-Alpha-1.iso) in VirtualBox 4.2.12. Haven't tried any nightlies (would have to download one), and will shortly try a physical system.
Proposing Release blocker per criteria:
" Expected installed system boot behavior
A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account. "
Just tried Fedora-Live-Desktop-i686-19-Alpha-1.iso on a Dell Optiplex GX620 (Pentium D w/ 4GB RAM I think), and after install it booted to a grub prompt.
Installed using a USB stick created by using DD.
Fedora-Live-Desktop-i686-19-Beta-TC3-1.iso created by using LiveUSB creator 3.11.8 however worked on Dell Gx620. After install it showed the grub boot menu and booted successfully with a root password and user configured.
Might be worth trying John to see if you see the same.
Discussed at 2013-05-06 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-06/f19beta-blocker-review-3.2013-05-06-16.02.log.txt . It looks like all the failure reports here are with Alpha images; John, can you please test with Beta TC3 or later and see if you are still having trouble? Cybertimer, if you're worried about the dd case, can you re-test that with a Beta TC3 or later image?
We will re-evaluate this at the next meeting; if we don't get any feedback on the situation with Beta, the bug is likely to be rejected as a blocker and/or closed. Thanks!
Sorry my comments caused some confusion here and in the blocker meeting. I don't think dd is related here as even in a virtual machine (VirtualBox) installing Fedora-Live-Desktop-i686-19-Alpha-1.iso it booted to the grub prompt and that was directly from the .iso.
I'm in the process of retesting on physical hardware. So far:
Fedora-Live-Desktop-i686-19-Alpha-1.iso using dd: Booted to grub.
Fedora-Live-Desktop-i686-19-Alpha-1.iso using live-to-usb: Booted to grub.
Fedora-Live-Desktop-i686-19-Beta-TC3-1 using dd: In progress
Fedora-Live-Desktop-i686-19-Beta-TC3-1 using live-to-usb: In Progress.
Are there any relevant logs I can grab before reboot that shows the grub install log? Even though it's working in Beta TC3-1, I'm not sure if it's wanted in case the problem returns.
Fedora-Live-Desktop-i686-19-Beta-TC3-1 using dd: Booted to Gnome desktop.
Fedora-Live-Desktop-i686-19-Beta-TC3-1 using live-to-usb: Booted to Gnome desktop.
I'd say reject the blocker since it seems fixed in TC3-1 and only affected the alpha.
Thanks, Cyber. John, are you still experiencing problems with Beta TC3?
Discussed at 2013-05-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Cybertimber no longer has an issue, and other validation testing of Beta TCs hasn't resulted in anyone else reproducing this issue so far as we know. We're not entirely sure what was going on in John's case, but for now, we decided to reject this as a blocker.
John, if you're still having trouble with current images, please update the bug with details and re-propose as a blocker if appropriate. Thanks!
Ignore me - just trying to suppress the "needinfo" spam from this stale bug.