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

[David Fernandez]

On 08/11/2021 20:50, Peter Maydell wrote:
> 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...

I'll try that and let you know...


>
>>>> 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.

Sorry, I missed that the version on fedora is 5.2.0 (re-sent the email 
but the list is slow).


>>
>>
>>> 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.

I believe I used to run without it... I'll recheck and confirm.


>
>>>> 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.

As noted above, I did not realize straight away that the fedora version 
is 5.2.0...

I'll try 5.2.0 first, then 6.1.0 (I tried master but the problem was 
still there).

Then I might do the newer guest version to see what happens.


> -- PMM