You are not logged in.
hi, I tried to launch previous android emulator I had setup in Virtual Disk emulator and using with VS Code/flutter
It failed to boot completly because it started to do heavy I/O and hit my SSD. Even letting it like that one hour, it gave nothing better. Still stuck at the "G".
I wiped my emulators, and started with a fresh one. It was the same.
On linux-zen, the heavy I/O was making using my desktop sometimes complicated.
I don't see anymore the warning about my GPU (UHD Graphics 630) when starting a emulator, so I forced a software renderer. that changed nothing.
I don't see anyhting when starting the emulator from cli. Seems like a loop
Is it gnome 49 or something like that. I didn't run that emulator for some time, so I can't pin point when it began to fail like that.
Still works from a live ubuntu
Offline
Your description doesn't give much to go on. Are there any logs created or echoed to the terminal? What tool is telling you it's I/O? If you check your processes with tools such as `top` or `htop`, is there a process pinned?
To isolate/eliminate GNOME as a culprit, have you tried running it from a simple WM? Use a newly created test user, to eliminate any auto-starting business that GNOME might have installed.
Offline
I didn't give because I had nothing to share. Nothing in system log. Even in logcat output via adb shell gives nothing that I see unusual, but that's hard to see from the sea of messages.
I tried with a new user on gnome and it was the same.
Not tested yet with another WM or desktop
The heavy I/O is visible because of the blinking led on the pc. and htop I/O tab is reporting a disk write for emualtor process going from 0 to 900Mb/s ina loop
Offline
So I managed to work around the problem by changing the default boot mode of the VM from quick to cold. That does not make any sense, because it was failing for the first boot of a new VM, so it should have been a cold boot anyway, right?
On the pixel 9a, I wasn't able to boot it. Now, with the changed setting it's OK.
For other VM model, the problem occurs more later after the boot, so changing the setting is still required for me, even if it boots correclty without, at first.
Offline