Bug 501720 - RFE: launch a login process on all paravirt consoles (/dev/hvc0, 1, 2... etc)
RFE: launch a login process on all paravirt consoles (/dev/hvc0, 1, 2... etc)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-20 09:44 EDT by Daniel Berrange
Modified: 2010-09-29 05:29 EDT (History)
12 users (show)

See Also:
Fixed In Version: initscripts-9.20-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-14 19:22:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2009-05-20 09:44:38 EDT
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:
Comment 1 iarly selbir 2009-06-09 19:03:02 EDT
Thanks for your report.


Assigning it.


--
Fedora Triage Team Volunteer Member
Comment 2 iarly selbir 2009-06-09 19:14:30 EDT
My apologize it must be as rawhide.
Comment 3 Daniel Berrange 2009-09-15 07:00:12 EDT
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.
Comment 4 Bug Zapper 2009-11-16 04:59:56 EST
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
Comment 5 Cole Robinson 2010-07-13 18:16:32 EDT
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).
Comment 6 Bill Nottingham 2010-07-14 10:33:36 EDT
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.
Comment 7 Bug Zapper 2010-07-30 06:39:40 EDT
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
Comment 8 Daniel Berrange 2010-08-23 11:25:03 EDT
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.
Comment 9 Lennart Poettering 2010-08-23 13:46:34 EDT
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.
Comment 10 Daniel Berrange 2010-08-24 07:52:27 EDT
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 :-(
Comment 11 Cole Robinson 2010-08-24 11:10:03 EDT
Hmm, I thought mingetty was supposed to be sufficient for virtio-console, maybe Amit can confirm one way or the other.
Comment 12 Lennart Poettering 2010-08-24 20:12:12 EDT
Hmm, and what's the appropriate TERM setting? TERM=linux? TERM=vt100?
Comment 13 Amit Shah 2010-08-25 07:48:16 EDT
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.
Comment 14 Bill Nottingham 2010-08-25 12:04:10 EDT
(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?
Comment 15 Amit Shah 2010-08-25 12:28:20 EDT
(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.
Comment 16 Lennart Poettering 2010-08-30 17:37:46 EDT
systemd git now adds in a serial getty on /dev/hvc0 if /sys/class/tty/hvc0 exists.
Comment 17 Fedora Update System 2010-09-02 23:37:58 EDT
systemd-9-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/systemd-9-2.fc14
Comment 18 Fedora Update System 2010-09-03 12:43:59 EDT
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
Comment 19 Fedora Update System 2010-09-03 18:36:51 EDT
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
Comment 20 Fedora Update System 2010-09-07 23:18:11 EDT
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
Comment 21 Fedora Update System 2010-09-10 11:13:58 EDT
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
Comment 22 Fedora Update System 2010-09-14 00:28:22 EDT
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
Comment 23 Fedora Update System 2010-09-15 03:11:58 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.