On 08/11/2021 20:50, Peter Maydell wrote: > On Mon, 8 Nov 2021 at 20:22, David Fernandez <david.fernan...@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.fernan...@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
