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



Thanks for the heads up. I use mergerfs along with snapraid to present a raided and unified location for my media. After the upgrade, mergerfs worked fine for me. I checked before the upgrade and I already has fuse3 installed, so perhaps that’s why I didn’t have to install it alongside fuse2 after the upgrade.



I’ve have the same issue. Any ideas what is causing it?


It’s a duplication in pacman’s database, you can either upgrade with --ignore or delete the file after doing a ls -l over the file mentioned, and deleting the older entry. The package bolt is a device manager for thunderbolt.


Since 4.19.5, blk_mq is enabled by default. That gives the schedulers you mentioned, which are mq schedulers.

deadline and cfq are sq schedulers, and those are not available when mq is activated.

You can go back to sq with the boot parameter scsi_mod.use_blk_mq=0.

Your GRUB command line is very dangerous because it disables just about every security feature concerning Meltdown and all Spectre classes of vulnerabilities.
Also you don’t need pti=off AND nopti since both are the same.
Disabling pstate and cstate increases power usage, a no-go for laptops.
And finally, hpet should only be enforced if there’s a problem.
Same goes for enforcing ACPI resources which can be outright dangerous.

The ‘elevator’ parameter sets the schedulers for ALL drives, which might not be what you want. A udev rule is recommended.


I also had a very similar issue after updating via tty today. The update seemed to complete OK but I did notice the error message regarding device-mapper. I think the grub update failed to complete (probably during the os-prober part). When I rebooted after the update the Grub menu was there but it only showed the Manjaro option and my other install on this laptop (deepin) wasn’t there. I dual boot Manjaro KDE Stable and Deepin (not Manjaro version). Easily fixed by “sudo update-grub” and OK since then.

My pacman log part follows:

[2018-12-05 14:08] [ALPM] running '99-grub.hook'...
[2018-12-05 14:08] [ALPM-SCRIPTLET] Generating grub configuration file ...
[2018-12-05 14:08] [ALPM-SCRIPTLET] Found background: /usr/share/grub/background.png
[2018-12-05 14:08] [ALPM-SCRIPTLET] Found linux image: /boot/vmlinuz-4.14-x86_64
[2018-12-05 14:08] [ALPM-SCRIPTLET] Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.14-x86_64.img
[2018-12-05 14:08] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-4.14-x86_64-fallback.img
[2018-12-05 14:08] [ALPM-SCRIPTLET] /dev/mapper/control: open failed: No such device
[2018-12-05 14:08] [ALPM-SCRIPTLET] Failure to communicate with kernel device-mapper driver.
[2018-12-05 14:08] [ALPM-SCRIPTLET] Check that device-mapper is available in the kernel.
[2018-12-05 14:08] [ALPM-SCRIPTLET] Incompatible libdevmapper 1.02.152 (2018-10-30) and kernel driver (unknown version).
[2018-12-05 14:08] [ALPM-SCRIPTLET] Command failed.
[2018-12-05 14:08] [ALPM-SCRIPTLET] Found memtest86+ image: /boot/memtest86+/memtest.bin
[2018-12-05 14:08] [ALPM-SCRIPTLET] done


Deepin problem solved!

I uninstalled the deepin desktop and then re-installed it. Now it works again. Still not sure what had caused the problem in the first place, though.


I have to do what with it? Sorry, not that familiar with bash yet.
All I saw is that the bolt-0.6-1 contains a Gzip called mtree and no folder called desc.
Attempted to reinstall the bolt package, didn’t succeed directly (would’ve required me to reinstall several gnome components too).


Well, you can remove bolt with pacman -Rdd bolt which will remove bolt without removing any dependent packages, after which you should be able to reinstall it normally.


Me too, Manjaro KDE. in my case, all update process if complete (I’m using terminal) and after I reboot my laptop the error came. I boot using live usb then using mhwd-chroot I reinstall the linux kernel and linux kernel header. After that my Manjaro back normal again.


I suspect one of the package updates dropped me from tty3 to tty1 gdm. On another computer I arrived at the logon prompt while pacman was, presumably, still doing its thing over on tty3. On the first computer where I got the blank screen after 10-15 packages, I presume gdm couldn’t/wouldn’t/didn’t start, but this is just a hunch.
On a 3rd machine (laptop) the update completed on tty3 without switching to tty1 (or screen going blank) - In this case I had not logged off (tty2) but had switched to tty3 from tty1 on an initial reboot.
All 3 running Manjaro gnome.

edit: just restored the snapshot on pc which had the blank screen, rebooted, logged on & off, went to tty3 and re-ran the update - had no issue this time.
edit 2: I noticed it downloaded a new version of systemd so maybe that was it. great job!


So I’m guessing the poll up top is out of date. Is this large update considered safe with the subsequent systemd version rollback update?

I’ve been putting it off till the end of the week anyway, so I can leave my workspaces up during the workweek.


Worked for me on plasma, upgraded via tty


Thanks. It had some config files which made pacman complain when reinstalling, but when I moved them to a different folder, sudo pacman -S bolt succeeded.


updated via tty, went smooth as butter on toast


The update process itself [tty] occurred fine on all my installations, real & VM. My Tower suffered a total freeze necessitating a Hard Reset, 2d14h later, but subsequently [21h] has been ok. I can’t tell if it was due to the systemd issue [i haven’t rolled it back down], the 4.19 kernel scheduler changing from sq-cfq to mq-deadline, or sunspots.

Dec 06 10:23:29 GA-Z97-HD3-Tower kernel: BUG: Bad rss-counter state mm:00000000f52f2301 idx:2 val:-2
Dec 06 10:25:12 GA-Z97-HD3-Tower kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Dec 06 10:25:12 GA-Z97-HD3-Tower kernel: rcu:         Tasks blocked on level-0 rcu_node (CPUs 0-7): P27436


After the update, I get an error that;

Ara 07 10:26:56 oguz-pc systemd[1]: postgresql.service: Control process exited, code=exited status=1
Ara 07 10:26:56 oguz-pc systemd[1]: postgresql.service: Failed with result 'exit-code'.
Ara 07 10:26:56 oguz-pc systemd[1]: Failed to start PostgreSQL database server.

I fixed with these commands;

sudo rm -rf /var/lib/postgres/data
sudo mkdir /var/lib/postgres/data
sudo chown postgres /var/lib/postgres/data
sudo -i -u postgres
initdb  -D '/var/lib/postgres/data'

Have a nice day :slight_smile:


@philm I ordered my Bladebook a week ago, I got a confirmation email, sent the money also a week ago but still no response from Vivare, sent 3 emails no response. What is happening there? If they are having issues with stock or whatever I do not mind if they just reply my emails.


Seems Off-Topic, new thread maybe better.


Question: do all “upgraded” packages previous to a “transaction interruption” need to be reinstalled to ensure all post-hooks successfully complete, even if you’ve already updated everything and are able to boot?

edit: you know I just realized that after looking at various hooks themselves, would a “reinstall” even be a valid alpm trigger if the contents are only the following:

Operation = Install
Operation = Upgrade
Operation = Remove



What would be the feasibility of allowing performing upgrades via systemd on reboot? Perhaps as an option, perhaps mandatory for large, system-spanning upgrades.

Where might I even begin learning about how to set something like that up?