Re: Guest Ubuntu 18.04 fails to boot with -serial mon:stdio, cannot find ttyS0.

[Peter Maydell]

On Mon, 8 Nov 2021 at 20:22, David Fernandez <david.fernandez@sen.com> wrote:
>
> Hi Peter,
>
> Answers in line.
>
> On 08/11/2021 19:59, Peter Maydell wrote:
> > On Mon, 8 Nov 2021 at 18:05, David Fernandez <david.fernandez@sen.com> 
> > wrote:
> >> I am running qemu-system-x86_64 on aarch64 running Ubuntu 18.04 as both
> >> guest and host.
> >>
> >> I couldn't get the stock qemu-system-x86_04 to boot correctly, as it was
> >> an old version 2.11.1, I decided to recompile from sources to see if
> >> that would fix the problem, but the problem still persists, using both
> >> top of master and stable-2.12 (currently on that).
> >>
> >> [ TIME ] Timed out waiting for device dev-ttyS0.device.
> > Is there any more error message ? How long does the guest wait on
> > this step before it times out ?
> The guest waits at the end forever... probably because it tries to use the
> normal console instead and that does not get displayed with my options.
>
> These are all the services that fail:
>
> [ TIME ] Timed out waiting for device dev-ttyS0.device.
> [DEPEND] Dependency failed for Serial Getty on ttyS0.
> ...
> [FAILED] Failed to start Dispatcher daemon for systemd-networkd. <==
> network does start fine though.
> See 'systemctl status networkd-dispatcher.service' for details.
> ...
> [FAILED] Failed to start Wait until snapd is fully seeded. <== snapd
> runs fine though.
> See 'systemctl status snapd.seeded.service' for details.
> ...
> [FAILED] Failed to start Holds Snappy daemon refresh.
> See 'systemctl status snapd.hold.service' for details.
> [  OK  ] Started Update UTMP about System Runlevel Changes.
> ... waits forever ...

This does sound like a lot of things might be timing out, not just
the "wait for the serial port" part. OTOH the host CPU is supposed to be
2.26GHz so it shouldn't really be having that much trouble (assuming
you aren't heavily loading the host with other stuff!).

There used to be a bug years back where a bug in a guest udev
rule meant that the guest would spawn a lot of processes in a way
that was invisible for running on real hardware but was just enough
extra load to make the slower emulated setup timeout in various
ways including that "Timed out waiting for device" error:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1615021
But I think that should have been fixed by 18.04. You might try
a 20.04 Ubuntu guest just in case, I guess...

> >> The problem does not happen when using qemu-system-x86_64 on my Fedora
> >> desktop as host, so I wonder if I need something in my build options or
> >> if I need to rebuild my kernel with some added kernel configuration
> >> options...
> > Are you testing with the exact same:
> >   * command line
> >   * files (guest kernel, initrd, iso, etc)
> >   * QEMU version
> > on both the aarch64 and x86-64 host ?
>
> Yes.
>
>
> > Does the x86-64 host still work OK if you run it with KVM turned off
> > (ie matching the aarch64 host setup) ?
>
> Have not tried that... is there an easy way/option to run that test? Or
> do I need
> to compile from sources in Fedora?

As long as your QEMU commandline doesn't have -enable-kvm or any
other kvm-related option in it it should default to emulation.

> >> Hopefully, some experts around here can help me with that if it is a
> >> known thing (I google around but other than mentioning that 2.11 is too
> >> old, could not find any clear reason about this problem).
> > For aarch64 host, I would be a bit dubious about running 2.11 or 2.12 --
> > they are both absolutely ancient in QEMU terms.
> Is there a specific branch I should use? Could not see more than 2.12 in
> git.qemu.org regarding stable branches, but happy to compile and try any
> other.

We switched some time ago to using tags rather than branches;
you could use the v6.1.0 tag for the most recent release, or
master for bleeding-edge.

-- PMM