After installing F16 Beta with serial console only, I see the following errors at the grub menu: error: the argument `--speed=' requires an integer. error: unknown terminal 'serial' . error: unknown terminal 'serial' . I ran into BZ 743642 during the install, so I had to manually install grub after booting into rescue mode. I don't know how that affected things. The errors appear to be harmless; the console behaves properly other than BZ 739522
Created attachment 526607 [details] screenshot of grub menu I've attached a screenshot of the grub menu.
Please attach /etc/default/grub and /boot/grub2/grub.cfg.
Created attachment 529980 [details] /etc/default/grub
Created attachment 529981 [details] /boot/grub2/grub.cfg
grubs complains makes sense; grub.cfg contains serial --unit=0 --speed= terminal_input serial console terminal_output serial console that _must_ be caused by invalid settings in /etc/default/grub made by anaconda. The file has however been overwritten by a grub update because of bug 741045, so the evidence has been removed. Can you reproduce the problem by installing from the latest test composes? Is it really creating a /etc/default/grub without speed? If so the anaconda log and program.log might be useful. Just a thought ... are you using a "real" serial console where you specify the speed? Or is it some kind of virtual xen serial console where you don't specify any speed?
/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py : speed = "9600" for opt in self.console_options.split(","): if opt.isdigit: speed = opt break command = "serial --unit=%s --speed=%s" % (unit, speed) opt.isdigit is always true - it should be opt.isdigit(). That can explain why GRUB_SERIAL_COMMAND contains an invalid speed setting. Which kernel boot parameters did you use?
proposing as NTH for final, for now: we're not entirely clear what consequences this causes due to the masking bug, but it looks like something that anaconda's clearly getting wrong, which it ought to be getting right, at the least.
(In reply to comment #5) > grubs complains makes sense; grub.cfg contains > serial --unit=0 --speed= > terminal_input serial console > terminal_output serial console > > that _must_ be caused by invalid settings in /etc/default/grub made by > anaconda. The file has however been overwritten by a grub update because of bug > 741045, so the evidence has been removed. > > Can you reproduce the problem by installing from the latest test composes? Is > it really creating a /etc/default/grub without speed? If so the anaconda log > and program.log might be useful. I can reproduce it using TC2. I'll attach install.log and anaconda.program.log > Just a thought ... are you using a "real" serial console where you specify the > speed? Or is it some kind of virtual xen serial console where you don't specify > any speed? It's a virtual KVM console without a specified (AFAIK) speed.
Created attachment 530151 [details] install log
Created attachment 530152 [details] anaconda program log
BTW, I'm still running into BZ 743642 with TC2, so in order to get a bootable system, I have to boot into rescue mode and install grub manually. When I first boot into rescue mode /boot/grub2/grub.cfg is a zero byte file.
Ok, so it was a manual boot loader installation all the time? How do /etc/default/grub look like? The issue from comment 6 has been fixed in next anaconda build, but I wonder what trigged the error. How do /proc/cmdline look - especially when the installer has been booted?
So using the test package available in bug 736993 I was able to get the installer to run through and install grub correctly. The error messages are still there, though. Re-running the installer shows a command line of: [ 0.000000] Linux version 3.1.0-0.rc10.git0.1.fc16.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.6.1 20111003 (Red Hat 4.6.1-10) (GCC) ) #1 SMP Wed Oct 19 05:02:17 UTC 2011 [ 0.000000] Command line: initrd=initrd.img serial console=ttyS0 updates=http://pjones.fedorapeople.org/serial-updates.img BOOT_IMAGE=vmlinuz
(In reply to comment #13) > Re-running the installer shows a command line of: I mean, I created a new VM and started another install, if that wasn't clear...
How do /etc/default/grub look like?
Ok, got it: (In reply to comment #6) > /usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py : > speed = "9600" > for opt in self.console_options.split(","): > if opt.isdigit: > speed = opt > break > > command = "serial --unit=%s --speed=%s" % (unit, speed) In your case console_options='' and it will thus loop through a list with an empty string and that string will be used as speed. It will be fixed by http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=7ac1fd221759e1a095f33df235fdc1091051281e
Created attachment 530164 [details] /etc/default/grub
(In reply to comment #16) > It will be fixed by > http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=7ac1fd221759e1a095f33df235fdc1091051281e Any way I could try that out?
(In reply to comment #18) > Any way I could try that out? I guess it will be included in the first f16 RC which in principle should be made today. Somebody in the qa team might know where to find something usable earlier than that.
Thanks, I'll try it out.
Dave: can you reproduce this if you use the updates.img that fixes 743642?
apologies, you already answered that. sorry.
anaconda-16.23-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.23-1.fc16
tc3 should have the fix for this, so you can test with that: http://dl.fedoraproject.org/pub/alt/stage/16.TC3/ please test and let us know if it's resolved. thanks! (it should also fix the bigger 'bootloader install fails' bug, so serial console install should work OOTB now).
Discussed at 2011-10-28 NTH review meeting, accepted as NTH as a visible installer bug which can't be fixed with an update and could theroetically cause some kind of serial install borkage. The fix was included in anaconda 16.23 and we're pulling that for sure anyway. We still need the verification requested in comment #24. thanks!
I tested the netinst image, the serial console install worked properly and the errors are gone, so it's looking good.
Thanks!
Let's close, fixed anaconda has gone stable now. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers