[Stable Update] 2018-12-02 - Kernels, Plasma, Mesa, Cinnamon, Gnome, Deepin, XFCE, Vulkan



With xfce4-panel-gtk3 4.13.3-15 and prior version I am receiving this on boot. However, the crashing has stopped. I reinitialized keys and reinstalld sddm, not sure what the culprit is with this.

Dec 04 19:51:57 xmg systemd[1]: Stopping User Manager for UID 992...
Dec 04 19:51:57 xmg systemd[2877]: Stopped target Default.
Dec 04 19:51:57 xmg systemd[2877]: Stopping D-Bus User Message Bus...
Dec 04 19:51:57 xmg systemd[2877]: Stopped D-Bus User Message Bus.
Dec 04 19:51:57 xmg systemd[2877]: Stopped target Basic System.
Dec 04 19:51:57 xmg systemd[2877]: Stopped target Sockets.
Dec 04 19:51:57 xmg systemd[2877]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Dec 04 19:51:57 xmg systemd[2877]: Closed GnuPG cryptographic agent and passphrase cache.
Dec 04 19:51:57 xmg systemd[2877]: Closed GnuPG network certificate management daemon.
Dec 04 19:51:57 xmg systemd[2877]: Closed p11-kit server.
Dec 04 19:51:57 xmg systemd[2877]: Closed Sound System.
Dec 04 19:51:57 xmg systemd[2877]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Dec 04 19:51:57 xmg systemd[2877]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Dec 04 19:51:57 xmg systemd[2877]: Stopped target Paths.
Dec 04 19:51:57 xmg systemd[2877]: Stopped target Timers.
Dec 04 19:51:57 xmg systemd[2877]: Closed D-Bus User Message Bus Socket.
Dec 04 19:51:57 xmg systemd[2877]: Reached target Shutdown.
Dec 04 19:51:57 xmg systemd[2877]: Starting Exit the Session...
Dec 04 19:51:57 xmg systemd[1]: Stopped User Manager for UID 992.
Dec 04 19:51:57 xmg systemd[1]: Stopping User Runtime Directory /run/user/992...
Dec 04 19:51:57 xmg systemd[1]: Stopped User Runtime Directory /run/user/992.
Dec 04 19:51:57 xmg systemd[1]: Removed slice User Slice of UID 992.

Is this a new string of messages because of sddm? This is after I login through sddm screen.

xmg pkexec[19013]: ryan: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/bin/xfpm-power-backlight-helper --set-brightness-switch 0]


Updated via tty successfully:-
0. downloaded updates first via normal logged in terminal session: sudo pacman -Syyuw

  1. create snapshot with timeshift
  2. logged off
  3. went to tty3 and ran: sudo pacman -Syyu
  4. after a few seconds screen went blank with cursor blinking in 1:1 (top left corner)
    (but I noticed hdd light was still blinking as if something was happening)
  5. pressed tty3 again and update was actually still running
  6. after a minute it finished so I rebooted: systemctl reboot
  7. system restarted normally
    hope this helps


Running pacman via tmux might work, wouldn’t it? The terminal session could survive that way.


This is at least the second report during this update cycle of (probably) systemd or DE actually failing also using TTY. There is something seriously wrong with the design of the software we use since this keeps happening again and again.


I have to agree. A stable update shouldn’t require any thought. Or at least Pamac GUI should not allow an update which isn’t GUI compatible.


Thing is, it doesn’t happen to everyone. So we must find out what exactly causes the update issues.

I’m starting to think that testing branch is actually more stable than the stable branch…


To go back to your regular desktop, press CTRL+ALT+F7 . On some systems, it can be CTRL+ALT+F1 instead.

When updating on Plasma 5 first I logout to sddm, and only then I press CTRL+ALT+F2 to enter TTy-terminal mode.
Then, to reboot I do:
sudo shutdown -r now

To come back to sddm: CTRL+ALT+F1. I am not sure, but this seems to me even better solution to avoid problems than going to TTy while being logged on running Plasma.

Anyway, this update feedback part of forum is the best idea I have seen in Linux world. Only this makes Manjaro my favourite distro.


Did the update in tty before I log in to xfce then rebooted. Everything works, no problems so far. :ok_hand:



An easier better way would be to issue
systemctl isolate multi-user.target
which drops you directly to runlevel 3 (in sysvinit terms). It stops Xorg completely.
Even easier in case your computer is shut down: start with boot parameter 3.

Instead of sudo shutdown -r now you could just as well use reboot.


oh boy am i glad i didnt upgraded


upgraded via TTY no problems so far peace


Thanks for the clarification, @Signalrunner


New kernels introduces the following changes to the default I/O scheduler, what the reason behind these changes? I understand quite much cause of spiritfire probably uses SSD and you default new kernel to mq-deadline but how it can possible hit performance under regular HDD’s?

cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber bfq none

The phoronix.com tests shows some upsets with facebook kyber and there is no regular deadline or cfq anymore, as well as bfq-sq it was replaced with regular bfq for now. I have a pretty common HDD from notebook I try to test it with hdparm don’t think another benchmarks needs to be executed. Then test regular bfq against mq-deadline and probably leave bfq or none (noop).

PS. I just updated from running XFCE session have 0 issues, today was coming next systemd updates from [Stable Update] 2018-12-04 - Systemd Same have 0 problems.

I just disable all mitigations and power management on my old E4500 Intel Core2 CPU cause when these on have has recently few system freezes completely. And use some irqpoll and pci quircks for safety and testing. If you interested in or have some issues you can pick what you want to test with your machine setup.
I have also the following on my grub commandline from /etc/default/grub:
Some options are doing the same and posted as twice just for safety of their removal from the kernel I don’t know the reason behind few different options doing the same stuff called differently. Its not recommended to having two same acting options on the grub cmdline but I prefer to stay like these.

Somebody free to pick up whatever relevant options to their setups and watch here for defailed explanation https://forum.manjaro.org/t/stable-update-2018-12-04-systemd/67536/8:

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19-x86_64 root=UUID= rw resume=/dev/disk/by-uuid/ acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1 hpet=force clocksource=hpet elevator=bfq-sq pti=off l1tf=off spectre_v2=off spec_store_bypass_disable=on nospectre_v1 nospec_store_bypass_disable intel_pstate=disable intel_idle.max_cstate=0 processor.max_cstate=0 nospectre_v2 nopti spectre_v2_user=off irqpoll pci=ioapicreroute,use_crs,routeirq,pcie_bus_peer2peer,realloc quiet rd.udev.log-priority=3

PPS Just removed my root and swap UUID doenst matter but for safety…


Same issue here, Manjaro XFCE. I had to login from live USB, chroot and change kernel from 4.19 to 4.14.
XFCE 4.13 pannel broken after update but seems fixed after another update.


Upgraded via tty, no problems. Kernel 4.19.6, Nvidia 415.18, systemd 239.6, plasma 5.14.4.


Is anyone experiencing better gaming performance with this update. Indy games such as Kingdoms and castles are experiencing double the performance on the highest setting in 1080p on my system. It was 30fps, now 60fps and Spec Ops The Line was barely playable on highest settings achieving 40fps+ now. Ryzen 1300X with a GT1030 and using proprietary drivers.


Yes, and my argument is that INIT should be so simple that it cannot fail, and most certainly cannot fail because an update happens.

If this would be true, then none of the people that reported update fail using TTY would have been affected. This is quite simply a fail of software design.


So I’m stupid, I upgraded using pacman in the gui and the upgrade went perfectly. I do believe that
there are hardware issues at work here beyond the software issues. On another note and my wonder
of where Deepin 15.8 was, small file update this morning and voila! Probably no system file changes
but at least the login screen says 15.8, thanks for that.


KDE, Thinkpad T60, Intel T5500, i915

Update via KDE GUI and Terminal from within Oktopi. (could not connect to WiFi from within tty2)
Everything OK, so far.

Still an issue:
logging into a user account using KDE GUI is laggy and slow.
Especially after an automatic logout due to timeout or powersave/suspend.




Yes, that. A warning popup/message would be necessary.

If there is some reason to expect problems, pacman (call it by a wrapper and let that check before updating) and pamac would give you a warning and ask if you can safely reboot for that particular update. Proceeding will throw you to runlevel 3 and the update will commence.