Description: When running virt-install with "--graphics none" virt-install will connect you to the serial console of the guest. In F20 this is hvc0 rather than ttyS0 so when I was passing in either nothing or console=ttyS0 to the cmdline it wasn't working. It would be nice if virt-install could detect what console option is the proper one to use for the Guest/OS we are installing and add an appropriate console=XXXX option for the situation. Here is the command I was using to install: virt-install --name nest2 --ram 2048 --disk /guests/nest2.img,size=10,bus=scsi --controller=scsi,model=virtio-scsi --accelerate --location http://dl.fedoraproject.org/pub/fedora/linux/development/20/x86_64/os/ --extra-args "ks=http://192.168.133.1:8000/kickstart.ks cmdline" --graphics none --os-variant fedora20 Version-Release number of selected component (if applicable): F20 alpha: virt-manager-0.10.0-4.git79196cdf.fc20.noarch libvirt-client-1.1.3-2.fc20.x86_64 kernel-3.11.3-301.fc20.x86_64 qemu-kvm-1.6.0-9.fc20.x86_64 Steps to Reproduce: 1. virt-install with "--graphics none" and notice you don't get any output Actual results: No output. Additional info: This was a nested virt setup F19(L0) F20(L1) F20(L2). Problem observed when running virt-manager on L1 guest and attempting to add graphics to L2 guest.
IIUC, you shouldn't need todo this. If no graphics card is present, systemd is supposed to be automatically running a agetty on any text console that is present. So if that's not working, I think we might have a systemd unit file bug.
Yep. The systemd agetty part works just fine. I talked about this with Cole yesterday in the #fedora-test-day chat. What is desired here are the kernel/init/anaconda install messages to be sent to the serial device during install. A later discussion revealed that kernel arguments can only be appended in cases where we directly pass the kernel into qemu so that may be a limitation of this "feature" if we decide to implement it. Or we could engineer some way to somehow pass in kernel args even if we don't know which kernel is going to be run at the time of startup (this would probably take some qemu/kernel work and is off topic from this discussion).
Rather than trying to hack up the command line, which we might get in wrong in rare cases, I just added a bunch of stdout/stderr warnings if the graphics + console + extra-args combo doesn't look right.