Created attachment 522285 [details] bootloader install error Description of problem: run test case https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_serial_console error occurred, Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. boot guest with netinst.iso 2. pass serial console=ttyS0 to kernel 3. run minicom to monitor Actual results: error to install bootloader Expected results: Additional info:
after reboot, the guest cannot boot into the system
Can you attach /tmp/anaconda.log, /tmp/syslog, and /tmp/program.log? Thanks.
Created attachment 522869 [details] anaconda logs
(In reply to comment #2) > Can you attach /tmp/anaconda.log, /tmp/syslog, and /tmp/program.log? Thanks. please find the logs in the attachment, thanks.
08:05:13,415 WARNING program: Generating grub.cfg ... 08:05:13,602 WARNING program: cat: /boot/grub2/video.lst: No such file or directory 08:05:13,614 WARNING program: Serial terminal not available on this platform.
Reproduced with F16 Beta TC2 i686 DVD.
Reproduced with F16 Beta RC1 DVD.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
reproduced on F16 Beta RC3
reproduced with F16 beta RC4
Konrad Wilk has reproduced this with RC4 also.
/etc/grub.d/00_header depends on $GRUB_PREFIX = /boot/grub2/ being populated ... which is done by grub2-install. AFAICS there is no solution to that upstream. "konrad" confirmed on IRC that grub2-mkconfig works if grub2-install is run before grub2-mkconfig. I don't know if that can be used as a "solution" in anaconda.
The workaround is to do in the serial console: 15:06:41 Please manually connect your vnc client to tst004.dumpdata.com:1 (192.168.101.24) to begin the install. Press <enter> for a shell 15:06:41 Starting graphical installation. sh-4.2# sh-4.2# /mnt/sysimage sh-4.2# grub2-install /dev/sda Installation finished. No error reported. sh-4.2#grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.1.0-0.rc6.git0.3.fc16.x86_64 Found initrd image: /boot/initramfs-3.1.0-0.rc6.git0.3.fc16.x86_64.img done sh-4.2#
reproduced with F16 Final TC1
marking as a final release blocker, so we can decide if we want serial console to block final release or not.
Discussed at the 2011-10-21 blocker review meeting. Accepted as a blocker: we feel serial console is used enough to be blocker material at least for final. There isn't current a criteria for this, but we're pretty sure there's meant to be one and it got lost somewhere down the line. We will re-add this criterion.
reproduced with F16 Final TC2
*** Bug 745035 has been marked as a duplicate of this bug. ***
*** Bug 743642 has been marked as a duplicate of this bug. ***
Hongqing, Konrad - pjones tried to reproduce this, but couldn't. He used a bare metal system. Can you provide more details on your exact test configurations? Did you do anything not mentioned in the test case? Did you both use virt or bare metal? Thanks!
pjones found his storage.log had the grub 'error' in it, but the config was actually written, and the system booted.
It was definitely baremetal, and I think the cause of this was that I had selected _everything_ - including the guestfish? which ended up also installing grub1. Let me retry it tomorrow and see if I can reproduce it.
having the grub package selected shouldn't really affect whether grub2-mkconfig succeeds or not, but it would be interesting to know if you can reproduce this with a more normal package set.
This is 100% reproducible for me on a KVM VM installing from the F16 beta DVD. The system shows the same error as in the attachment "bootloader install error" and the system does not boot after the install completes.
is a valid config file actually apparently produced, or not?
(In reply to comment #26) > is a valid config file actually apparently produced, or not? The grub2.cfg is empty with minimal installation. I cannnot select package with minicom.
I can confirm this is extremely easily reproducible with KVM and TC2 DVD. Created grub.cfg is empty.
So, in case it hasn't been clear thus far, the video.lst file missing isn't the critical error. grub2 warns about that, but continues. The critical problem is /boot/serial.mod: if [ "x$serial" = x1 ]; then if ! test -e ${GRUB_PREFIX}/serial.mod ; then echo "Serial terminal not available on this platform." >&2 ; exit 1 fi so if it knows it's doing a serial console install and it can't find serial.mod it simply exits. I don't know why we're hitting that problem on some serial installs but not others, but it's certainly what the problem is.
that's from grub2's /etc/grub.d/00_header , btw.
So, pjones went ahead and fixed the issue as diagnosed, without figuring out why he couldn't reproduce, and tflink has tested that it works for him at least. Can others please test with this updates image: http://pjones.fedorapeople.org/serial-updates.img and see if that fixes the problem for you? Thanks! To use it, just boot from the TC2 image with the kernel parameter 'updates=http://pjones.fedorapeople.org/serial-updates.img'.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=748964 as a Rawhide 'clone' of this, as pjones thinks there should be a better long-term fix.
(In reply to comment #31) > Can others please test with this updates image: > > http://pjones.fedorapeople.org/serial-updates.img That fixes it on my system.
anaconda-16.23-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.23-1.fc16
When using the updates.img it seems that there is a new dialog in the beginning that asks whether to enable VNC mode or text mode. I don't remember it from previous installs, I'm not sure whether it was there or not. The updates.img fixes the serial console problem.
Tested with TC3 i686 on bare metal. After installation, the machine booted as expected.
anaconda 16.24-2 (glibc rebuild) went stable, so CLOSING. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I hit this with F17 Alpha TC1
Created attachment 559554 [details] anaconda logs
I'm also seeing this on F17 Alpha TC1: ┌──────────────────┤ Warning ├──────────────────┐ │ │ │ There was an error installing the bootloader. │ │ The system may not be bootable. │ │ │ │ ┌────┐ │ │ │ OK │ │ │ └────┘ │ │ │ │ │ └───────────────────────────────────────────────┘ ...and indeed the system does not boot I am able to get a bootable system as with F16 Beta by booting the install DVD in rescue mode and executing: sh-4.2# grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.3.0-0.rc2.git1.1.fc17.x86_64 Found initrd image: /boot/initramfs-3.3.0-0.rc2.git1.1.fc17.x86_64.img done sh-4.2# grub2-install /dev/vda Installation finished. No error reported. sh-4.2#
reproduced with F17 Alpha TC2
Discussed at 2012-02-10 blocker review meeting. Agreed this does not hit the Alpha criterion, "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces", which intentionally excludes the serial interface. We still haven't decided whether we want serial install to block beta or final, but we're clear that it doesn't block Alpha. Accordingly, this is rejected as an Alpha blocker. Re-proposing as a Beta blocker so this doesn't fall off the radar. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Just my $.02, it should block Beta. Of course, I would say that since nearly all my machines are serial console only. Although serial console is something of a niche use case, it's not going away, and people who use it depend on it.
reproduced with F17 Alpha RC2
I'd like to add my voice to those requesting this to be a beta blocker. Well over half the hardware variants used by the customer, I am assigned to, is serial only.
reproduced with F17 Alpha RC4
I kindly request high priority when solving this bug. Our automated installation tests are blocked by this.
reproduced with F17 Alpha (as released to the general public)
Created attachment 568107 [details] Reproducer script for failure of a KVM guest install(specifically 'bootloader' install) via serial console using F17 alpha
Please find the reproducer(in Comment #50) for the behaviour in comment #41
reproduced with F17 Beta TC1
*** Bug 748964 has been marked as a duplicate of this bug. ***
Discussed at 2012-03-09 blocker review meeting. Agreed the bug is a beta blocker: we have general consensus that serial console should be beta blocking. We will update the criteria to reflect this, and conclude the ongoing ML discussion. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Soo, can you please push modified grub2 to Fedora Updates? Thanks.
I believe https://admin.fedoraproject.org/updates/FEDORA-2012-3875/grub2-1.99-19.fc17 should have the fix for this. We need to build an image with that grub2 to test. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This should be fixed in TC2. Please note the syntax for triggering a serial console install has changed: https://bugzilla.redhat.com/show_bug.cgi?id=804506#c2 - we will need to adjust the test case. Hongqing, please re-test, following the new syntax. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is currently blocked on bug #804506. Can't verify fix.
the grub2 update is now actually stable, but we still need to verify the fix with TC3 or RC1. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It should be possible to verify this with RC1. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is fixed with F17 Beta RC1
Let's close, then, all relevant components are stable. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers