manjaro linux 18.1 – not ready for virtualization prime time

I read of a new group selling Linux computers, Tuxedo Computers (, which is bundling Manjaro Linux with the hardware. All the commentary about Manjaro is laudatory, especially when running on the Tuxedo hardware. So I navigated over to the Manjaro Linux site ( and downloaded the latest ISO release, 8.1.

I run a number of Linux systems virtually using Oracle’s VirtualBox on my Mac, all successfully. Before installing a Manjaro guest VM, I updated to the latest VirtualBox, 6.1.2. The update was no problem with my existing VMs, which are a mix of RHEL/CentOS/Oracle Linux 8.1 releases, and various Debian/Ubuntu VMs as well. I was able to update the guest extensions on all of them with no issues whatsoever. Keep that in mind.

Installation of Manjaro was absolutely smooth with no issues. It was attempting to install the guest extensions in the VM where I ran into issues. I tried the regular way of installing them by mounting the extensions CD image and running the installation script. I installed the minimal image, which meant I had to install the kernel header files matching my kernel, gcc, and make. I then ran the installation script and had no failures. On reboot unfortunately the extension that enabled folder sharing of the host’s filesystem failed. The dmesg error indicated a lack of kernel symbols. I then went looking in the Arch Linux forums (Manjaro is based on Arch) and discovered there was an Arch package with those extensions pre-built. Fine. I uninstalled the extensions I installed, then installed using pacman. On reboot the extension still failed to load because the module “taints the kernel”. The message is part of the screen capture at the top of the post.

I won’t put up with this. I would love to run this distribution because its tools are up to the very latest (gcc and Python in particular), and the kernel is the near-latest version 5.4. There’s an awful lot to like about this distribution. But this problem with the VirtualBox kernel modules, especially ones provided via pacman, is a show stopper for me. I need the ability to share files between my VMs and my Mac, or between VMs using the Mac shared folder. That feature works like a charm with every distribution I have except for Arch in general, and this version of Manjaro.

There’s also one other aggravation with Arch/Manjaro I really don’t care for, and that’s the attitude that crops up in the forums, and is exemplified by the comment “that’s not the way we do things in Arch.” Fine. It wouldn’t be such a big deal if it all worked without drama, but it doesn’t. And I’ve already had my run-ins with Arch on my Raspberry Pi (3 and 4) systems as well as an attempt in times past to just get an Arch VM running. The Raspberry Pi installations eventually all failed to properly update after a time, and the VM never worked, including the VirtualBox shared filesystem module.

In April Ubuntu 20.04 will be released with the latest kernel and tools, and I’ll step up to that and call it a day. If I need to keep on the bleeding edge, there’s always the non-LTS Ubuntu releases as well, and there are also ways to keep a Debian installation on leading release tools. I don’t need Manjaro and the Arch attitude that comes with being derived from Arch. All the other distros Just Work. In the future when my clients ask what Linux distribution to install and run, Manjaro won’t be one that I recommend.

I might be retired but I still do a bit of consulting.

2 thoughts on “manjaro linux 18.1 – not ready for virtualization prime time

  1. I’m finding Virtualbox quite hit and miss, between releases, at least on Windows. Bridged networking has been broken for sometime, for me (must try on Mac). On my personal development kit (Thinkpad running Windows 10), I’ve taken to using Ubuntu hosted on Hyper-V.

    Liked by 1 person

    • I don’t disagree with that assessment, especially with VirtualBox 5.x releases, on either Windows or macOS. I would update a guest Linux VM with a kernel update, then in that same VM go to update the guest extensions, only to have the extension build fail. Then I’d have to wait for a following VirtualBox 5.x release to see if that release fixed the VB guest brokenness. Most of the time it did, but sometimes it took two VB releases to make it all right. Then I’d continue on until the next time the guest Linux had a kernel update and go through this again. Until I learned to be picky what I updated. I got to the point where I blocked kernel updates unless it was a major update or critical security update, and make sure I had the latest VB. That usually kept me out of trouble.

      If you mean Bridged Adapter, I have that working on my macOS and have had it for some time. As for what adapter to use, I use paravirtualized network (virtio-net), instead of the default Intel Pro/1000. That seems to have solved a lot of network issues for me. But again, this is on macOS Mojave (10.14.6) which I have yet to fully update due to my dependence on Adobe Lightroom 6.

      Overall I find the VB 6.x release to be better managed and of better quality.

      I have Windows 10 Pro (free from my Windows 8 Pro from a Samsung notebook I purchased in 2013, and which still works) and I installed WSL with Ubuntu 18.04. I like what they’ve done from a shell perspective. It beats the hell out of Cygwin and company. The problem there is enabling Hyper-V effectively disables VirtualBox and VMware Player. I should learn to import and exported VB appliance VM, but it’s not too high on my to-do list at the moment.


Comments are closed.