We currently have CONFIG_VIRTIO_CONSOLE=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO=y These should be reverted to be built as modules once the parent bug is resolved. Anaconda will then work fine with virtio_console built as a module, and the kernel won't be bloated for non-virt or non-kvm installs. +++ This bug was initially created as a clone of Bug #1019564 +++ Description of problem: Brian C. Lane found Lorax removes the virtio_console.ko module from the installer image; it needs to leave drivers/char/virtio_console.ko when cleaning up, to ensure kernels which build virtio_console.ko as a module are able to send guest install logs to the host via virtio-serial.
VIRTIO_CONSOLE was made built-in in bug 677713.
So bug 677713 made it built-in on x86_64 to match i386, but there's really no explanation as to why it was made built-in to begin with. I'm all for making things modular, but I'm curious why we made it built-in in the first place. I don't want to go breaking things because we didn't notice it needed to be built-in somewhere. Particularly not in F20 now that it's in Beta freeze. Does anyone remember why these were made built-in originally?
(In reply to Josh Boyer from comment #2) > So bug 677713 made it built-in on x86_64 to match i386, but there's really > no explanation as to why it was made built-in to begin with. I'm all for > making things modular, but I'm curious why we made it built-in in the first > place. I don't want to go breaking things because we didn't notice it > needed to be built-in somewhere. Particularly not in F20 now that it's in > Beta freeze. > > Does anyone remember why these were made built-in originally? Yes, it was built-in to accomodate anaconda not being able to load virtio_console on demand. Brian Lane now says this functionality is handled in lorax, so anaconda doesn't need any smarts (like what was proposed in bug 677713). I'm not sure what the orig bug reference or config file change reference is where this was changed (neither in bugzilla nor in git). However I do know that this change was made for anaconda, and due to human error, the change was only made in the i686 configs, which was not the intent. The intent was to enable for all x86*. Downstream kernels don't have virtio_console built-in, and Brian Lane has fixed lorax to work properly, so he can attest things are working fine. I know for sure nothing breaks if virtio_console is built as a module on x86*. s390 is a different case, though, where it's the only way to get console, and has to be built-in (but also has the other advantage of not needing virtio-pci -- since s390 doesn't have pci yet).
Great, thanks for the explanation. Just to summarize, we want: s390x - CONFIG_VIRTIO_CONSOLE=y everything else: CONFIG_VIRTIO_CONSOLE=m (and the other options also =m) correct? That's easy enough to do. Brian, could you comment here when a lorax with the fixes is being used to compose both the F20 and rawhide trees? I can change the kernel configs for F20 and rawhide at that point if I understand everything correctly.
(In reply to Josh Boyer from comment #4) > Great, thanks for the explanation. Just to summarize, we want: > > s390x - CONFIG_VIRTIO_CONSOLE=y > everything else: CONFIG_VIRTIO_CONSOLE=m (and the other options also =m) > > correct? Yes.
(In reply to Josh Boyer from comment #4) > Brian, could you comment here when a lorax with the fixes is being used to > compose both the F20 and rawhide trees? I can change the kernel configs for > F20 and rawhide at that point if I understand everything correctly. From bug 1019564 lorax-20.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lorax-20.3-1.fc20
Modified the configs in Fedora git. Should be in the next f20/rawhide builds.
kernel-3.11.6-302.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.6-302.fc20
Package kernel-3.11.6-302.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.6-302.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20566/kernel-3.11.6-302.fc20 then log in and leave karma (feedback).
kernel-3.11.7-300.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.7-300.fc20
kernel-3.11.7-300.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
FWIW this has caused two regressions: 1) systemd no longer autostarts a getty on /dev/hvc0: https://bugzilla.redhat.com/show_bug.cgi?id=1039742 2) There was a mailing list report that console=hvc0 no longer works for seeing kernel boot output. I didn't even know that was supposed to work but not surprising it is now broken. Maybe one or both of those issues have other fixes, but if not we might want to consider if the gains of modularizing virtio-console were worth it.
(In reply to Cole Robinson from comment #12) > FWIW this has caused two regressions: 1) systemd no longer autostarts a > getty on /dev/hvc0: > > https://bugzilla.redhat.com/show_bug.cgi?id=1039742 I'll check what happens there. systemd should be able to discover the port in late-boot (via udev). > 2) There was a mailing list report that console=hvc0 no longer works for > seeing kernel boot output. I didn't even know that was supposed to work but > not surprising it is now broken. This never worked -- virtio_console on x86 lacks early_printk support, so wonder what got broken here.