[Stable Update] 2019-02-19 - Kernels, KDE, LibreOffice, Systemd, VirtualBox, Deepin, Qt, Firmwares, Wine

Updated via TYY on 1 KDE System and 2 Cinnamon Systems with zero problems. Great work!

Powertop isn't working on my end.
No more to report, a good update.

1 Like

I updated my system with qt5 only issue (solved removing file) in TTY

Thanks Manjaro Team

XFCE - Kernel 4.19

yes, it gives me this:

Cannot load from file /var/cache/powertop/saved_results.powertop
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery only
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery only
segmentation fault

Found the masochist! :laughing:

You probably want to address that error. @Frog kindly provided some guidelines that worked for me, so they might work for you as well (keep the warning in mind though.) He also suggested trying first to try the overwrite option instead of removing the package...I can't remember but I think I tried that and it still didn't want to install, so I just removed it and then reinstalled again.

1 Like

Hmmm, after updating, my thunderbolt is dead and I can no longer use my docking station. Gnome reports that Thunderbolt could not be detected.

After the update, I started receiving errors about /usr/bin/boltctl already existing and was unable to update other applications. I manually removed bolt, deleted this file, and then reinstalled bolt and related packages, but I'm unable to get my thunderbolt to re-enable.

Made a thread for tracking this:

Think it might have something to do with google chrome which I have now uninstalled. I never used it. Will keep an eye on it & see how it goes. Thanks.

In the HP notebook I can not enter the pure line of commands (TTY) through the combination of keys (Ctrl + Alt + F2 ...). Any other option to enter TTY?


if you have FN key on by default, you will need Ctrl+Fn+Alt+F2 (F3,F4,F5,etc..)


Because unstable has been on systemd 240 and 241 for months now.

Stable is only now updating from 239 -> 241, skipping 240 as it was problematic in testing. It is major version updates like this that can crash x sessions, crash updates, and leave systems in an incomplete / borked state.

These issues were experienced by unstable and testing users also ... just maybe not yourself (me either, I updated through tty).

1 Like

Also, a major difference between Unstable and other branches, if I'm correct, is that systemd never got downgraded on Unstable (like Arch did actually).

Essentially, it means that Unstable only did the transition from 239.6 to a newer version once, while other branches has done it at least twice. Hence, Unstable only got f-ed once, while other branches got f-ed more than one time with systemd.

The downgrade of systemd, hoping for a more stable transition, actually backfired on us hard.

This isn't anything to do with systemd. People have just had the same "libidn2.so.4" update issue with manjaro32 and x32-stable has been on 240 for a few weeks.

The common factor: Pamac.

I suspect it is failing halfway through because it's upgrading packages in use and removing files it needs, then it falls over.

This is why I only use pacman (and sensible AUR helpers like yay and aurman).


I used pamac in name of science on xfce and no ill happened. Just that python cache thing which I think is unrelated to pamac.

1 Like

I don't think it's consistent, but it does seem to be a common factor - all of the people having issues with [Stable Update i686] 2019-02-18 - systemd, LibreOffice, KDE, firmware were using Pamac to update. I have had zero issues with pacman. However - my data sample is small so I could be wrong.


As long as i read to the post i'm more convince of that pamac is somehow disturbing with the update process.
I can say that people that made it through pacman hadn't any problem.

Damn, my system must be blessed then. :cross:

The thing is Pamac is a front-end using libalpm, the same library that use Pacman to handle package management.

So I don't understand why Pamac would be the culprit here, especially when people could just upgrade without problem usually with Pamac before when there's nothing systemd related.

If there's someone that can actually prove in detail that Pamac is doing garbage when upgrading packages, I would like to see that, and I'm pretty sure @guinux would like to fix that too.

If Pamac is considered too problematic, prehaps guinux should stop losing his time to develop and maintain it right now then. It's kinda useless to develop a package manager in-house if we just end up saying "Use pacman, Pamac is garbage." :confused:

Manjaro Deepin Edition user reporting in. No errors! Everything went smootly updating through TTY. Woo hoo!!! Thanks devs! And thanks @oberon for all the hard work!

System Info for those interested. Cheers!


It's well-known that writing package managers is hard and there are edge- and corner-cases which don't appear in normal use.

The larger a piece of software gets, the harder it is to keep clean, the more edge-cases.

Just because Pamac uses libalpm doesn't necessarily mean it does things in the same way as pacman - for example, the update/dependency checking/etc. logic can be very different, and especially so when Pamac also brings in AUR support.

I suspect Pamac needs some TLC, testing, and polish. Just like systemd did with 240.


I've been doing pamac upgrades since last October. Nothing ever happened. I have two systems and both always show the same warnings or issues (like the mentioned python cache file). Why? Because most likely I use the exactly same software (packages) on both.

What would be cool (but impossible to do) is to make two databases. One with a list of installed packages of users who's update though pamac went well and another dB with lists of installed packages of users who had issues upgrading with pamac. A sample of 10-20 users on each dB would be enough. All we would need to do would be to prune out each dB to find the common packages among each user group and finally crosscheck (diff) between the two dB.

I bet a case of beer we would find a very small set of packages that made the difference between the update going through well or not.


Forum kindly sponsored by