Recent F20 kernels now distribute virtio-console as a module: https://bugzilla.redhat.com/show_bug.cgi?id=1019569 However this change has the side effect that a getty is no longer autostarted on /dev/hvc0, so 'virsh console' doesn't automagically work like it used to. Not sure if this is something systemd can fix, or if we should consider reverting the kernel change. (there have also been reports that console=hvc0 on the kernel command line no longer works for showing boot output, so there's two regressions that stem from that kernel change)
(In reply to Cole Robinson from comment #0) > > Recent F20 kernels now distribute virtio-console as a module: > > https://bugzilla.redhat.com/show_bug.cgi?id=1019569 > > However this change has the side effect that a getty is no longer > autostarted on /dev/hvc0, so 'virsh console' doesn't automagically work like > it used to. It can be made to a udev trigger instead of just assuming a vc exists if /dev/hvc0 is present.
I am pretty sure it would be a better idea to leave virtio-console compiled in in the kernel. I kinda like the robust logic in systemd that just always makes use of the console, instead of doing hotplugging magic. I mean, this is the console after all, not some random physical device you plug in. We could add complexity for this to userspace to work aorund this, but really, the console is not really where we should play those games, it's the fricking console after all... ;-) Given that virtio-console is tiny, can't we just leave this compiled into the kernel? I am pretty sure people would be thankful about this in many other cases too, for example when they use init=/bin/sh on the kernel cmdline or something like that....
Amit, per comment #2, thoughts on going back to virtio-console compiled into the kernel?
It's just a console [#], but: * it pulls in virtio* dependencies (including virtio-pci on x86, and virtio-mmio on arm, s390) * those virtio* drivers need to be compiled in even on non-guest configurations (which means all hosts) If the complexity this might introduce in systemd/udev outweighs the additional RAM required for compiling in these drivers for all configurations, we would want to flip it back to compiled in. [#]: Also, it's not just a console: the virtio-console driver also drives the virtio-serial (i.e. a non-tty guest-host communication channel) functionality.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug will not be auto fixed by a kernel update, since it is specific to Fedora's kernel config. Any way to tag a bug as such?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
OK, so we've fallen down on handling this. Do we still have a problem here (nobody else has complained about this that I'm aware of), and do we have agreement on a solution?
Thanks for following up Josh. Apparently I'm the only one who cares about this issue, so I'm fine with just closing this bug, same was already done for RHEL7 as well. Would be nice if systemd could handle it but I'm not going to hold my breath...