Message-ID: <5a643fd6-1b1c-45ad-86a0-5d53f074d6f7@suse.com>
Date: Wed, 14 Jan 2026 09:33:23 +1030
From: Qu Wenruo <wqu@...e.com>
To: jollycar <jollycar@...ton.me>, Qu Wenruo <wqu@...e.com>
Cc: "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
 "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows
 installation on btrfs with kernels 6.18+ (works on 6.12 LTS)



在 2026/1/14 05:38, jollycar 写道:
> Thanks for the response.
> 
> Module installation: DKMS via the virtualbox-host-dkms package. The dkms status output confirms vboxhost/7.2.4_OSE is compiled for each kernel including the broken ones (6.18.3, 6.18.5 (tkg), 6.19.0-rc3).
> 
> Regarding CPU type specification:
> 
> VirtualBox doesn't have qemu-style CPU model selection. The --cpu-profile option only supports "host" (full passthrough) or ancient CPUs (8086/80286/80386) which don't meet Windows 10 requirements.
> 
> Additional testing: I recently upgraded my desktop pc from Ryzen 9 5900X to 9950X3D (reusing same disks and linux install) and the regression occurred identically on both CPUs. Also tested custom compiled TKG kernels (6.12/6.18 with bore scheduler). The behavior matches the Manjaro kernels exactly (6.12 works, 6.18 breaks).

Thanks for the extra info, I guess the last thing we can verify is, try 
to run the same VBox setup, using disk images from an EXT4/XFS.

And if that still failed, we're sure it's fs independent but more likely 
VBox dependent.

Thanks,
Qu

> 
> Regards,
> Jollycar
> 
> On Monday, January 12th, 2026 at 8:48 PM, Qu Wenruo <wqu@...e.com> wrote:
> 
>>
>>
>>
>>
>> 在 2026/1/13 02:03, jollycar 写道:
>>
>>> Qemu/libvirt test results on kernel 6.18.3:
>>>
>>> Setup:
>>> - Virtualization: qemu via libvirt (virt-manager)
>>> - Disk format: qcow2
>>> - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
>>> - COW disabled on disk image (chattr +C)
>>> - ISO: Same Windows 10 ISO used in VirtualBox tests
>>> - Guest: Windows 10
>>>
>>> Result:
>>> Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
>>>
>>> Summary of all tests on kernel 6.18.3:
>>> - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
>>> - Qemu via libvirt: No crashes, installation completes successfully
>>>
>>> Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.
>>
>>
>> Thanks a lot, this looks like there is something wrong related to the
>> VBox out-of-tree kernel module.
>> In that case, the btrfs community is not going to help much unfortunately.
>>
>> Mind to share how is the out-of-tree kernel module installed?
>> The pre-compiled one from the distro? The DKMS one or something else?
>>
>>
>> And just some guesses, can VBox specify what type of CPU (and extensions
>> like SSE/AVX) it uses?
>> If so (like qemu), mind to check if you can specify some CPU types
>> without some newer extensions while still meets the minimal CPU
>> requirement of Windows 10?
>>
>> I'm wondering if it's some extension handling not done properly, which
>> is commonly utilized by checksums.
>> Thus triggers the checksum mismatch errors inside Windows.
>>
>> Thanks,
>> Qu
>>
>>
>>> On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo wqu@...e.com wrote:
>>>
>>>> 在 2026/1/11 21:39, jollycar 写道:
>>>>
>>>>> Storage configuration details:
>>>>>
>>>>> Storage format: VDI (VirtualBox Disk Image)
>>>>> Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
>>>>
>>>> OK, this means it's not related to the direct IO changes in newer kernels.
>>>>
>>>> When COW is disabled, data checksum is also disables, thus direct IO is
>>>> still doing the true zero-copy behavior.
>>>>
>>>> This ruled out the btrfs direct io change, but this means I have no clue
>>>> what is going wrong at all now.
>>>>
>>>>> Controller: IntelAhci (SATA)
>>>>> Default configuration: hostiocache on, mtype normal
>>>>>
>>>>> Cache and media type testing on kernel 6.18.3:
>>>>> - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
>>>>> - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
>>>>> - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
>>>>>
>>>>> None of the configurations provide a working solution - they only delay the crash.
>>>>>
>>>>> On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
>>>>>
>>>>> I have not yet tested with qemu/libvirt. Should I proceed with that test?
>>>>
>>>> Yes please. Libvirt/qemu is a more common solution among developers.
>>>> If you can reproduce it using libvirt/qemu, more btrfs developers can
>>>> try to reproduce it and look into it.
>>>>
>>>> And if not, the cause may shift towards vbox other than btrfs.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>> On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@...e.com wrote:
>>>>>
>>>>>> 在 2026/1/11 20:33, jollycar 写道:
>>>>>>
>>>>>>> #regzbot introduced: v6.12..v6.18
>>>>>>>
>>>>>>> [1.] One line summary of the problem:
>>>>>>> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
>>>>>>>
>>>>>>> [2.] Full description of the problem:
>>>>>>> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
>>>>>>>
>>>>>>> [3] Kernel & Hardware:
>>>>>>> - Kernel versions tested:
>>>>>>> * Working: 6.12.63-1
>>>>>>> * Broken: 6.18.3-2, 6.19.0-rc3-1
>>>>>>> - Distribution: Manjaro Linux
>>>>>>> - Architecture: x86_64
>>>>>>> - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
>>>>>>>
>>>>>>> [4.] Filesystem and storage:
>>>>>>> - Root filesystem: btrfs on LUKS encryption
>>>>>>> - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>>>>>>> - VM storage: separate btrfs subvolume
>>>>>>
>>>>>> What's the storage file configuration? Like what's the cache mode setting?
>>>>>> I don't know VBox at all, but there may be something similar to
>>>>>> libvirt's cache mode (none/unsafe/writethrough etc).
>>>>>>
>>>>>> More importantly, will tweaking the cache mode change fix the broken
>>>>>> kernels?
>>>>>> If so it may point to direct IO related behavior changes.
>>>>>>
>>>>>> And what's the storage file format? QCOW2? RAW? Or whatever format
>>>>>> provided by Vbox?
>>>>>>
>>>>>> And one final question, have you tried qemu (or libvirt + qemu) and can
>>>>>> it still be reproduced with qemu?
>>>>>> As I'm wondering if the direct IO related change will even affects qemu
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>>> - btrfs device stats: all zeros (no errors)
>>>>>>>
>>>>>>> [5.] Reproduction:
>>>>>>> - Boot kernel 6.18.3-2 or 6.19.0-rc3
>>>>>>> - Start VirtualBox 7.2.4 r170995
>>>>>>> - Create new Windows 10 or Windows 11 VM
>>>>>>> - Begin OS installation
>>>>>>> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
>>>>>>> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
>>>>>>>
>>>>>>> Additional context:
>>>>>>> - Host system remains completely stable during VM crashes
>>>>>>> - No btrfs errors in dmesg or device stats (all zero)
>>>>>>> - Issue persists across multiple 6.18/6.19 releases over one month
>>>>>>> - VirtualBox 7.2.4 modules load successfully on all kernel versions
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jollycar
> 

Powered by blists - more mailing lists