I hope this is helpful to put here, as i still dont know the underlying reason. But after updating this update my KDE Connect works again. It wasnt working before.
After the upgrade my NAS shares would not mount automatically
I get:
sudo mount -a 32 ✘
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Apparently the needed options for mount have changed.
In my /etc/fstab I have:
//192.168.1.2/home /mnt/NAS_home cifs defaults,uid=1000,credentials=/home/carsten/nascred 0 0
This worked fine up until this upgrade. I tried different mount options but no luck so far. Any advice?
Try it with
//192.168.1.2/home /mnt/NAS_home cifs defaults,vers=2.0,uid=1000,credentials=/home/carsten/nascred 0 0
That worked for me.
Thanks, it worked. It also works with vers=3, since my NAS supports it and I don’t want to use “old” protocol versions if I can avoid it.
But it seems, that you have to explicitly set the protocol version now for whatever reason.
1 Like
Yes, except that the browser is hard crashing because of this setting, so you have to create a new profile, and when you go to about:config on a new profile, that would toggle the setting for that new profile, but you need to change the setting in the old profile. Therefore, the setting has to be edited manually inside prefs.js.
Thanks @GokuSan & @flux for your input.
I’ve decided to:
- Apply all the syntax changes… “”
()
- Keep my hook options as they were originally (with
keymap)
HOOKS=(base udev autodetect modconf block keyboard keymap filesystems fsck) - merged in the new
MODULES_DECOMPRESSsection remmed as it was introduced in the pacnew for now - removed the pacnew file…
$ sudo rm /etc/mkinitcpio.conf.pacnew -
$ sudo mkinitcpio -Pand rebooted
all is well as expected as really the only changes made were altered syntax and more remmed lines
$ cat /etc/mkinitcpio.conf
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(piix ide_disk reiserfs)
MODULES=()
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=()
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS=(base)
#
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS=(base udev autodetect block filesystems)
#
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS=(base udev block filesystems)
#
## This setup assembles a pata mdadm array with an encrypted root FS.
## Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
# HOOKS=(base udev block mdadm encrypt filesystems)
#
## This setup loads an lvm2 volume group on a usb device.
# HOOKS=(base udev block lvm2 filesystems)
#
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
HOOKS=(base udev autodetect modconf block keyboard keymap filesystems fsck)
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
#COMPRESSION="zstd"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()
# MODULES_DECOMPRESS
# Decompress kernel modules during initramfs creation.
# Enable to speedup boot process, disable to save RAM
# during early userspace. Switch (yes/no).
#MODULES_DECOMPRESS="yes"
1 Like
You’re right. Seems to be an upstream bug in a kernel patch in v5.18.8
2 Likes
Hi winnie,
thx for the confirmation. I was really wondering, what the heck I again did “destroy”. So I will stick of with LTS, as I have no fancy new hardware no other known thing for which I actually would need newer kernel. Thx for the hint.
1 Like
What does “remmed” mean? “Commented”? I have the same HOOKS line, I haven’t inserted the MODULES_DECOMPRESS section (yet), because it’s just a bunch of comments, that is, I haven’t changed anything at all, but Manjaro doesn’t boot anymore with any kernel 5.x I have (5.4, 5.10, 5.15), only with 4.19, where I ironically(?) got the errors/warnings during the installation of the update. What can I do?
I’m no expert but check this out. It seems like they do the same thing. You can replace it with udev as long as you don’t mount /usr on a separate partition.
1 Like
This update is no fun. It feels like a regression on a regression.
The previous update caused a non-working Virtualbox and now this:
After updating, the boot process “hangs”. I do not get a login screen.
It chokes on failed loading kernel modules. could not load module nvidia_uvm (or similair, I can not find it anymore in journalctl. Sigh, those times when you could just find stuff in /var/log).
But the module is still there. I’m able to boot and work fine on kernel 5.4.204.1. But no luck with other kernels (eg. 5.18.10-1. 5.15.53-1 5.10.129-1).
Any pointers or ideas?
Also grrrrrr, why does mkinitcpio.conf lacks a comment like “Oh BTW, after editing this file, run mkinitcpio -P and reboot to get the changes in effect”. Such a comment could reduce headaches. Also, why doesn’t mkinitcpio patch its config file on its own to the right format? The devs of mkinitcpio suck.
/rant
2 Likes
System froze after this line: [ALPM] upgraded linux419-nvidia (515.57-1 -> 515.57-3) This was on tty 6 btw, not in GUI. I running 5.4, but it never got to those packages as best I can tell.
Tried a restart but grub complained there were no vmlinuz file for any entry.
Booted latest xfce manjaro iso & manjaro-chroot -a.
Had to delete /var/lib/pacman/db.lck then was able to finish the update.
my panel is wigging out now. all my widgets in the panel are freezing and glitching. If you click on them and show the tooltips(?) above they will all run fine though. and they are all affected at same time. also had some weird issues where screens would clip through each other randomly for a split second
Why doesn’t /etc/default/grub have a comment “Oh BTW, after editing this file, run update-grub and reboot to get the changes in effect”?
Yeah, those pesky devs… hiding crucial information.
Soon we’ll need signs to look left and right before you cross the road or else it will be others’ fault if hit by a car. Oh wait…they actually exist already… 
2 Likes
Kernel 4.19 is an old one which doesn’t ship that modules.builtin.modinfo file as you can see here:
[phil@infinitybook iso-info]$ pacman -Fl linux419 | grep modinfo
[phil@infinitybook iso-info]$ pacman -Fl linux54 | grep modinfo
linux54 usr/lib/modules/5.4.203-1-MANJARO/modules.builtin.modinfo
There were changes to mkinitcpio to look for that file. We can try to ship an empty file with one of the next kernel builds of that series to avoid that warning. Since it is a warning the kernel will still boot as the file doesn’t exist to begin with …
2 Likes
Had the same issue here.
As chris_d mentioned this seems to be a bug with the recent kernel v5.18.8.
As I actually as far as I see do anyway not needed new Kernel stuff, I switched to the most recent LTS Kernel and everything is up and running again 
1 Like
Just updated everything went well, except for rendering subtitles in Arabic language.
ASS subtitles are rendered fine, but other types are displayed in wrong way.
From left to right rendering it unreadable.
My guess it’s some issue with harfbuzz?
To elaborate
مرحبا
is rendered like this
اب ح رم