Manjaro 26.0.1 as a VirtualBox virtual machine hangs shortly after startup

Bernmeister · 24 January 2026 00:27

I have installed Manjaro 26.0.1 KDE Plasma as a virtual machine using VirtualBox 7.2.4 r170995 on Debian 13 (64 bit) as host. The VM attributes I chose are

OS Type: ArchLinux
RAM: 4096 MB
HDD: 20 GB

When I boot up Manjaro, all seems well (the desktop and startup window appears and I can interact with the desktop with the mouse). After a couple of minutes, the desktop hangs and becomes unresponsive. I notice my physical hard drive activity light blinks quite a bit as does the virtual hard drive light in the status bar of VirtualBox.

The only way out is to close the VirtualBox window and force a shutdown.

I did try to install Guest Additions (there is an Upgrade menu option), but that failed and I was unable to capture the error message. Regardless, just booting the VM to the desktop will hang after a couple of minutes.

Any ideas please?

Molski · 24 January 2026 01:48

Can you post your guest configuration? (The whole xml file in a code block.)

I am more of a qemu person myself, but I know Manjaro works fine in both.

One thing you would most likely want to change, and may have to do with the hyperactive disk I/O, is installing Manjaro to ext4 instead of btrfs, which is the new default for Manjaro.

I am also a huge btrfs advocate and fan! But on bare metal (or on the host).

This is just a virtualisation thing with CoW file systems in general. In any OS, even Windows. You lose many of the benefits of CoW when it’s inside a virtual drive. So best to avoid it unless you know what you are doing. (And if you have CoW on CoW, it’s even worse!)

Aragorn · 24 January 2026 04:58

The general advice is to disable copy-on-write on the virtual machine images.

Molski · 24 January 2026 06:36

(I’m still woozy from anesthetic so hopefully I can articulate!)

You can mount it with nodatacow, but this only affects the data part of the file system.

btrfs metadata still runs the same way as before. And depending on what you are doing, and how you set up your disk(s), this can be a bottleneck and/or cause extra overhead.

If you are using the default thinly provisioned disks (which are CoW by nature), you now have CoW on CoW for metadata.

I do use btrfs in VMs quite a bit actually on many mediums, and it works. But it can be much slower, especially with random I/O, and even with nodatacow.

You can alleviate a lot of this I with pre-allocation (or raw images). And they feel somewhat closer to native performance.

(And there are a few cases where I want snapshots and/or checksumming inside my guests too!)

Mod edit: Fixed small typo

Aragorn · 24 January 2026 06:47

Whatever happens inside of the virtual machine stays inside the virtual machine — it’s somewhat like Las Vegas.

So, if you set the nodatacow attribute on the files acting as virtual machine images, then it should be alright.

cfinnberg · 24 January 2026 07:48

I have tried latest Manjaro ISO in VirtualBox in two different computers and can’t reproduce your problem. No hangs so far. Do you have problems with any other ISO? You can also try a memory test just in case…

The only problem I have is that in VirtualBox the live environment does not adjust automatically to my screen size. The default resolution is 800x600 and I have to change it manually if I want something bigger.

linux-aarhus · 24 January 2026 11:35

This is not necessary.

Is the virtual disk stored on btrfs file system?

If yes try moving it to an ext4 formatted partition.

I am thinking the following could generate some weird issues

if your virtual disk is stored on btrfs
the virtual machine is installed with btrfs (default file system on the ISO)

Bernmeister · 26 January 2026 02:48

Apologies for not replying sooner; I received no email notification despite set to ‘watching’.

My host is ext4. When I created the VM, I only increased the HDD in size (I didn’t see an option to choose format).

I ran the VM up now, manged to launch a terminal, entered lsblk -f and got FSTYPE as btrfs.

So is it possible to switch the FSTYPE to ext4?

As for the ISO I used to install the VM:

$ sudo blkid -o value -s TYPE manjaro-kde-26.0.1-260114-linux618.iso
iso9660

$ file -sL manjaro-kde-26.0.1-260114-linux618.iso
manjaro-kde-26.0.1-260114-linux618.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) ‘MANJARO_KDE_2601’ (bootable)

From where do I obtain the XML file?

(As I said in an earlier reply), I don’t recall seeing an option for choosing ext4 over btrfs (or any other format)…and no idea how to change to ext4 after the fact.

How can I set the nodatacow on the VM files if my host is ext4?

Any other ISO in terms of other distros? Nope. Happily installed Manjaro 24 and 25 both from an ISO.

Aragorn · 26 January 2026 05:19

You can’t, because ext4 does not use copy-on-write.

I wrote that because I was under the impression that the host filesystem was btrfs. My mistake.

anon33601770 · 26 January 2026 07:48

Convert the file system of the freshly installed VM from BTRFS to ext4? No.
The other way around is possible.

You installed with the defaults , which is BTRFS.
The option to choose the file system is not really hidden, but also not very prominent either.
In the third screen of the installer (Partitioning stage), right below the third option,
where you select whether to use swap or not - to the right of that is a small selector field with the default set to btrfs.

linux-aarhus · 26 January 2026 08:34

Then the possible, theoretical issue does not exist.

With most distributions it is recommended to use the guest iso to install certain support files.

This is not necessary with Manjaro Linux. The required package will be provided during installation (by mhwd).

The forum has an extensive troubleshooting and configuration guide in the Contributions > Tutorials section

[root tip] [How To] VirtualBox - Installation - USB - Shared Folder

What comes next is speculation…

Manjaro Plasma default to use Wayland - I don’t know if this is an issue, because I have never purposely tested for that scenario.

You can however test it - instead of signing in - you can use the Host-key+Fkey (if I recall correct) to switch to a TTY in the virtual machine.

Sign in and sync the system while adding the plasma-x11-session.

sudo pacman -Syu plasma-x11-session

Then restart the system - and in the lower left corner change session type to Plasma X11 - and sign in.

Bernmeister · 26 January 2026 09:12

I managed to run a terminal (rather than TTY) and installed plasma-x11-session, logged out, selected x11 and logged in. Seemed fine, so I shutdown (via the start menu). Restart and all seemed well…then locks up again. Always running at maximum CPU. I’ll make a detailed post after this one giving the tests I’ve run so far…

Ran a few tests FWIW…

Download fresh ISO - same version/build numbers as what I downloaded initially.

Create VM (ArchLinux, 8GB RAM, 20GB HDD).
Start installation:
Boot using open source drivers.
Erase disk: No swap; ext4
Restart at end.
Locks up after restart after a few seconds.

Create VM (ArchLinux, 8GB RAM, 20GB HDD).
Start installation:
Boot using open source drivers.
Erase disk: Swap (no Hibernate); ext4
No restart at end; after a few seconds locked up.
CPU at maximum.
Force power off.
Remove virtual ISO.
Start up:
Sitting idle for a few minutes.
CPU is bouncing around.
Mouse hover over startup windows; seems responsive.
Screen saver kicked in. Entered password. Still responsive.
Minimised start up window.
CPU still bouncing around.
Desktop icons responding to mouse hover (showing tooltips).
Screen saver kicked in. Entered password. Still responsive.
Attempt shut down; CPU at maximum. Lock up. Force shutdown.
Start up:
Minimise start up window.
Run terminal (click on desktop shortcut).
CPU at maximum. Still responsive.
Run Firefox (click on desktop shortcut).
CPU at maximum. Still responsive.
Screen saved kicked in. Entered password. Still responsive.
Exit terminal.
Start terminal. Shutdown via terminal. Shutdown as normal.
Start up:
Managed to run a terminal (not TTY). Installed plasma-x11-session.
Log out. Select x11 and log in.
Seems fine for a minute or two, so do a proper shutdown via start menu.
Start up:
After a minute or two, locks up and CPU is at maxium (CPU is thrashing for most of the time).

anon33601770 · 26 January 2026 10:43

It has been a long time since I used VirtualBox - this is from memory and from reading the documentation:

it’s likely located in ~/VirtualBox
some files, like the disk images, are in ~/VirtualBox VMs or similar
or look in ~/.config/ for a folder belonging to VirtualBox

If you are not dead set on VirtualBox - try virt-manager
(which is what I use)
or the very similar, but simpler Gnome Boxes.
(you appear to use Gnome as your DE on the Debian host)

linux-aarhus · 26 January 2026 10:54

Still only speculation …

So you are booting into the ISO and you are able to install the system but if you wait then it will lock up.

I am beginning to think it is related to the host and how it handles the virtual machine.

Just punching holes to see what’s behind

is virtual extensions enabled in the host firmware?
is there any file system or disk errors on the host?

EDIT:

I have not been able to reproduce your issue to the fullest extent.

I see a continued high CPU usage in the guest, but as this is the same no matter the guest system I don’t think it is the Manjaro Linux.

I have used a Clevo N141WU with Intel i7-85550u, 16G RAM using Intel iGPU, The host is installed with Manjaro Xfce 26.0.1 using Linux 6.18 kernel.

I see the same high CPU usage no matter the OS, I have created virtual machines using Manjaro Plasma 26.0.1 ISO and Zorin 17 (Ubuntu based, Linux 6.8 kernel).

Bernmeister · 27 January 2026 04:59

@anon33601770

I found $HOME/.config/VirtualBox/VirtualBox.xml and looked in that; only config stuff for VirtualBox itself, not for any of the VMs.

I’ve not had trouble with other distros/versions such as this using VirtualBox (that includes Manjaro 24 / 25).

Yes, using Debian 13 with GNOME; I will take a look at other VM solutions…annoyingly I’m spinning up VMs just to test out software I’m writing. After that, I bin the VM.

@linux-aarhus

Yes, can install of ISO. Then restart, after a minute or three, lock up.

Not sure about virtual extensions being enabled. Is this a BIOS thing? I’ve run quite a lot of other VMs using VirtualBox (Manjaro 24 / 25 for example) without this issue.

I ran Manjaro 25; CPU is not thrashing nor at maximum once the VM has fully loaded. I then gave Fedora 43 a go and the CPU is at maximum and does not back off! Oh well…

I might try Manjaro GNOME or Xfce to see the difference. I’m only installing Manjaro (and a bunch of other distros/versions) to test some software. I’ve tested GNOME/Xfce with other distros, but really I want to test Manjaro 26 to check all is well (as has been with Manjaro 24 / 25).

I downloaded the ISO Manjaro 26.0.1 GNOME. Installed using: 8G RAM, 20 GM HDD, OS Type ArchLinux. Used defaults across the board (btrfs and no swap). The VM runs as expected and did all my testing. The CPU was running hot, but at least I (mostly) achieved my goals.

Might try the next (minor/micro) point release of Manjaro 26 KDE as I really wanted to test version 6 of KDE.

Thank you to you all for giving up your time to help. As the issue is unresolved, I’m happy to run other tests/checks if that helps.

linux-aarhus · 27 January 2026 06:02

The only interesting about Manjaro 26.0.1 ISO is Plasma 6.5 which in a few weeks time change to Plasma 6.6.

That said - I do think it is related to the kernel - Manjaro 26.0.x uses Linux 6.18 and 25.0.x uses Linux 6.12.

Whether it kernel or it is a combination of VirtualBox 7.2.4 and Linux 6.18 is difficult to say.

Your Debian host - which kernel is in use?

I have tested the following combinations of Manjaro Linux using kernel 6.12 and 6.18 on the host, and also for the Manjaro Linux Guest systems. The result is the same no matter the combination.

Running htop on the host - only the host is interesting CPU wise - is showing one (1) CPU at almost 100% almost all the time. On an 4/8 core/thread Intel Core i7-8550U.

As I have also tested Ubuntu with the same result - I am thinking it is more related to VirtualBox than it is to Manjaro Linux.

I have not been able to reproduce a freeze, so the freeze point back to your system.

Since VirtualBox in the current iteration leans heavily on the CPU, one need to ask - it the cooling on the host system adequate and fully functional or could the freeze be caused by the host running too hot?

This points more to VirtualBox than it points to Manjaro Linux.

A search for virtualbox 7.2.4 high cpu use even when vm is 20idle - https://sx.nix.dk also reveals that others have noticed this as well.

Bernmeister · 27 January 2026 10:12

Debian 13 GNOME; kernel 6.12.63+deb13-amd64

I did also try Manjaro 26.0.1 GNOME version and that was all good. Most of the VMs I have run (all Linux flavours) run without the CPU chugging (Fedora 43 did when I tested earlier today). I presume my system is adequate, otherwise the other VMs would not have run (or the CPU would have thrashed).

Very difficult to pin point; I will try the next minor/micro version of Manjaro KDE when it is released.

BG405 · 27 January 2026 17:20

@Bernmeister I don’t see this in the thread yet.

Although the .ISO has an MBR/DOS boot sector, it’s possible you installed the VM in (U)EFI mode; I’ve had the same (or similar) issues as you using that mode.

Molski · 27 January 2026 18:54

I am typing this from within a Manjaro Plasma guest. Smooth as butter! (And mostly idle.)

$ top -H -p `pidof qemu-system-x86_64`


top - 11:47:27 up 19:18,  2 users,  load average: 0.44, 0.28, 0.18
Threads: 28 total, 0 running, 28 sleep, 0 d-sleep, 0 stopped, 0 zombie
%Cpu(s):  0.4 us,  0.1 sy,  0.0 ni, 91.1 id,  8.4 wa,  0.0 hi,  0.0 si,  0.0 st 
MiB Mem :  48059.6 total,  28447.6 free,  14442.5 used,   5711.8 buff/cache     
MiB Swap:  35266.5 total,  35266.5 free,      0.0 used.  33617.1 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                            
  16190 tdell     20   0   33.6g 409596  39620 S   2.0   0.8   4:02.94 CPU 9/KVM                                                                                                                                          
  16181 tdell     20   0   33.6g 409596  39620 S   1.3   0.8   2:51.18 CPU 0/KVM                                                                                                                                          
  16191 tdell     20   0   33.6g 409596  39620 S   1.3   0.8   2:56.86 CPU 10/KVM                                                                                                                                         
  16192 tdell     20   0   33.6g 409596  39620 S   1.3   0.8   2:45.34 CPU 11/KVM                                                                                                                                         
  16184 tdell     20   0   33.6g 409596  39620 S   1.0   0.8   2:17.28 CPU 3/KVM                                                                                                                                          
  16185 tdell     20   0   33.6g 409596  39620 S   1.0   0.8   2:38.90 CPU 4/KVM                                                                                                                                          
  16187 tdell     20   0   33.6g 409596  39620 S   1.0   0.8   2:40.02 CPU 6/KVM                                                                                                                                          
  16189 tdell     20   0   33.6g 409596  39620 S   1.0   0.8   2:45.78 CPU 8/KVM                                                                                                                                          
  16182 tdell     20   0   33.6g 409596  39620 S   0.7   0.8   2:18.01 CPU 1/KVM                                                                                                                                          
  16183 tdell     20   0   33.6g 409596  39620 S   0.7   0.8   2:39.50 CPU 2/KVM                                                                                                                                          
  16188 tdell     20   0   33.6g 409596  39620 S   0.7   0.8   2:21.52 CPU 7/KVM                                                                                                                                          
  16186 tdell     20   0   33.6g 409596  39620 S   0.3   0.8   2:16.81 CPU 5/KVM                                                                                                                                          
  16153 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:12.97 qemu-system-x86                                                                                                                                    
  16162 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.33 qemu-system-x86                                                                                                                                    
  16163 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 IO iothread1                                                                                                                                       
  16164 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 IO iothread2                                                                                                                                       
  16165 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.85 vhost-16153                                                                                                                                        
  16180 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:05.08 IO mon_iothread                                                                                                                                    
  16199 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:03.58 SPICE Worker                                                                                                                                       
  16200 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 kvm-nx-lpage-re                                                                                                                                    
  17191 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.01 worker                                                                                                                                             
  17197 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker                                                                                                                                             
  17198 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker                                                                                                                                             
  17199 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker                                                                                                                                             
  17202 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker                                                                                                                                             
  17204 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker                                                                                                                                             
  17205 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker                                                                                                                                             
  17206 tdell     20   0   33.6g 409596  39620 S   0.0   0.8   0:00.00 worker

Always preferred qemu over vbox, but still, this shouldn’t happen.

What CPU are using? (And you obviously enabled VT-x or AMD-V based on which processor you have? Almost all BIOS come with this disabled by default.)

Bernmeister · 27 January 2026 22:01

CPU: Intel(R) Core™ i3-10105 CPU @ 3.70GHz

VT-x is enabled.

@BG405

Apologies; here is the contents of Manjaro 26.0.1 KDE.vbox

<?xml version="1.0"?>
<!--
** DO NOT EDIT THIS FILE.
** If you make changes to this file while any VirtualBox related application
** is running, your changes will be overwritten later, without taking effect.
** Use VBoxManage or the VirtualBox Manager GUI to make changes.
**
** Written by VirtualBox 7.2.4 (r170995)
-->
<VirtualBox xmlns="http://www.virtualbox.org/" version="1.19-linux">
  <Machine uuid="{0b9cc1a3-4e63-42af-bfc8-032383c462cf}" name="Manjaro 26.0.1 KDE" OSType="ArchLinux_64" snapshotFolder="Snapshots" lastStateChange="2026-01-27T21:53:08Z">
    <MediaRegistry>
      <HardDisks>
        <HardDisk uuid="{f75320db-c763-430b-92e3-163fd9953487}" location="Manjaro 26.0.1.vdi" format="VDI" type="Normal"/>
      </HardDisks>
      <DVDImages>
        <Image uuid="{f30ce9fe-f014-4505-9ae9-a55f4d263e53}" location="/home/bernard/Downloads/manjaro-kde-26.0.1-260114-linux618.iso"/>
      </DVDImages>
    </MediaRegistry>
    <ExtraData>
      <ExtraDataItem name="GUI/LastCloseAction" value="PowerOff"/>
      <ExtraDataItem name="GUI/LastNormalWindowPosition" value="279,81,1280,846"/>
    </ExtraData>
    <Hardware>
      <Memory RAMSize="4096"/>
      <HID Pointing="USBTablet"/>
      <Display controller="VMSVGA" VRAMSize="16"/>
      <Firmware/>
      <BIOS>
        <IOAPIC enabled="true"/>
        <SmbiosUuidLittleEndian enabled="true"/>
        <AutoSerialNumGen enabled="true"/>
      </BIOS>
      <USB>
        <Controllers>
          <Controller name="OHCI" type="OHCI"/>
          <Controller name="EHCI" type="EHCI"/>
        </Controllers>
      </USB>
      <Network>
        <Adapter slot="0" enabled="true" MACAddress="0800276A368E" type="82540EM">
          <NAT localhost-reachable="true"/>
        </Adapter>
      </Network>
      <AudioAdapter codec="AD1980" useDefault="true" driver="ALSA" enabled="true" enabledOut="true"/>
      <Clipboard/>
      <GuestProperties>
        <GuestProperty name="/VirtualBox/GuestAdd/HostVerLastChecked" value="7.2.4" timestamp="1769550723501847000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestAdd/Revision" value="170995" timestamp="1769550670648348000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestAdd/Version" value="7.2.4" timestamp="1769550670647313000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestAdd/VersionExt" value="7.2.4" timestamp="1769550670648275000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/0/MAC" value="0800276A368E" timestamp="1769550675637930000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/0/Name" value="enp0s3" timestamp="1769550675638029000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/0/Status" value="Up" timestamp="1769550675637982000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/0/V4/Broadcast" value="10.0.2.255" timestamp="1769550675637116000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/0/V4/IP" value="10.0.2.15" timestamp="1769550675636942000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/0/V4/Netmask" value="255.255.255.0" timestamp="1769550675637870000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/Net/Count" value="1" timestamp="1769550755394008000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/OS/Product" value="Linux" timestamp="1769550670646484000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/OS/Release" value="6.18.4-1-MANJARO" timestamp="1769550670646562000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/OS/ServicePack" value="" timestamp="1769550670646631000" flags=""/>
        <GuestProperty name="/VirtualBox/GuestInfo/OS/Version" value="#1 SMP PREEMPT_DYNAMIC Thu, 08 Jan 2026 12:46:08 +0000" timestamp="1769550670646598000" flags=""/>
        <GuestProperty name="/VirtualBox/HostInfo/GUI/LanguageID" value="en_US" timestamp="1769550758899178000" flags="RDONLYGUEST"/>
      </GuestProperties>
      <StorageControllers>
        <StorageController name="IDE" type="PIIX4" PortCount="2" useHostIOCache="true" Bootable="true">
          <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="0" device="0"/>
        </StorageController>
        <StorageController name="SATA" type="AHCI" PortCount="1" useHostIOCache="false" Bootable="true" IDE0MasterEmulationPort="0" IDE0SlaveEmulationPort="1" IDE1MasterEmulationPort="2" IDE1SlaveEmulationPort="3">
          <AttachedDevice type="HardDisk" hotpluggable="false" port="0" device="0">
            <Image uuid="{f75320db-c763-430b-92e3-163fd9953487}"/>
          </AttachedDevice>
        </StorageController>
      </StorageControllers>
      <RTC localOrUTC="UTC"/>
      <CPU>
        <HardwareVirtExLargePages enabled="false"/>
        <PAE enabled="false"/>
        <LongMode enabled="true"/>
        <X2APIC enabled="true"/>
      </CPU>
    </Hardware>
    <Groups>
      <Group name="/Linux"/>
    </Groups>
  </Machine>
</VirtualBox>

Just checked the setting under Specify Virtual Hardware: Use EFI is unchecked by default and I would NOT have checked it.