[Unstable Update] 2019-04-17/18 - Kernels, Virtualbox, Mono


Hi community,

today I added a whole bunch of kernel updates with their extramodules.
With the update to virtualbox 6.0.6 these modules can no longer be built for linux316, so again... If you need virtualbox you will have to choose a newer kernel than 3.16.

With the latest update of thunar/thunar-gtk3 the right-click 'new document' issue has now been fixed.

This update also includes bash 5.0.003 and mono

The full package diff can be found here.

Thank you for reporting any issues you encounter.

Current supported Kernels

  • linux316 3.16.65
  • linux318 3.18.138 [EOL]
  • linux44 4.4.167 [FZN] 4.4.178 - see below
  • linux49 4.9.169
  • linux414 4.14.112
  • linux419 4.19.35
  • linux420 4.20.17
  • linux50 5.0.8
  • linux51rc 5.1rc1.d0317.g9e98c67 (experimental. no extramodules, yet)
  • linux419-rt 4.19.31_rt18
  • linux50-rt 5.0.5_rt3
  • 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:


Note that virtualbox 6.0.6-1 is known to be pretty buggy right now and can make some VMs unbootable.




All my VMs boot fine on my unstable branch laptop (Manjaro(s), Manjaro32, Win81, W10), no other Linux distro VMs though on that machine.



With the latest update of thunar / thunar-gtk3 the right-click 'new document' issue has now been fixed.

I can confirm that thunar-gtk3 1.8.4-3 right clic > new file works fine now :slightly_smiling_face:

1 Like

Everything fine on my gnome desktop (virtualbox, mesa, kernels, e.t.c.)!


My understanding is that only Win 7 has issues booting with vbox 6.0.6 currently. My strategy is to wait for upstream fix since rolling back for all kernels is quite a task now that all the kernels have been updated since :wink:
After all this is the unstable branch - so if someone absolutely needs a win7 vbox you still have the option to switch to testing...


Arch specific build issue according to linked upstream reports, hopefully will be patched soon.


I have now also updated linux44.
We had it frozen for a while because of compiling issues with catalyst and nvidia-340xx.
We were able to fix the catalyst build, nvidia-340xx unfortunately not yet ... we shall see. In the worst case you will just not be able to use linux44 with this specific legacy driver - could be worse :stuck_out_tongue_winking_eye:
Anyway I'm still on it to see if we can make it build.
In any case I think we shouldn't hold back kernel updates for linx44 any longer just because of that.
So here you go:

[New Packages]

Is there a DE that actually works close to flawlessly with an Nvidia card?
[Unstable Update] 2019-04-29 - mostly kernels
[Unstable Update] 2019-04-30 - Systemd, Lightdm, Falkon
[Unstable Update] 2019-05-03 - Kernels, Backintime, Palemoon
[Testing Update] 2019-04-29 - mostly kernels
[Testing Update] 2019-05-04 - Systemd, Lightdm, Kernels, deprecate Qt4
[Testing Update] 2019-04-25 - Gcc, Kernels, Qt5, Kde, Deepin
[Unstable Update] 2019-04-23 Kernels, Qt5, Deepin, KDE

Thanks, @oberon! The patch worked, no more annoying flood messages in logs. However, there's a lack of another patch that was previously submitted to @philm which resolves some issues with tpm2-tools and which worked for me with kernel 5.0.7. With 5.0.8, it again results in this:

$ sudo luks-tpm2 reset
[sudo] password for openm:
Enter any existing LUKS passphrase for /dev/nvme0n1p5:
Removing current TPM key from slot 1...
Adding new key to slot 1...
WARNING:tcti:src/tss2-tcti/tcti-device.c:254:tcti_device_receive() Got EOF instead of response.
ERROR: Failed parse_policy_type_and_send_command
ERROR: Unable to run tpm2_createpolicy
There was an error resetting the TPM key in slot 1!
The temporary reset key in slot 2 has not been removed.

Anyway, thanks, at least I can report both solutions work.


Well, according to gitlab the patch is still in the PKGBUILD. So we have to check what changed.


Hi @Ste74 I have a few questions about the LSI integration of Manjaro.
On Manjaro we have lsi-settings and lsi-steam.

lsi-settings runs without problems and so I assume it is working correctly.
I tried to run it via LSI_DEBUG=1 steam to see if I can verify that LSI is really controlling Steam, but I'm not sure if this is the right way. Do you happen to know how to confirm that LSI is actually running?

lsi-steam does not work and throws an error message

Steam isn't currently installed at /usr/lib/steam/steam

I found this report about this error: https://github.com/solus-project/linux-steam-integration/issues/55

Solus does not have lsi-steam, they have only lsi-settings, so maybe they patched it out for some reasons and it is not needed at all?



if you launch normal steam from menu icon.
with steam-native, linux-steam-integration installed it launches lsi-steam(as active window control shows lsi-steam as running).
but launching lsi-steam from menu shows above same error as steam install directory is incorrect.


Well I'm still not sure whats going on as I just tried it with both steam-manjaro and steam-native installed.
Trying to run lsi-steam either via launcher or terminal fails for me no matter if:
STEAM_RUNTIME=0 lsi-steam
STEAM_RUNTIME=1 lsi-steam

I'm not saying LSI isn't working, but trying to understand what lsi-steam is for and why it doesn't lauch that way if it is supposed to.

Like I said, Solus does not have lsi-steam as a launch option and still LSI works, so I believe it's the same on Manjaro.


lsi-steam launcher is not working.but lsi is working.without launching using lsi-steam.normally launching steam launches lsi-steam.but if you explicitly launch lsi-steam it throws error.
so the launcher needs changes/removal as the steam install directory is different in manjaro.and its trying to look elsewhere for steam.


But even if you symlink ln -s /usr/bin/steam /usr/lib/steam/steam the launcher still fails for me, so there is more than that.

Yep I agree!

I think the error is in the PKGBUILD of Manjaro.

According to the mentioned bug report above line 24 should be changed from:

-Dwith-steam-binary=/usr/lib/steam/steam \


OK I've rebuilt it myself. It was a fun experience. No changes were applied, all according to your PKGBUILD, just a makepkg --skipchecksums --skipinteg command. And it installed and all works fine. The error is gone.

$ sudo luks-tpm2 reset
[sudo] password for openm:
Enter any existing LUKS passphrase for /dev/nvme0n1p5:
Removing current TPM key from slot 1...
Adding new key to slot 1...
Sealing keyfile with the TPM...
Removing temporary passphrase from slot 2...

So now I can only guess that the patch failed to be pulled correctly from https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git/patch/?id=7bde1fe0abbe202dc1f484fe7ef110f6ed3b1351 during compilation process on @oberon's side, bcz that's the only patch which is not pre-existent in linux50 directory but is currently supposed to be pulled from the above link.

PS: had to adjust /etc/makepkg config to make use of my 4 (weak, but 4 lol) cores. It took about 40 minutes to build though. Gosh I wish I had some Ryzen 8-core PC now :slight_smile:
PS2: linux50-bbswitch and linux50-nvidia also required a rebuild (original ones refused to work with my manually compiled kernel). Sometimes I think nvidia-dkms could be a better idea instead of prebuilt modules.

Have a good one, cheers.


okay so i rebuild the linux-steam-integration package with this pkgbuild and now it works properly,lsi-steam launches and directory error is gone

# Maintainer: Luca Weiss <luca (at) z3ntu (dot) xyz>

pkgdesc="Helper for enabling better Steam integration on Linux"
depends=('gtk3' 'steam')
makedepends=('git' 'meson' 'gcc-multilib')
optdepends=('steam-native: A package for installing all required deps for the native runtime.')
validpgpkeys=('22512D02C191D39D5EC4FDCDBFF2F5A2CA201B84') # Ikey Doherty

build() {
  # 64-bit build
  arch-meson "$pkgname-$pkgver" build \
    -Dwith-shim=co-exist \
    -Dwith-frontend=true \
    -Dwith-steam-binary=/usr/bin/steam \

  ninja -C build

  # 32-bit build
  export CC="gcc -m32"
  export CXX="g++ -m32"
  export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"

  arch-meson "$pkgname-$pkgver" build32 \
    -Dwith-shim=none \
    --libexecdir /usr/lib32 \
    --libdir /usr/lib32

  ninja -C build32

package() {
  DESTDIR="$pkgdir" ninja -C build install
  DESTDIR="$pkgdir" ninja -C build32 install

# vim:set ts=2 sw=2 et:

I also just build it and can confirm that it works.


Very strange. Maybe my PKGBUILD was not at the latest state when I built this version. Will provide a pkgrel 2 ... Thanks for your research, @openminded

[New Packages]