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

[David Fernandez]

On 11/11/2021 13:42, Peter Maydell wrote:
> [No suele recibir correo electrónico de peter.maydell@linaro.org. Obtenga 
> información acerca de por qué esto es importante en 
> http://aka.ms/LearnAboutSenderIdentification.]
>
> On Thu, 11 Nov 2021 at 12:45, David Fernandez <david.fernandez@sen.com> wrote:
>> On 11/11/2021 11:23, Peter Maydell wrote:
>>>    The problem is that the
>>> udev machinery that creates nodes in /dev is being too slow
>>> (or possibly is failing for some other reason, but given all the
>>> other timeouts I'm guessing "everything is too slow") and so
>>> the systemd unit that is waiting for /dev/ttyS0 to be created
>>> times out.
>> What is a bit puzzling is that this is supposed to all run in an
>> emulated machine having its own simulated time, so yes things are slow,
>> but everything should happen as expected, just slowly.
> That's not the way QEMU's emulation of time works. In non-icount
> mode, which is the default, wall clock time in the VM follows
> wall clock time in the outside world. The guest just sees
> itself as running on a rather slow CPU (and one with some odd
> performance characteristics about what is slow compared to
> what other things).
I see... I wonder if a redhat system is likely to run better in such a
situation, or if any other debian/ubuntu distro is known to run better when
host performance might have an impact.

>> I guess I will compile from sources on Fedora and see if I get the same
>> problem, as it is a bit hard to believe that the only way to run qemu is
>> to have a high end machine dedicated just to run an install cd.
> There's probably something odd going on, it's just not clear
> what and trying to diagnose it is going to be really hard.
> It is the case that if the host system is underpowered then
> it's not going to be able to run complicated guests in
> an acceptably performant way, but that ought to apply more
> to situations like "I want to emulate a Windows guest on my
> first-generation raspberry pi".
>
> What does 'file' say about the QEMU binary you're running
> on the aarch64 system? (This is a check to eliminate an
> almost-certainly-not-the-problem theory.)
sen@vpm-devkit:~$ which qemu-system-x86_64
/usr/local/bin/qemu-system-x86_64
sen@vpm-devkit:~$ file /usr/local/bin/qemu-system-x86_64
/usr/local/bin/qemu-system-x86_64: ELF 64-bit LSB shared object, ARM 
aarch64, version 1 (GNU/Linux), dynamically linked, interpreter 
/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, 
BuildID[sha1]=e05b26921bd35d96b6c749d23d5bfa5e6e43ab4c, stripped

> -- PMM