| Summary: | agetty not started for /dev/hvc0 on latest F20 kernels | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Cole Robinson <crobinso> | |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 20 | CC: | amit.shah, gansalmon, itamar, johannbg, jonathan, kernel-maint, lnykryn, madhu.chinakonda, msekleta, plautrba, systemd-maint, vpavlin, zbyszek | |
| Target Milestone: | --- | Keywords: | Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1055089 (view as bug list) | Environment: | ||
| Last Closed: | 2014-06-18 14:47:05 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1055089 | |||
|
Description
Cole Robinson
2013-12-09 21:38:46 UTC
(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... |