[Stable Update] 2017-04-02 - Mesa-Stack, Kernels, Plasma, Firefox



Clearly there must have been MORE in that first update than just a keyring.
Was it true that the first step removed symlinks? If so, that sounds like a packaging error.

It seemingly induced a lot of people to fall into a trap before the mirrors had everything. Almost everyone who rebooted after the first update got bit.

I waited a while before I did the update, but I didn’t check the forum first. Pamac did it all correctly, because I gave the mirrors time to sync (mostly because of time-zones.)


Pamac borked my stable install. Had to use pacman to fix it from the cli. I have found this to be true more often than not in my experience when an update is problematic. Of course this may be because I run testing on my laptops. I knew this one was probably going to be an interesting stable update and it was.


The 12.5.3/12.5.4/12.5.5 have issues.

If you can, reinstall an old version.

Read comments here: https://aur.archlinux.org/packages/vmware-patch


Really? Because this is the first time you mentioned it, some 224 messages into the thread.


Is this problem exclusive for people who have video cards (nvidia/amd)? Sorry the dumb question, I am kind lost


This is not a minor point release though.

The migration to libglvnd, subsequent changes to mhwd and all drivers, and the simultaneous replacement of all glx symlinks is what is causing all the issues. This caused many issues in Arch also and is not a straight forward upgrade given the vast array of hardware configurations.

Having been a small part of the testing of this in unstable and testing I honestly don’t know what more could have been done, bar more testers being involved with a broader selection of hardware and driver configs.

The real issue is that whilst the Manjaro dev team endeavour to make Manjaro user friendly and non technical as possible, under the hood is still an Arch rolling system that most likely will require manual intervention for complicated upgrades at some stage during its life.

Blindly assuming the small selection of Manjaro automated tools will be able to mask and obfuscate all the underlying complexity in all situations is noble, but ultimately wishful thinking. The Manjaro dev team is pretty small and stretched pretty thin, and whilst progress is always being made, there is no magical pill.

I do agree with you though that the notification system could be improved. Where it is recommeneded that some updates be performed at the command prompt with pacman, there should be provisions for this.

Octopi already has a news tab which contains a link to all update announcement threads on the forum, users need to know to use this. Not sure if Pamac has the same feature, don’t use it.


Have been upgrading by right-click system tray Octopi notifier and selecting system upgrade.
No issues last dozen or so updates but weirdness this upgrade.

Sometimes I lose the wifi connection during upgrades so have to restart the upgrade again.
Usually just re-run system upgrade from Octopi or right-click notifier and start again and finishes fine.

This upgrade also lost wifi connection and tried to right-click notifier,Octopi and none would run.
Tired to open a terminal also would not run with a kdeinit5 error.

So Alt-Ctrl F2 to terminal and sudo pacman -Syyu and it finished upgrade and rebooted just fine to desktop.
Just trying to understand why this particular upgrade would not allow me to re-run notifier system upgrade,Octopi or allow me to run a terminal?


Similar problem here. After updating archlinux-keyring and manjaro-system, apps started crashing, so I rebooted before doing the rest of the updates. Blank screen. I got into tty and ran pacman -Syyu. Everything seems fine now.


I’m guessing it is in some way related to all those symlinks @sueridgepipe mentioned above getting nuked early in the process, and not being available for restarts.
All such things, If they are in memory being used, won’t be deleted, but once the process stops you’ve either got nothing or a new incompatible version on the disk.

This kind of stuff is going to end up foisting BTRFS on all of us some day just for the rollback capability.


It was probably that restart that bit you. Maybe letting getting out of everything to do the update would have prevented the need to reboot. Just guessing.

Not knowing a thing about it, it seems to me that the manjaro-system script should have been packaged into the second update rather than the first. No files were listed in that package so I have no idea what it actually did.


I guess I did not mention specifically that I attempted with pamac it failed, crashed my terminal every time I tried starting it up and then on reboot it would hang. So I went to tty2 and followed the steps outlined by kainonergon in post 45. I believe my post referencing this is post 69. I did not think to mention that I had tried with pamac because I just assumed most people update graphically if they can, also I have three bare metal Manjaro installs, and the other two are on testing which had a recent problem with ca-certs if I remember correctly. I did not feel it was a huge problem and knew I could resolve it, and if I needed to I would have eventually troubleshot the problem until I fixes it. So borked as in temporarily inconvenienced. It simply follows my experience in testing. Pamac says no. Pacman on the cli does what it is told, and hopefully the commentary helps the devs get it fixed before it goes live. Not enough bare-metal installs in testing and unstable, so ■■■■ like this happens from time to time.

Regardless what is your point?



I’m thinking I should move my unstable test to a different hard drive rather than a VM, just so the time I spend in testing would be more painful -er, ah, I mean helpful. :grin:


This is my understanding, no symlinks, no OpenGL in X (GLX), no booting into graphical environment. The symlinks need to be removed before the upgrade installations though to avoid file conflicts, which pacman would error out on. Double edge sword.

Stopping any update part way through is risky and not recommened, this one particularly so.

Moral of the story, if you start your update it is unwise to stop or kill it part way through, it could leave your system in an incomplete and unstable state.


I am converting one of my laptops to unstable, so I can remind myself that pain is weakness leaving the body.


Thanks and yep that was my conclusion as well. Hate to see this happening.
And wish there was a better way. As these kind of things keep popping up every few months.


I resurrected an old machine and synced it to unstable purely for this purpose also, but also keep VMs for unstable and testing so I know exactly what is coming down the pipe before any bare metal upgrade. I actually have multiple Manjaro systems installed on it, easier than booting in a live environment when issues arise.

Outside of updates like this one though, most of Manjaro’s issues seem to revolve around newer hardware, newer dual video card systems, some network cards, and multi-monitor setups. My little unstable clunker doesn’t help much here, and TBH Linux is always playing catchup with newer hardware and with nvidia specifically a reliance on sometimes dodgy proprietary drivers.


Same problem here

/$ blueberry

(blueberry.py:32700): Gtk-WARNING **: Theme parsing error: :1:41: The style property GtkWidget:wide-separators is deprecated and shouldn’t be used anymore. It will be removed in a future version
Traceback (most recent call last):
File “/usr/lib/blueberry/blueberry.py”, line 35, in on_activate
File “/usr/lib/blueberry/blueberry.py”, line 154, in create_window
File “/usr/lib/blueberry/blueberry.py”, line 231, in get_default_adapter_name
output = subprocess.check_output([“bt-adapter”, “-i”]).strip()
File “/usr/lib/python2.7/subprocess.py”, line 212, in check_output
process = Popen(stdout=PIPE, *popenargs, **kwargs)
File “/usr/lib/python2.7/subprocess.py”, line 390, in init
errread, errwrite)
File “/usr/lib/python2.7/subprocess.py”, line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory


i wasn’t paying attention late last night and clicked to update in pamac
it crashed during main update, then black screen on reboot, with occasional flickering nvidia logo?

booted on a live usb and following wiki instructions for grub repair to get in via chroot
sudo pacman -Syyu
and all good again

No problem on laptop earlier today updating in CLI[quote=“philm, post:1, topic:20843”]
we strongly recommend to use pacman for this update!
If i had seen that, and only 63% for “everything went smoothly” in the poll i would have avoided any problem


Perhaps you’re confused about my question, and I apologize if I wasn’t clear enough. I fully understand that using Pacman directly provides more flexibility. That is only tangentially related to my question.

I want to know the functional difference between what Octopi is doing and what pacman -Syu is doing that makes the latter more immediately successful than the former. What procedure might one be running through that the other isn’t?

My experience with this update consisted of me running pacman -Syy followed by pacman -Syu and everything went swell. What would have gone differently “behind the scenes” if I synced and upgraded via Octopi? What might have caused it to fail?


Un-induced? Just up and crashed, or were a bunch of tasks running?
I ask, because a lot of the people reporting problems decided to reboot or something between the first of two updates.

My pamac ran perfectly, no problem at all, but I had shut down everything else, even closed browsers, and shut down virtual machines running in the background.

Reminds me of an old story that the best computer sysop is a man and a German Shepard.
The man is there to feed the dog, and the dog is there to make sure the man doesn’t touch the console.