[Testing Update] 2018-07-04 - Kernels, Firefox, VirtualBox, NetworkManager



Can you please push latest Mozilla Thunderbird 52.9 ?
Fixes a security issue:


Kernel 4.16 is deprecated - you should move forward, or backwards to 4.14.

Your VM will run fine with 4.17.


Not until linux 4.17.4 is available. See this archlinux bug for more information: https://bugs.archlinux.org/task/59091


This bug has been fixed for me with 4.17.2 or 3 by the new version of libinput.

Testing is now on 4.17.4, so it should be fixed for all.

But thanks for the hint.


I’m sorry but you are incorrect. I have posted intermittently about this problem in various Update threads for [i think] a few weeks now… basically ever since kernel 4.17 became no longer RC [which is when i began using it in my real Manjaros, & in my various VMs], my VMs became unusable / uncontrollable. I did not know why [did not know about the Arch bug report, thanks @fredb74 :slight_smile: ] but all i knew is that each time i booted a VM with its 4.17.x, the VM misbehaved, but each time i booted in 4.16.x or 4.14.x they were as good as normal.

Conversely 4.17.x seems fine in my real Manjaros.

EDIT: Oh, just saw your

…which i had overlooked, so i shall now reinstall 4.17 in my Testing VM to see how it goes. Thanks.

EDIT2: Yep, it’s now behaving fine & dandy once more, now that it has 4.17.4 – cool bananas! Thank you @LAZA & @fredb74


On Gnome 3.28.2 (testing branch), back & forward button mouse not work anymore. Comparisan with stable using 3.28.1, no any trouble on extra buttons mouse.


Even Arch don’t have newest thunderbird yet. As written in the mentioned article, those security wholes are unlikely to be exploited since scripts are disabled by default. So we can only wait patently till it arrives. Besided, we’ve been living with those secutity wholes all the time so I guess we can survive a little longer althouh… once the cat is out of the sack…


Also on 3.28.2 (wayland though) - can not confirm - my Logitec MX Anywhere 2 (bluetooth) the forward and back keys do work (in firefox)


Please check if installing systemd-resolvconf fixes the issue …


I’ve changed openresolvconf to systemd-resolvconf, it has seems operesolfconf is provided by systemd-resolvconf anyway. Rebooted.

Anyway, no effect, vpn still reports invalid device

NetworkManager[455]: <info>  [1530734817.9578] audit: op="connection-activate" uuid="3c6d9fb2-ac15-4913-b1dc-28dbc33c1914" name="ZČU" result="fail" reason="Cannot specify device when activating VPN"


I’m having issues with 802.1x authentication on a wired connection. Wifi is working fine, but the issues are quite possibly related. Or, it’s just a network switch which needs rebooting.

If you can, have a chat with your local network admin/tech support to see if the connection logs shed any light.

I’ll be digging into my connection issues tomorrow or Friday.


I can connect with anyconnect via nmtui, just checked. I rarely use nm-applet.

Update: It really doesn’t work with nm-applet! Here is what the terminal logs:

(nm-applet:2812): nm-applet-WARNING **: 23:13:23.905: VPN Connection activation failed: (org.freedesktop.NetworkManager.UnknownDevice) Cannot specify device when activating VPN

I would like to install systemd-resolvconf, but
:: systemd-resolvconf and openresolv are in conflict. Remove openresolv? [y/N]

No, @philm, systemd-resolvconf doesn’t help with nm-appletnot able to connect to an anyconnect connection. I did sudo systemctl enable --now systemd-resolved.service


I have the same rusults as you. I did resolved the conflict and nothing have changed in my end.

EDIT: NO, after reboot I can’t get connection from my router :open_mouth: so systemd-resolvconf is bricking my network


I can also confirm vpn breakage with this notification error using nm. Establishing an openvpn connection per terminal still works – however precautions are needed to ensure client config files are clean and you also need to perform extra steps to translate over the DNS servers pushed by the provider.


Don’t know how you setup the VPN, but try add the VPN connect from configure file (or manual config) again maybe help.

For DNS, first try ping the VPN address, see if it resolve correctly (you can find the right ip use service like cachecheck by OpenDNS)
and check resolvectl status to see if your settings working.


:bulb: Still on nm 1.12, I found an interesting workaround for the vpn breakage. (Btw, I’ve since already updated to linux417.)

Go into your applet’s “Edit Connections…” -> double click on your primary network adapter -> general tab -> check “Automatically connect to VPN” and then choose your desired saved vpn selection -> save -> close preferences and then disconnect the adapter (single left-click on the applet) -> connect -> and now your saved vpn location should automatically connect (with the pushed DNS servers translated over, as normal.)


After a load of digging through logs, it turns out I simply needed to remove and re-create the network connection.

Looks like a schema change or similar.

I’ll put this in the Known Issues post.


I tried removing and re-adding my primary adapter with no luck with an openvpn connection, but there’s since been a bug report that’s been filed in debian sid and a working PR is already in progress that deals with the problematic applet itself.

As noted in the report above, this is also another workaround confirmed working for me:
nmcli connection up [vpn connection name]

Unrelated discussion: are topics here in the Manjaro forums not indexed by Google and others? It would seem to make sense to index at least certain subforums like “unstable updates” and “testing updates” to indeed get more exposure to search terms. I didn’t think to search DDG, but I only found the bug per Google but no Manjaro forum results displayed.

[Testing Update] 2018-07-14 - Kernels, KDE (Plasma, Apps), Firefox, Thunderbird, Mesa, Haskell

Following the excellent research done today by @xabbu [Testing Update] 2018-06-29 - Linux v4.18-rc2, Pamac, Manjaro-Tools-Git, Haskell, Python we now know the viable workaround:

I read some of the links within some of @xabbu’s references, & these two discuss that if a recent commit is rolled back, the problem goes away:

Reverting the mentioned Qt commit fixes it


Interestingly, Qt Creator has similar problems with Qt 5.11.1 that are also fixed by reverting that commit in Qt:

Is this possible for you to do within Manjaro, or is this necessarily dependent entirely on Upstream?


This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.