Intermittent Boot Freeze after Cryptsetup – Related to VirtualBox Module?

[debianix]

Hi everyone,

I'm using MX Linux with a fully encrypted root partition, and I’ve been running into the following issue:

=== The Problem ===
Roughly 1 out of every 20 boots, the system freezes right after decrypting the root partition. I see the usual message:

cryptsetup: cryptsetup successfully initialized

…but then nothing happens. The system just hangs.
Only a forced shutdown (holding the power button) helps. The next boot always works fine.

=== Diagnostics So Far ===

No critical errors related to cryptsetup in dmesg, fsck.log, or boot.log.

Normal fscrypt and cryptd messages appear during a successful boot.

One consistent warning I do see is:

vboxdrv: module verification failed: signature and/or required key missing - tainting kernel

(Note: Secure Boot is not enabled.)

=== What I’ve Tried ===

Reinstalled virtualbox-dkms

Manually unloaded vboxdrv, vboxnetflt, vboxnetadp in correct order

Checked /etc/modules – no vboxdrv entry

Disabled hardware acceleration in Chromium due to occasional typing lag

Considered removing VirtualBox entirely, and maybe move to virt-manager..

=== My Use Case ===
I only use VirtualBox to maintain a clean snapshot of MX Linux as a "clean-system-backup", which I occasionally boot to update and in case I need it some day, I convert into a live USB with persistence via MX Snapshot and Live USB Maker. I rarely run VMs otherwise, sometimes I test fancy stuff or other distros there but very rare, as Im very happy with MX and doesnt want to change :)

=== My Question ===

Has anyone else experienced a freeze right after cryptsetup initialization?

Could vboxdrv or other VirtualBox components cause this with an encrypted root setup?

Any known VirtualBox issues on MX Linux using SysVinit?

Any other ideas what might cause this behavior? I'd appreciate any thoughts on this..

Code: Select all

Snapshot created on: 20250123_2022
System:
  Kernel: 6.1.0-37-amd64 [6.1.140-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/vmlinuz-6.1.0-37-amd64 root=UUID=<filter> ro quiet splash
    resume=UUID=<filter> resume_offset=626688
  Desktop: KDE Plasma v: 5.27.5 wm: kwin_x11 vt: 7 dm: SDDM Distro: MX-23.6_KDE_x64 Libretto May
    19 2024 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Desktop Mobo: Gigabyte model: B560M DS3H V2 serial: <superuser required> UEFI: American
    Megatrends LLC. v: F11 date: 12/19/2023
CPU:
  Info: model: 11th Gen Intel Core i7-11700 bits: 64 type: MT MCP arch: Rocket Lake gen: core 11
    level: v4 note: check built: 2021+ process: Intel 14nm family: 6 model-id: 0xA7 (167) stepping: 1
    microcode: 0x64
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache: L1: 640 KiB
    desc: d-8x48 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 800 high: 801 min/max: 800/4800:4900 scaling: driver: intel_pstate
    governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 9: 801 10: 800
    11: 800 12: 800 13: 800 14: 800 15: 801 16: 800 bogomips: 79872
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling mitigation: Microcode
  Type: indirect_target_selection mitigation: Aligned branch/return thunks
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed mitigation: Enhanced IBRS
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Enhanced / Automatic IBRS; IBPB: conditional; PBRSB-eIBRS: SW
    sequence; BHI: SW loop, KVM: SW loop
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Navi 23 WKS-XL [Radeon PRO W6600] vendor: Dell driver: amdgpu v: kernel
    arch: RDNA-2 code: Navi-2x process: TSMC n7 (7nm) built: 2020-22 pcie: gen: 4 speed: 16 GT/s
    lanes: 16 ports: active: DP-1,DP-2 empty: DP-3,DP-4 bus-ID: 03:00.0 chip-ID: 1002:73e3
    class-ID: 0300
  Device-2: AIRHUG 02 type: USB driver: uvcvideo bus-ID: 3-4:4 chip-ID: 2f9d:1101 class-ID: 0e02
    serial: <filter>
  Device-3: RODE Microphones RØDE VideoMic GO II type: USB
    driver: hid-generic,snd-usb-audio,usbhid bus-ID: 5-4:2 chip-ID: 19f7:001c class-ID: 0300
    serial: <filter>
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 5120x1440 s-dpi: 96 s-size: 1354x381mm (53.31x15.00")
    s-diag: 1407mm (55.38")
  Monitor-1: DP-1 mapped: DisplayPort-0 pos: primary,left model: AOC AG275QZN serial: <filter>
    built: 2024 res: 2560x1440 hz: 240 dpi: 109 gamma: 1.2 size: 597x336mm (23.5x13.23")
    diag: 685mm (27") ratio: 16:9 modes: max: 2560x1440 min: 720x400
  Monitor-2: DP-2 mapped: DisplayPort-1 pos: right model: AOC AG275QZN serial: <filter>
    built: 2024 res: 2560x1440 hz: 240 dpi: 109 gamma: 1.2 size: 597x336mm (23.5x13.23")
    diag: 685mm (27") ratio: 16:9 modes: max: 2560x1440 min: 720x400
  API: OpenGL v: 4.6 Mesa 25.0.4-1~mx23ahs+1 renderer: AMD Radeon Pro W6600 (radeonsi navi23
    LLVM 15.0.6 DRM 3.49 6.1.0-37-amd64) direct-render: Yes
Audio:
  Device-1: AMD Navi 21/23 HDMI/DP Audio driver: snd_hda_intel v: kernel bus-ID: 3-2:2 pcie: gen: 4
    chip-ID: 0d8c:0014 class-ID: 0300 speed: 16 GT/s lanes: 16 bus-ID: 03:00.1 chip-ID: 1002:ab28
    class-ID: 0403
  Device-2: C-Media Audio Adapter (Unitek Y-247A) type: USB
    driver: cmedia_hs100b,snd-usb-audio,usbhid
  Device-3: RODE Microphones RØDE VideoMic GO II type: USB
    driver: hid-generic,snd-usb-audio,usbhid bus-ID: 5-4:2 chip-ID: 19f7:001c class-ID: 0300
    serial: <filter>
  API: ALSA v: k6.1.0-37-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet vendor: Gigabyte
    driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 06:00.0
    chip-ID: 10ec:8168 class-ID: 0200
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 3.17 TiB used: 1.82 TiB (57.5%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 970 EVO Plus 1TB size: 931.51 GiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 2B2QEXM7 temp: 41.9 C scheme: GPT
  ID-2: /dev/nvme1n1 maj-min: 259:1 vendor: Samsung model: SSD 970 EVO Plus 2TB size: 1.82 TiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 2B2QEXM7 temp: 43.9 C scheme: GPT
  ID-3: /dev/sda maj-min: 8:0 vendor: Kingston model: SA400S37480G size: 447.13 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 60.1 scheme: GPT
Partition:
  ID-1: / raw-size: 68.34 GiB size: 66.72 GiB (97.62%) used: 36.86 GiB (55.2%) fs: ext4
    dev: /dev/dm-0 maj-min: 253:0 mapped: luks-<filter>
  ID-2: /boot raw-size: 1024 MiB size: 973.4 MiB (95.06%) used: 281.8 MiB (29.0%) fs: ext4
    dev: /dev/nvme0n1p2 maj-min: 259:3
  ID-3: /boot/efi raw-size: 1024 MiB size: 1022 MiB (99.80%) used: 288 KiB (0.0%) fs: vfat
    dev: /dev/nvme0n1p1 maj-min: 259:2
  ID-4: /home raw-size: 861.14 GiB size: 846.54 GiB (98.31%) used: 275.07 GiB (32.5%) fs: ext4
    dev: /dev/dm-2 maj-min: 253:2 mapped: luks-<filter>
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 8 GiB used: 0 KiB (0.0%) priority: -2 file: /swap/swap
Sensors:
  System Temperatures: cpu: 36.0 C mobo: N/A gpu: amdgpu temp: 55.0 C mem: 58.0 C
  Fan Speeds (RPM): N/A gpu: amdgpu fan: 1443
Repos:
  Packages: 3287 pm: dpkg pkgs: 3265 libs: 1766 tools: apt,apt-get,aptitude,nala,synaptic pm: rpm
    pkgs: 0 pm: flatpak pkgs: 22
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm main non-free
    2: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm ahs
  Active apt repos in: /etc/apt/sources.list.d/syncthing.list
    1: deb https://apt.syncthing.net/ syncthing stable
Info:
  Processes: 374 Uptime: 23m wakeups: 1 Memory: 31.24 GiB used: 4.72 GiB (15.1%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

[atomick]

Question: Could vboxdrv with encrypt system disk cause issue - 1st would say no every in order would be as boot listed sequences process each line at a time and script start up at a time.
the question about find re " vboxdrv: module verification failed: signature and/or required key missing - tainting kernel "
to me seems the problem as to stopping to a blank screen in booting complete thru to desktop.

How did you Install VirtualBox and is this MX-Program selected installed via program-manager
or did you install via the steps and process usually written out covering most distros on the virtualbox.org web site

this could refer also to a setting to check as discussed other VBox users issues as too MX-Tweaks top right tab "Other" And adding in the check for pre KVM loading to kernel checked in box.
one other item and some can bypass this step as too Adding the GPG keys given string in Description given for version of VBox your installing and working with.
something like

Code: Select all

sudo gpg --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --dearmor oracle_vbox_2016.asc
2 files I make sure present are . 
oracle-virtualbox-2016.gpg
oracle_vbox_2016.asc
present in the install directory your adding VBox version from if downloaded via web.   
one other I have also added for my own success  is
oracle_vbox_2016.fingerprint  also present. 

as many outside pkg from MX-own package installer can be daunting to its essentials to understand requirements when and by how its language expressing the steps
to getting it right. Details can set one off into another world all together. without rightful examples per each platform expecting zero issue as "Tainted Kernel "
suggests something is incorrect. As found per suggested to another post now showing solved. was as Charles suggest to remove what version VBox current. Use MX-Package installer and install MX version of VBox, Remove it and re-install your VBox newer version from there

not sure I get this right but the Oracle "Pula license" for Personal User support and gpg keys might tie together , something missing here might create your symptom.

[CharlesV]

The two suggestions I gave and you might try here are:

1) Uninstall Virtualbox, reboot and see if your still seeing the issues.
and
2) For later kernels, the VirtualBox version in the test repo is the one that works the best. (Liquorix kernels 6.12 and 6.14 ) - this is what solved that other thread.

The other possibility, is to install the Virtual box directly from The Oracle site and try that. ( https://www.virtualbox.org/wiki/Downloads ) VirtualBox IS one of the packages I do install from outside the MX repos - only for the latest kernels. And I use VM's heavily. (as in 3 and 4 running all the time.)

[debianix]

Right now I use Kernel 6.1.0-37-amd64 [6.1.140-1] and everything fine so far except that boot thing that happens occasionally (about every 20th boot or so, but still annoying)

Until now I had always installed VirtualBox over MXPI, because I thought this is always the preferred way within the MX universe :-) I would love to stick to that procedure in the future especially because of the automatic updates.

Maybe another way:
Since you say that it might work via the MX test repos, maybe I should just remove VirtualBox for now and see if the problems persist, and as soon as the new MX Linux main version is released, I'll install it again via MXPI (until then the test repos should have become the stable repos?) and maybe the problems will have disappeared?

Or another option, maybe switch completely to virt-manager, would that be a safer alternative to be completely independent of this vboxdrv module?

As I said, I installed VirtualBox via MXPI, but I'm surprised that when I look in MXPI now and check the box for VirtualBox, the “Uninstall” button is not clickable... shouldn't that be the case if it was installed via MXPI? At least, that's how I know it...
Would the correct way to uninstall it then be
“sudo apt purge virtualbox virtualbox-dkms”
or how would you remove it completely?
And I assume that I probably can't just continue to use my VirtualBox machines in virt-manager...?

I don't really need VirtualBox at the moment, but I would like to have my “backup machine” and a machine to play around with ready in case I need it or want to test something. But maybe virt-manager (libvirt) would be sufficient for this? I would then install it via MXPI...

I'm very excited to hear your recommendations :-)

[DukeComposed]

I don't really need VirtualBox at the moment, but I would like to have my “backup machine” and a machine to play around with ready in case I need it or want to test something

I don't think it's the VirtualBox kernel module. The message about tainting the kernel is a fairly benign one and I usually see it in projects that involve non-GPL software. I build ZFS kernel modules regularly and the unique ZFS software license means that the kernel taint warning gets shown briefly on startup. It does not negatively affect the boot process. Similarly, VirtualBox is an Oracle project and they aren't big fans of non-proprietary licenses. You can uninstall the VirtualBox packages without deleting any of your VMs and reboot a few times to confirm that (a) the VirtualBox modules are gone and (b) that the startup problem still occurs. My first thought when a system hangs is that the initramfs needs to be remade, but I'd try to only make one change at a time in diagnosing the root cause of the matter.

[debianix]

Thanks again to all of you for your detailed replies – it really helps to get different perspectives on the issue.

Here's what I'll do next, based on your input / what I have understood so far:

Step 1: Remove VirtualBox completely
Since I currently don't need it, and there's a chance it might be related to the intermittent boot issue, I'll remove it entirely:

Code: Select all

sudo apt purge virtualbox virtualbox-dkms
sudo apt autoremove --purge

Then I'll reboot the system several times over the next days to check if the issue still happens. Probably its best to wait at least 1 month or a bit longer because that was the probably longest period... I didnt document the problem so detailed when it comes to the time.


Step 2: Rebuild initramfs
(if issue persists)
If the boot problem still occurs after removing VirtualBox, the next step will be to rebuild the initramfs, in case it's corrupted or incomplete:

Code: Select all

sudo update-initramfs -u -k all

I'll do this only after ruling out VirtualBox as the cause, to keep the troubleshooting clean and one step at a time.

Step 3: If necessary – consider switching to virt-manager
If I find out that VBox was part of the problem (or I just want a cleaner solution going forward), I’ll likely switch to virt-manager and use that for my occasional snapshot/testing needs.

I'll report back with results as I go – thanks again for all your help so far!

[DukeComposed]

Step 2: Rebuild initramfs[/b]
(if issue persists)
If the boot problem still occurs after removing VirtualBox, the next step will be to rebuild the initramfs, in case it's corrupted or incomplete:

You may want to update your grub config before trying anything else:

Code: Select all

Snapshot created on: 20250123_2022
System:
  Kernel: 6.1.0-37-amd64 [6.1.140-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/vmlinuz-6.1.0-37-amd64 root=UUID=<filter> ro quiet splash

Whenever I'm having boot problems, turning off the "quiet" and "splash" options may help you debug the source of the problem. I would start with removing "quiet" and testing it first, then possibly changing "splash" to "nosplash" if need be.

[CharlesV]

I think your on the right track with your steps and what Duke proposed too. Give your self enough time to thoroughly test each step, excellent methods to debug this:-)

[debianix]

alright thank you so much! Then I will leave virtualbox as it is for now, I was so used to having "splash" and "quiet" activated that I didnt even consider that as an option...
So I replaced those words with "nosplash" and planning to do nothing more right now... just wait till the problem occurs again, and then hopefully being able to take a picture of the log during the freeze.
Will be back in that thread as soon as the problem occurs again, to find out which of the advised steps make the most sense then :-)
endlessly grateful for ur help, god bless mx linux and its community :-)