Description of problem: When running a Xen guest kernel, or a KVM guest with VirtIO-Console enabled, there is a paravirtualized console device presented as /dev/hvc0. This accessible from the host OS using 'virsh console GUEST'. The initscripts only launch a login prompt on this device if the kernel command line has 'console=hvc0'. This is wrong behaviour. The core raison d'tre of the /dev/hvc0 device is as a text mode login to the guest machine. Thus if a /dev/hvc0 device is present then there should *always* be a login prompt launched on it, even if the kernel's console is configured for a serial port, or a VGA device, or somewhere else. It should not be neccessary to add special kernel params like 'console=hvc0' in order to get a login prompt. This problem appears fairly easy to resolve - /lib/udev/rules.d/10-console.rules needs to have the hvc0 line removed - /etc/securetty needs to have hvc0 added - A new file /etc/event.d/hvc0 needs to be added, containing same logic as /etc/event.d/tty2, just with substitution of tty2 with hvc0. Version-Release number of selected component (if applicable): initscripts-8.95-1.x86_64 How reproducible: Always Steps to Reproduce: 1. Install a Xen paravirt guest using the graphical console 2. post-install try to use 'virsh console GUEST' to login via text console 3. Actual results: No login prompt available Expected results: Login prompt always available Additional info:
Thanks for your report. Assigning it. -- Fedora Triage Team Volunteer Member
My apologize it must be as rawhide.
Upstream is in the process of majorly changing virtio console, so I'd recommend *NOT* fixing this bug at this point in time. Postpone to F13 when we'll have a better idea of how virtio console changes turned out.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Moving this to rawhide. Pretty sure virtio console is set in stone at this point, we just need the changes Dan outlined above to make this work out of the box. notting, does danpb's comment sound reasonable? It would be nice to get this in for F14 (and hopefully would be a harmless F13 backport).
Well, upstart's been rebased in the meantime, and therefore the code would be different. And then there's the matter of systemd in F-14.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Re-assigning to systemd, since initscripts/upstart are going the way of the dodo. The original problem description is still fairly accurate, ignoring the obsolete proposed solution. KVM in fact now supports multiple paravirt text consoles which will appear as (hvc0, hvc1, hvc2, etc). So ideally systemd would just enable an agetty on all hvcXXX devices that are present in a machine, regardless of what the guest's primary console device is. ie we want VNC graphical console as primary, and also text console logins.
Does this require agetty or would mingetty work too? i.e. does this device require any of the special serial terminal features of agetty? How can I test this? The fixing of securetty should be requested in the setup package.
To set this up * Pull down 0.8.3 release of libvirt (currently scheduled for f14 testing): https://admin.fedoraproject.org/updates/libvirt-0.8.3-2.fc14 (Do a 'service libvirtd restart' after install just to be sure) * If you don't already have an F14 or RHEL6 guest installed, then install one with virt-install/virt-manager. Older guests won't have virtio console support. * While the guest is shutoff, run 'virsh edit $GUESTNAME' and add the following XML within the <devices> section: <console type='pty'> <target type='virtio'/> </console> The editor is 'vi', so just :wq to save & exit * Now start the guest with 'virsh start $GUESTNAME' (or virt-manager) * Run 'ps -axuwwf | grep qemu'. If all is operating correctly you should see the following args were included on the command line for the guest: -device virtio-serial-pci,id=virtio-serial0 -chardev pty,id=console0 -device virtconsole,chardev=console0 * Running 'virsh console $GUESTNAME' will now connect to the host side of the console and display any data / allow input. It won't do anything useful until the next step though.... * Inside the guest OS launch an 'agetty /dev/hvc0 9600' * The previous virsh console session should now display a login prompt and let you enter your credentials I have tried 'mingetty /dev/hvc0' too, but in my tests it simply exits without doing anything, so AFAICT we need to use agetty. The virtio console devices aren't really serial devices, so don't require any special serial config parameters, but the baud rate parameter seems tobe mandated by agetty :-(
Hmm, I thought mingetty was supposed to be sufficient for virtio-console, maybe Amit can confirm one way or the other.
Hmm, and what's the appropriate TERM setting? TERM=linux? TERM=vt100?
I've not used mingetty. I just tried and it didn't work. I've always used TERM=vt100 and that works fine, but TERM=linux works as well. Also: I'd advise against spawning a virtio-console on more than one port: I remember seeing races in the code and it doesn't work well in some cases. Sadly, I don't remember all the details now. But just mentioning the tty/hvc mess is enough to stay away as much as possible. Also, even if just two virtio-consoles are provided to the guest, the guest has /dev/hvc0../dev/hvc7 available. Spawning an agetty on them isn't harmful, though, as there'll be no effect for ports that don't have a device attached.
(In reply to comment #13) > Also, even if just two virtio-consoles are provided to the guest, the guest has > /dev/hvc0../dev/hvc7 available. Spawning an agetty on them isn't harmful, > though, as there'll be no effect for ports that don't have a device attached. Surely this would cause spurious errors that would confuse the admin, though?
(In reply to comment #14) > (In reply to comment #13) > > Also, even if just two virtio-consoles are provided to the guest, the guest has > > /dev/hvc0../dev/hvc7 available. Spawning an agetty on them isn't harmful, > > though, as there'll be no effect for ports that don't have a device attached. > > Surely this would cause spurious errors that would confuse the admin, though? I haven't seen anything logged in such cases, but that may be due to my settings (which aren't too different from the default). There could certainly be some tunables which users could enable and cause the warnings to appear. However, it's best not to have multiple consoles as of now.
systemd git now adds in a serial getty on /dev/hvc0 if /sys/class/tty/hvc0 exists.
systemd-9-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-3.fc14, initscripts-9.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.18-1.fc14
initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.