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 !
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.
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
I updated XFCE, Cinnamon and Deepin via tty, no problems so far.
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?
You’re on testing branch?
Stable. Had testing before. gone off testing.
I’ve never had problems updating, except the one time with catalyst which is resolved without reinstalling.
I have always been on stable, but switched to testing a few months ago. Smaller update packages and less waiting time were the reasons.
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.
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.
Not using pamac
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).
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.
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.
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.
@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.
Then people will just whine “why are there so many updates”
At the end, someone is always crying…
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.