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

update
stable

#123

Updated via tty as is usual for an update of this size and composition , No issues whatsoever encountered with KDE and 4.19 . Smooth update , Great job !


#124

First upgrade via pamac-gui in Mate desktop left system un-bootable with missing root device.
ERROR:device ‘UUID=xxxx-xxx-xxx-xxx-xxx’ not found.

Reinstall of kernel via chroot from LiveUSB restored bootable system but still left with pamac broken and unable reinstall via pacman.

Thankfully had a Timeshift backup 24hr old so rolled-back from liveusb and re-upgraded seamlessly over ssh with pacman -Syu

First time Manjaro upgrade gone south in a year of use with pamac-gui but lesson learnt for big upgrades.


#125

All is ok on Plasma 5. Updated from TTY-terminal.

It is worth to mention that to reboot I use

sudo shutdown -r now

To turn off

sudo shutdown -h now


#126

I updated XFCE, Cinnamon and Deepin via tty, no problems so far.


#127

I updated as usual in terminal, not tty, not using octopi or pamac.
No problems in uefi or bios-legacy, in kde, in openbox, in (old) lxqt, in (old) i3.
No gnome, xfce, mate, awesome, budgie or cinnamon.
What am I doing right?


#128

You’re on testing branch? :slight_smile:


#129

Stable. Had testing before. gone off testing.
I’ve never had problems updating, except the one time with catalyst which is resolved without reinstalling.


#130

I have always been on stable, but switched to testing a few months ago. Smaller update packages and less waiting time were the reasons.


#131

This is the simplest answer I’ve seen. You don’t have to wonder about which way to update. Just use the TTY. I haven’t heard of an update going wrong specifically because of using the TTY yet.


#132

A lot of the updates were xfce-related. So you didn’t have that to contend with.

Like I said earlier, I also updated in terminal, not tty, on my laptop and didn’t have update issues or system crashes.


#133

Not using pamac :+1: :wink:


#134

So you are having suspend issues with 4.19.6 as well?

Too bad that there does not seem to be a way to keep 4.19.4 as 4.19.6. simply replaced it, it’s rather drastic to go back to 4.14 (which I have not tested on my Kaby Lake R laptop).


#135

Actually my suspend issue started on 4.19 with the last kernel upgrade. I have no need to be on the latest and greatest, this Manjaro box is 10 years old. I could probably use kernel 3.16 and it would run just fine.


#136

blk-mq is not aimed at improving HDD performance (or even SATA SSD performance either I think), so it should not make any difference.

But in my limited testing with blk-mq, I found it buggy on my HDD system. So I will stick to single-queue schedulers for now until there is a compelling reason not to.

Also I agree this blk-mq change on 4.19 kernel should have been announced.


#137

My Kaby Lake R laptop with i7-8550U processor seems to have had suspend issues with older kernels as well (unsuspected resume right after suspend due to USB issues, which could be solved by disabling XHC in /proc/acpi/wakeup), which went away when I switched from openSUSE Tumbleweed to Manjaro 18.0, but this issue now with 4.19.6 is different because it does not even go into suspend.

I’m not a programmer and I can’t tell what difference between 4.19.4 and 4.19.6 could be responsible for this issue, so hopefully someone with more knowledge and the same problem can have a look.


#138

@philm Maybe a recommendation for the future if such huge updates are in the pipeline: Better you split it to smaller pieces like in the testing branch (i.e., kernel + DE stuff, normal applications, libs, …) to make it clearer and in case of occuring problems it is more comprehensible which update may be responsible for certain crashes or bugs.


#139

Then people will just whine “why are there so many updates” :sob:


#140

At the end, someone is always crying… :smile:


#141

Hello, dear community,
I have had a failure during the last update process, specifically at point Updating Grub-Bootmenu:

( 7/25) Updating Grub-Bootmenu
Generating grub configuration file ...
Found background: /usr/share/grub/background.png
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.18-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.18-x86_64.img
Found initrd fallback image: /boot/initramfs-4.18-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.18-rt-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.18-rt-x86_64.img
Found initrd fallback image: /boot/initramfs-4.18-rt-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.14-rt-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.14-rt-x86_64.img
Found initrd fallback image: /boot/initramfs-4.14-rt-x86_64-fallback.img
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.152 (2018-10-30) and kernel driver (unknown version).
Command failed.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

Could someone, please, explain me what it is about and, if needed, how can it be solved?

If it is relevant, I am running Manjaro Gnome in a dual boot along Windows 10 on a Thinkpad T480. The nvme0n1 is my main and only drive. Also, I have 4 kernel versions installed, although just the v4.19 is used.

Best regards,
vrabiutz


#142