I get this on shutdown:
[92.118213] systemd-shutdown[1] Failed to move /run/initramfs to /: Invalid argument
and
[92.118222] systemd-shutdown[1] Failed to switch root to “/run/initramfs”: Invalid argument
I can reboot and everything is fine but these messages are troubling.
Already reported Failed to move /run/initramfs to / · Issue #28645 · systemd/systemd · GitHub and being worked on: shutdown: disable recursive mount of /run/ on switching root by yuwata · Pull Request #28648 · systemd/systemd · GitHub
Ok Thanks so much.
After installing it, even if I have /etc/vconsole.conf.pacsave, the file vconsole.conf is not created, but after rebooting, it’s created with the different content:
# This is the fallback vconsole configuration provided by systemd.
#KEYMAP=us
While /etc/vconsole.conf.pacsave still contains:
FONT=
FONT_MAP=
KEYMAP=fr
That’s the the default template file from Systemd that was automatically created. See my posts above.
There were a lot of changes with systemd 254. As I said above I’ve now made it seamless for users updating in the future.
Disclaimer: Please remember, this is our “unstable” branch. No, it’s not really unstable. However, there may be hiccups and speedbumps along the way. Normally any packaging issues on our end are resolved within a very short amount of time. If it’s an upstream or an Arch packaging issue, it may take longer. Such as life with a rolling distro.
Your feedback is always appreciated!
Coming from
systemctl status efi.automount
https://wiki.archlinux.org/title/Systemd#GPT_partition_automounting
Im sure it could be handled … but Id really just rather take this as an opportunity to ditch the old discouraged /boot/efi and start using /efi as ESP.
Edit. Success. 
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 100M 0 part /efi
├─sda2 8:2 0 16M 0 part
├─sda3 8:3 0 97.7G 0 part
├─sda4 8:4 0 1G 0 part
└─sda5 8:5 0 139.7G 0 part /
Based on my recent experience with the latest release of systemd let me propose the following changes to mkinitcpio in order to produce better Manjaro kernels’ presets (/etc/mkinitcpio.d/linux*.preset):
...
PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-%KERNELBASE%.img"
#default_uki="/efi/EFI/Linux/manjaro-%KERNELBASE%.efi"
#default_options="--cmdline /etc/cmdline.d/default.conf --splash=/sys/firmware/acpi/bgrt/image"
#systemd_config="/etc/mkinitcpio.systemd.conf"
#systemd_image="/boot/initramfs-%KERNELBASE%-systemd.img"
#systemd_uki="/efi/EFI/Linux/manjaro-%KERNELBASE%-systemd.efi"
#systemd_options="--cmdline /etc/cmdline.d/systemd.conf --splash=/sys/firmware/acpi/bgrt/image"
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-%KERNELBASE%-fallback.img"
#fallback_uki="/efi/EFI/Linux/manjaro-%KERNELBASE%-fallback.efi"
fallback_options="-S autodetect"
...
Those who want to make use of a separate systemd-based initrd may create a mkinitcpio.systemd.conf, populate it with hooks they need, uncomment #systemd... options and adjust them according to their preference, those who don’t use UKIs won’t be affected at all if leave as proposed above.
Of course it’s not necessary to make these changes at all but atm Manjaro-specific kernel presets contain weird-looking references to Arch-specific files which looks like an oversight or something:
# mkinitcpio preset file for the '%KERNELBASE%' package
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-%KERNELBASE%"
ALL_microcode=(/boot/*-ucode.img)
PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-%KERNELBASE%.img"
#default_uki="/efi/EFI/Linux/arch-%KERNELBASE%.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-%KERNELBASE%-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-%KERNELBASE%-fallback.efi"
fallback_options="-S autodetect"
It didn’t though, I just installed that and rebooted. vconsole.conf is still the same fallback version and the pacsave is still there in all it’s glory.
I’ll just restore it myself, but could be good to know if you rely on it doing something.
[ALPM] upgraded filesystem (2023.08.01-1 -> 2023.08.02-1)
$ ls -l /etc/vconsole.conf*
-rw-r--r-- 1 root root 79 Aug 1 22:58 /etc/vconsole.conf
-rw-r--r-- 1 root root 33 May 5 19:20 /etc/vconsole.conf.pacsave
$ cat /etc/vconsole.conf
# This is the fallback vconsole configuration provided by systemd.
#KEYMAP=us
I guess it was supposed to be restored from the pacsave only if there’s no vconsole.conf in place yet.
I pulled some upstream packages which also updates the toolchain. Hence dkms is broken for a while. New kernels and rebuilds are expected soon. In this process we will drop linux63.
I removed vconsole.conf and forcibly reinstalled both filesystem and systemd and vconsole.conf.pacsave is still there while the newly created vconsole.conf contains different default content.
In the end, I manually copied the content of vconsole.conf.pacsave into vconsole.conf, because my laptop have an azerty keyboard that needs KEYMAP=fr entry to correctly type my login password.
this is what changed: [pkg-upd] 2023.08.02-1 (4a79e6e9) · Commits · Packages / Core / filesystem · GitLab. Was an older filesystem package installed?
The problem is when you force reinstall of the same version, I tried downgrading to filesystem-2023.01.31-1 then upgrading to latest and it restored vconsole.conf.pacsave to vconsole.conf.
I meant the transition from filesystem 2023.01.31-1 to 2023.08.02-1. 
An Arch bug report has been filed:
There are two potential solutions, we’ll see what happens:
And here’s the first candidate to become a backport to systemd 254 
:
https://bbs.archlinux.org/viewtopic.php?id=287354
Oh I see it had been mentioned above already, however the news is it’s been resolved this is why I talked about back-porting
Seems there was another toolchain update which needs a rebuild of all kernels again.This time cos of glibc 2.38. So dkms will be broken for a little longer …
I copy /etc/vconsole.conf.pacsave over /etc/vconsole.conf, it was my previous configuration for vconsole and regenerate mknitcpio.
Looks like its being looked at
And an odd happening. I have no idea when this would have started occuring.
Dolphin > Devices Sidebar > Root Device > Properties
Displays an incorrect (and huge) device size.
Actually it begins blank, but if you hit calculate it returns 128.9 TiB on a 137 GiB partition.
Also note that all other references are normal, including the bottom of the same window.
I think this is the known issue a long time ago.
The size of the Kernel file /proc/kcore should not be calculated because it is in RAM.
9 years ago:
https://stackoverflow.com/questions/21170795/proc-kcore-file-is-huge
