Bug 947285
|
Description
John Ellson
2013-04-02 03:58:03 UTC
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]
/mnt/sysimage/var/log/anaconda/anaconda.log
from just before reboot from live image
Created attachment 731148 [details]
/mnt/sysimage/var/log/anaconda/anaconda.program.log
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. Trying: Fedora-19-Nightly-20130403.16-i686-Live-xfce-20130403.16-1.iso same problem. 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: Fedora-19-Nightly-20130406.12-i686-Live-xfce-20130406.12-1.iso Still no go: Fedora-19-Nightly-20130412.13-i686-Live-xfce-20130412.13-1.iso Is no one else seeing this? Seems very quiet for such a major bug! Does it only affect KVM installs? Still no go: Fedora-19-Nightly-20130419.11-i686-Live-xfce-20130419.11-1.iso Still no go with:
Fedora-Live-XFCE-i686-19-Alpha-1.iso
But OK with minimal install from:
Fedora-19-Alpha-i386-DVD.iso
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? Possibly related?
https://bugzilla.redhat.com/show_bug.cgi?id=912791
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. |