When running with RMC under qemu (for example, runqemu refkit-image-common wic intel-corei7-64), there is no output to the serial console because the boot parameters contain no console=ttyS0. This might be a IoT Refkit specific thing, because refkit.conf currently removes console=ttyS0,115200 from APPEND. I'm not sure what the log-term plan is regarding ttyS0 (always enable it, enable it only when RMC is not active with/without default in RMC database). Besides adding ttyS0 for this kind of virtual machine it might also be necessary (or even useful) to also add ttyS1, because if I'm not mistaken, automated testing with imagetest.bbclass relies on a console prompt on the second serial console. If someone happens to look at that in the context of refkit, perhaps also check whether we use correct SERIAL_CONSOLE settings. We currently have: /lib/systemd/system/getty.target.wants: serial-getty@ttyS0.service serial-getty@ttyS1.service serial-getty@ttyS2.service I think that's causing problems (like restarts of getty and noise in the log) when there aren't that many serial devices - not sure, haven't investigated.
There's one additional, potentially related issue: debug output and the interactive shell prompt from the initramfs are never (?) connected to the serial console. To reproduce, add APPEND_append = " shell-debug" to local.conf, rebuild, and "runqemu nographic serial refkit-image-common wic intel-corei7-64". One should see debug output from the initramfs, but it is only visible when running with graphic and connecting to the VNC graphical console.
I've submitted https://github.com/intel/intel-iot-refkit/pull/80 adding qemu v2.6 and v2.8 to RMC DB. With the patch applied initramfs's debug output becomes visible as well as kernel and systemd's startup output. The issue with restarting getty deserves a separate bug IMHO. SERIAL_CONSOLES is defined in meta-intel for all intel-corei7-64 builds as > SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2" whereas the qemux86-64 machine defines (in meta/conf/machine/qemux86-64.conf) > SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1". If we want to get rid of the unneeded console for intel-corei7-64 under QEMU we need to make RMC not ignore POSTINSTALL.sh for QEMU "boards". For that, I guess, we need either to switch from initramfs-framework to initramfs-live-install-efi (RMC extends it to accommodate POSTINSTALL.sh and some other quirks) or to update RMC to use initramfs-framework.
(In reply to comment #0) > This might be a IoT Refkit specific thing, because refkit.conf currently > removes console=ttyS0,115200 from APPEND. I'm not sure what the log-term > plan is regarding ttyS0 (always enable it, enable it only when RMC is not > active with/without default in RMC database). ttyS0 has to be removed because with 'console=ttyS0,115200' we'd loose boot logs on 570x that has serial console in ttyS2 (two ttySx in console= is not possible). This is important from CI (and also from debugging) perspective. > If someone happens to look at that in the context of refkit, perhaps also > check whether we use correct SERIAL_CONSOLE settings. We currently have: > /lib/systemd/system/getty.target.wants: > serial-getty@ttyS0.service serial-getty@ttyS1.service > serial-getty@ttyS2.service These come from refkit_image_system_serialgetty; and SERIAL_CONSOLES in meta-intel. With this bug fixed, could we set ttyS0 and ttyS1 for qemu boards in the RMC db, rely on systemd-getty-generator and not use refkit_image_system_serialgetty; anymore.
(In reply to comment #3) > > If someone happens to look at that in the context of refkit, perhaps also > > check whether we use correct SERIAL_CONSOLE settings. We currently have: > > /lib/systemd/system/getty.target.wants: > > serial-getty@ttyS0.service serial-getty@ttyS1.service > > serial-getty@ttyS2.service > > These come from refkit_image_system_serialgetty; and SERIAL_CONSOLES in > meta-intel. Thanks for reminding me. I wrote that and already forgot that I had ;-} > With this bug fixed, could we set ttyS0 and ttyS1 for qemu boards in the RMC > db, rely on systemd-getty-generator and not use > refkit_image_system_serialgetty; anymore. It's worth trying. However, I left a comment above refkit_image_system_serialgetty saying: # Defining serial consoles via the "console" boot parameter only works # for at most one console. Documentation/serial-console.txt explicitly # says "Note that you can only define one console per device type # (serial, video)". # # So for images where we need more than one console, we have to # configure systemd explicitly. We cover all consoles, just to be # on the safe side (can't know for sure which of these are also # given via "console" boot parameter). That sounds like the systemd generator looks at what the kernel uses, not what was specified in the boot parameters.
(In reply to comment #4) > > That sounds like the systemd generator looks at what the kernel uses, not > what was specified in the boot parameters. Yes, now I remember. It reads from /sys/class/tty/console/active.
I guess this bug can be closed now.
RMC DB has got records needed for QEMU and the output is visible in the serial console.