Dear Maintainer,
When trying to run Debian Trixie as a guest OS in a VM, I ran into major issues
that make Trixie unusable in a virtualized environment.
I am using Debian Trixie as a host (same as guest) and VirtualBox 7.2 available
in Trixie repositories. I created a new virtual machine, selected
debian-13.1.0-amd64-netinst.iso as the installation media (obtained from debian
servers, MD5: a9d5c5778f6e228af1e462d717a6d544), and performed a basic Trixie
installation in text mode. I went with a single-partition installation with no
desktop environment; during the Software selection step I only selected "SSH
server" and "standard system utilities". After the installation I added a
handful of tools such as aptitude, mc, emacs-nox, vim and htop. Essentially, it
is a text-only environment that I want to be able to SSH into.
However, the guest system is highly unstable. Usually, after a couple of
minutes of uptime, it becomes unresponsive with kernel errors being reported on
TTY1:
[ 325.455294] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 325.455336] rcu: 9-...!: (1 ticks this GP) idle=a678/0/0x0 softirq=1084/1085 fqs=0 (false positive?)
[ 325.455356] rcu: 10-...!: (19 ticks this GP) idle=8460/0/0x0 softirq=821/823 fqs=0 (false positive?)
[ 325.455382] rcu: 13-...!: (0 ticks this GP) idle=2fe0/0/0x0 softirq=687/687 fqs=0 (false positive?)
[ 325.455399] rcu: 15-...!: (0 ticks this GP) idle=3bf0/0/0x0 softirq=1160/1160 fqs=0 (false positive?)
[ 325.455416] rcu: (detected by 7, t=5260 jiffies, g=11081, q=2672 ncpus=16)
Detailed call traces van be found in dmesg:
[ 325.455437] Sending NMI from CPU 7 to CPUs 9:
[ 325.455458] NMI backtrace for cpu 9
[ 325.455462] CPU: 9 UID: 0 PID: 0 Comm: swapper/9 Not tainted 6.12.48+deb13-amd64 #1 Debian 6.12.48-1
[ 325.455465] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 325.455467] RIP: 0010:pv_native_safe_halt+0xf/0x20
[ 325.455478] Code: 09 e9 50 bd 20 00 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 05 29 31 00 fb f4 <e9> 27 bd 20 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[ 325.455479] RSP: 0018:ffffb5d6c010bed8 EFLAGS: 00000202
[ 325.455482] RAX: 0000000000000009 RBX: ffff9c92409d0000 RCX: ffff9c924b148860
[ 325.455484] RDX: 0000000000000000 RSI: 0000000000000009 RDI: 00000000000da674
[ 325.455485] RBP: 0000000000000009 R08: 0000000000000001 R09: 0000000000000001
[ 325.455486] R10: 0000000000000009 R11: 0000000000000001 R12: 0000000000000000
[ 325.455487] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 325.455488] FS: 0000000000000000(0000) GS:ffff9c99b4480000(0000) knlGS:0000000000000000
[ 325.455490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 325.455499] CR2: 00007f0c46000010 CR3: 0000000108326000 CR4: 00000000000506f0
[ 325.455502] Call Trace:
[ 325.455510] <TASK>
[ 325.455511] default_idle+0x9/0x20
[ 325.455521] default_idle_call+0x29/0x100
[ 325.455523] do_idle+0x1fe/0x240
[ 325.455538] cpu_startup_entry+0x29/0x30
[ 325.455540] start_secondary+0x11e/0x140
[ 325.455551] common_startup_64+0x13e/0x141
[ 325.455557] </TASK>
I will attach full dmesg log in a follow-up email.
I attempted to resolve the problem by changing the default virtual machine
settings, in particular:
- enabling PAE/NX
- enabling Nested VT-x/AMD-V
- disabling Nested Paging
- changing the graphics controller
- installing VirtualBox Guest Addons inside the guest OS
None of these changes had any effect.
At this point, Debian Trixie seems unusable with VirtualBox. I will attempt to
create a Trixie VM with QEmu and see whether that works. I also note, that on
the same host machine I have a Debian Buster virtual machine running under
VirtualBox without any issues. Lastly, I managed to report the bug from inside
the VM, so information that follows is accurate w.r.t. the problematic guest
system.
Please let me know if any further details are required.
Best regards,
Janek