On Thu, 11 Nov 2021 at 12:45, David Fernandez <david.fernan...@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 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.) -- PMM
