I’ve made the transition easier with filesystem 2023.08.02-1. If vconsole.conf.pacsave exists, it will be automatically restored as /etc/vconsole.conf.
$ pacman -Qo /etc/credstore*
/etc/credstore/ is owned by systemd 254-1
/etc/credstore.encrypted/ is owned by systemd 254-1
Before systemd 254-1 those directories were created but not owned, maybe that’s why it was showing 0 for permissions, but everything was fine already.
One more thing after systemd 254-1 update: /boot/efi also mounts to /efi
Not on my system:
core/systemd 254-1 [installed]
systemd client libraries
systemd resolvconf replacement (for use with systemd-resolved)
acme-tiny systemd files for running as dedicated user instead of root.
/dev/sda5 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
Or are you talking about systemd boot?
No, I use GRUB.
$ mount | grep "/efi "
systemd-1 on /efi type autofs (rw,relatime,fd=53,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=1758)
/dev/nvme0n1p2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
You probably use MBR and I use GPT. That’s why there is no problem on your machine.
Found a bug report:
It’s not critical for me, I just noticed a new mount point.
I don’t have that, only shows me my device mount.
I don’t even have an /efi directory…
But your boot partition (dev/nvme0n1p2) is mounted to /boot/efi on your system.
This is the new standard for ESP’s
But it still shouldnt have changed/added to yours.
Looks like it did here too:
$ mount | grep "/efi "
systemd-1 on /efi type autofs (rw,relatime,fd=38,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=17650)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
PS
I also got the permissions change … just followed with chmoding the locations to the new permissions.
My mount point is still /boot/efi 
I use GRUB, Dracut and GPT:
$ mount | grep "/efi "
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
Same. But I got the funny thing.
(no noticeable problem … just the extra mount)
systemd-boot here, and I don’t have and efi mounts:
$ mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
Contents of /boot:
/boot
├── EFI
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Linux
│ │ ├── 19875b6bc63142ed8ea075dd33faae6d-6.4.7-1-MANJARO.efi
│ │ └── 19875b6bc63142ed8ea075dd33faae6d-6.5.0-1-MANJARO.efi
│ └── systemd
│ └── systemd-bootx64.efi
├── intel-ucode.img
├── linux64-x86_64.kver
├── linux65-x86_64.kver
└── loader
├── entries
├── entries.srel
├── loader.conf
└── random-seed
7 directories, 10 files
Everything works 
By the way, the new mount point /efi appears only after a reboot. Just in case someone checks this without rebooting.
Correct, my fat32 boot is MBR.
It’s a little late now. 
Don’t worry, it’s fine (and encouraged) to have more discussion in Unstable Updates threads to work out potential issues before they reach testing and stable.
However, in the future please do create a new Support thread and tag it unstable when you think you may need help.
2 Likes
I checked Arch with systemd-boot and mkinitcpio on KVM/QEMU.
After reboot:
$ mount | grep "/efi "
systemd-1 on /efi type autofs (rw,relatime,fd=57,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=16572)
/dev/vda1 on /efi type vfat (rw,nosuid,nodev,noexec,relatime,nosymfollow,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
But I wait more than 5 min, then the last line disappears automatically.
$ mount | grep "/efi "
systemd-1 on /efi type autofs (rw,relatime,fd=57,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=16572)
I forgot to mention that I also got this:
[ALPM-SCRIPTLET] Creating user 'systemd-journal-upload' (systemd Journal Upload) with UID 952 and GID 952.
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
3 Likes
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!
6 Likes