qemu: Put console on hvc0 in addition to ttyS0, and root shell on hvc1 in addition to ttyS1

Our use of ttyS0 and ttyS1 was a PC-centric design that turns out not to extend well to non-x86 emulated hardware.

---

• !116 (merged) (see that MR for details)

• setup-testbed: Make sure /etc/init.d/ exists

  It probably will, but it seems better to be sure.

• setup-testbed: Put root shells on both ttyS1 and hvc1 if they exist

  ttyS1 is PC-specific (it's the second serial port of qemu's emulation of the IBM PS/2's 16550 UART), whereas hvc1 is more hardware-agnostic (it's the second virtio serial console). There's no reason why we need to choose one or the other - we can have both.

  In particular, Ryutaroh Matsumoto reports that the ARM and ppc64el machines emulated by qemu only have one serial port available via the -serial option (ttyAMA0 or hvc0 respectively), so we cannot rely on the second serial port.

  I'm not using hvc0 (the first virtio serial console) for this special purpose, because it's a sensible place to put a Linux console and an ordinary getty on any architecture, and in particular the serial port of the default machine emulated by qemu-system-ppc64le (used for boot messages and the Linux console) shows up as /dev/hvc0 inside the VM. Accordingly, reserve hvc0 for either the Linux console or a placeholder, and start from hvc1 for these autopkgtest-specific shells.

  Under systemd, we do this with an instanced unit that automatically disables itself via a Condition if the referenced device doesn't exist. similar to the previous autopkgtest.service that hard-coded ttyS1.

  Under sysvinit, we just start them all in a loop (untested, I'm not running sysvinit on any test VMs in practice).

• autopkgtest-build-qemu: Load virtio_console in the initramfs

  This is a workaround for it not being built-in (#689962). If we don't load virtio_console early, it won't be detected before systemd-getty-generator(8) runs, so we won't automatically get a getty prompt on it.

• setup-testbed: Put Linux console on all the usual console ports

  Linux console logging can be directed to any number of devices, so let's send it to all of:

  • the first emulated hardware serial port, ttyS0 (x86) or ttyAMA0 (ARM)
  • the first hypervisor virtual console, hvc0 (qemu, Xen, PowerPC)
  • whichever graphical virtual terminal is in the foreground, tty0 (this is unnecessary for autopkgtest itself, but is convenient if you want to boot an autopkgtest VM image interactively)

  systemd should automatically start an interactive getty on each of these via systemd-getty-generator(8).

  sysvinit will not do that without further configuration, but that isn't a regression: it already needed special configuration to put a serial getty on ttyS0.

• virt-qemu: Create serial devices for /dev/hvc0, /dev/hvc1

  Instead of assuming all virtual machines have two PS/2-style serial ports, try to use the hypervisor virtual console interface on /dev/hvc1 for our root shell, falling back to ttyS1 if that wasn't set up. As before, reserve /dev/hvc0 for a Linux console and login prompt.

  One oddity here is that in the default configuration of qemu-system-ppc64le, the serial port is itself considered to be a hypervisor virtual console and shows up as /dev/hvc0 inside the VM, so we only need to create one virtio-serial device to get /dev/hvc1.

  Based on a patch from Ryutaroh Matsumoto.