#1079064 debvm-run armhf on WSL is stucks in multi_cpu_stop

Package:
debvm
Source:
debvm
Submitter:
Vasyl Vavrychuk
Date:
2025-03-31 16:03:01 UTC
Severity:
normal
Tags:
#1079064#5
Date:
2024-08-19 16:29:37 UTC
From:
To:
Dear Maintainer,

I create VM

  debvm-create -r stable -- --architectures=armhf

I run it

  debvm-run

but run stucks in kernel crashing in multi_cpu_stop (see attached debvm-
run.txt).

Note, this problem is reproducible only if host Debian is run using WSL. If I
run host Debian natively on the same machine, then debvm for armhf works fine.

Also, x86 debvm on WSL works fine too.
#1079064#10
Date:
2024-08-19 18:03:53 UTC
From:
To:
Control: retitle -1 debvm-run armhf on WSL is stucks in multi_cpu_stop
Control: tags -1 + unreproducible

Thank you for the report along with good detail. Given that reproducing
the bug requires the use of non-free software, I do not intend to work
on it. For this reason, I am marking it as unreproducible.

If you or someone else wants to work on it, please mark your self as
owner of the bug. I expect that this is not a bug in debvm, but in some
other component (e.g. linux or qemu). Please reassign as appropriate and
remove the unreproducible tag once it is better understood.

Helmut
#1079064#19
Date:
2024-08-22 12:27:11 UTC
From:
To:
I have reproduced a similar (I guess) issue when running Debian
natively (without WSL). For that, I first run x86 VM, but ensure it
has enough disk and memory:

debvm-create --release=stable --size=5T
debvm-run -- -m 2G

Then, from x86 VM I create and run arm VM similarly to how I do this from WSL:
debvm-create -- --architectures=armhf && debvm-run

I observed multiple backtraces printed from the kernel (debvm-run.log
attached) and could not reach the console.

Experimentally, I found this can be worked around by passing fewer CPUs to QEMU:
debvm-run -- -smp 7 - is enough on native Debian > x86 debvm
debvm-run -- -smp 4 - is needed on WSL

(I have 8 cores in total)
#1079064#24
Date:
2025-03-31 15:27:41 UTC
From:
To:
Would you be able to retry this on debvm 0.3.2 (just uploaded to
unstable, but you may run from git if you prefer)?

I'm asking you to retry, because we have an arm32-specific failure where
dracut-install would fail to include virtio_blk.ko in the initramfs due
to a bug in glibc fts or dracut's use of it. In order to trigger this
bug, the inodes of files created by debvm-create need to exceed 32bit.
On a typical tmpfs that would only happen after creating 2 billion
files, but maybe the WSL environment provides large inodes to trigger
this bug. Since fixing the root cause is quite difficult, debvm now
includes a workaround for the particular problem. The reported symptom
is somewhat different and the messages about virtio-pci also hint at a
different issue, but maybe we are lucky?

Thanks in advance

Helmut