[Testing Update] 2019-04-20 - Kernels, Virtualbox, Systemd


Hi community,

here comes another testing update with a pile of updated Kernels, Virtualbox 6.0.6 and another patch :stuck_out_tongue_winking_eye: for Systemd 242.

Please be aware that this latest version of vbox has issues booting Windows 7 guests. So if this affects you, you might want to hold back on this update or switch to stable branch until this gets fixed upstream - it's already being worked on...

We now decided that we can not hold back updates for linux44 any longer. We were able to fix build of the catalyst module, but unfortunately nvidia legacy 340-xx NOT. So if you need this driver you will now have to switch to a different kernel !!

@Ste74 also just updated steam-manjaro to

We hope that this update goes smoothly for you and wish you a beautiful Easter weekend!

Manjaro v18.0.4 released!

We updated our flagship ISOs of Manjaro Illyria with the latest packages. It comes with refreshed packages and updated tools. You may want to download our XFCE Edition with the latest 4.13 packages, aswell as our most recent styling efforts. Our KDE fans may try our KDE Edition with the latest KDE v5.15 instead. And our GNOME fans may try our Gnome Edition with the latest GNOME v3.30.

Current supported Kernels

  • linux316 3.16.65
  • linux318 3.18.138 [EOL]
  • linux44 4.4.178
  • linux49 4.9.169
  • linux414 4.14.112
  • linux419 4.19.35
  • linux420 4.20.17 [EOL]
  • linux50 5.0.8
  • linux51 5.1-rc1 (no extramodules yet)
  • linux419-rt 4.19.25_rt16
  • linux50-rt 5.0.7_rt5

The list of updated packages can be found here.

  • No issue, everything went smoothly
  • Yes there was an issue. I was able to resolve it myself.(Please post your solution)
  • Yes i am currently experiencing an issue due to the update. (Please post about it)

0 voters

Check if your mirror has already synced:

[Testing Update] 2019-04-14 - Nvidia, Systemd, Deepin, Gnome
[Testing Update] 2019-04-14 - Nvidia, Systemd, Deepin, Gnome

Lol the website doesn't handle the rabbit very well.

(Firefox on Windows 10)


I think it's PERFECT! :rofl:

1 Like



Good evening, the installation worked well without any issues [KDE, kernel 4.19 + 4.14, encrypted /home partition].

But I would like to add this note:

As usual after a wine-staging update, I started the update of my 32-bit wine prefix with the command:
WINEPREFIX=~/.wine32 winecfg

Even though the Manjaro package wine-mono 4.8.2-1 is installed on my system, winecfg cannot recognize wine-mono and offers to download and install it. If I cancel the wine-mono installation, I still find the old version wine-mono 4.8.0 within the prefix. On the other hand, installing wine-mono via winecfg results in 2 wine-mono package entries installed within the prefix:

  1. Wine Mono Runtime (version 4.8.1)
  2. Wine Mono Windows-Support (version 4.8.1)

Looks like wine-staging 4.6 cannot handle wine-mono 4.8.2. Regarding the new wine-mono package (2.) I need to research.

And finally: Happy Easter!

Found this in wine-mono git ->
Changes since 4.8.0:

  • The MSI has been overhauled, and the Wine Mono package has been internally split into 2 parts: runtime and windows support. The runtime contains a complete Mono install and supporting libraries. The windows support package contains the files and registry keys needed to convince Windows programs that .NET is installed. This change should be mostly transparent to the user, but it means you may see two different entries for Wine Mono in the uninstaller list.

As Manjaro wine-mono package does not always fit to wine base package, my solution was to remove Manjaro wine-mono from system and stay with winecfg upgrades. Cheers

1 Like

windows7 as guest, no issues. kernel 5.0.8

1 Like

Xfce on 4.19, no issues so far


Also did the Testing update on a KDE machine, after having done the Unstable update on another, and it booted fine after doing so. Another success.

1 Like

Good update, System after reboot works fine.:+1:
58 Package on LXQT with Kernel 5.0.

Link not work.


OOps, thanks, sorry, fixed! :sunglasses:


I still got an issue with systemd 242.0 -2 (same as with 242.0 -1) on my ryzen machine.
The system hang during boot process as before.

Still no issues on my Core i7 machine.

Downgrading systemd resolved the problem on the ryzen machine.


If anybody else has issues with systemd 242.0:

After removing "quiet" from GRUB_CMDLINE_LINUX_DEFAULT, I could see that the boot process on my ryzen machine hang after "Stopped udev Kernel Device Manager."

Thus I replaced "systemd" with "udev" in my HOOKS-array in /etc/mkinitcpio.conf and generated a new initcpio with "sudo mkinitcpio -P".

Now my system boots again!

This resolved the issue on my Ryzen-desktop machine. My Intel-notebook is running fine with systemd 242.0 and "systemd" in the HOOKS-array...


During the update,
the loudspeaker symbol went missing.
(from the system tray...)

After a reboot it was there again..

journalctl -b -p err

Apr 21 12:07:52  systemd-vconsole-setup[469]: /usr/bin/loadkeys failed with exit status 1.
Apr 21 12:07:52  systemd-vconsole-setup[468]: /usr/bin/loadkeys failed with exit status 1.
Apr 21 12:09:12  colord-sane[1017]: io/hpmud/pp.c 627: unable to read device-id ret=-1



How it got there I wonder? My Manjaro install is more than one year old but I believe that new installs still use udev hook instead of systemd one as it was in my time.

HOOKS="base udev resume autodetect modconf block keyboard keymap filesystems fsck shutdown"

This is how my hooks look. Install from 2014.

1 Like

Yes, that's strange. Our default has udev, indeed and I don't remember us ever changing that ... but who knows :wink:


Same issue here (probably).
I also have the systemd hook which I put there manually a long time ago and which never failed.

Now unfortunately I cannot auto-chroot (with manjaro-chroot) to fix, guess the good old manual way is now the only way forward.


I removed "systemd" from my /etc/mkinitcpio.conf too. I remember I manually modified it some time ago.


I chrooted manually, replaced systemd with udev, rebuilt initram.
Now it's working again.

I wonder whether it is a Manjaro/Arch problem or one with systemd.
@uncles-a-m, the issue occurs on my Intel desktop, but not on the Intel laptop.


About Virtual Box, Arch Linux has just pushed a rebuild on Arch Stable to work around the issue that makes some VMs unbootable with virtualbox 6.0.6-2.

Changes: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/virtualbox&id=321cac1ee72e685e4333df47f1109cdfc9d2f3a4

Issue: https://bugs.archlinux.org/task/62381

Could be worth to do another sync from Unstable eventually.

1 Like