Appreciate the heads up. IIRC, I installed the nm library.
Be careful/mindful with filesystem / systemd updates: /etc/vconsole.conf got removed on my system and broke building initramfs (I’m using systemd hooks in /etc/mkinitcpio.conf):
==> Building image from preset: /etc/mkinitcpio.d/linux64.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
-> -k /boot/vmlinuz-6.4-x86_64 -g /boot/initramfs-6.4-x86_64.img --microcode /boot/amd-ucode.img
==> Starting build: '6.4.7-1-MANJARO'
-> Running build hook: [base]
-> Running build hook: [systemd]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci'
-> Running build hook: [sd-vconsole]
==> ERROR: file not found: '/etc/vconsole.conf'
-> Running build hook: [block]
-> Running build hook: [sd-encrypt]
-> Running build hook: [lvm2]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.4-x86_64.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
Needed to rebuild initramfs after restoring it from /etc/vconsole.conf.pacsave (edit: or use the default from /usr/share/factory/etc/vconsole.conf).
4 Likes
Odd, I got a default file along with the original being moved to .pacsave.
Which of course is how it should go.
My file was also removed.
I rebuilt it with localectl set-keymap de (for German keymap).
1 Like
Yep, same happened to me. Had to move vconsole.conf back.
EDIT: rolled systemd back to 253.7 as I was getting weird messages like
Generating and signing 6.4-x86_64-systemd-signed.efi
objcopy: /efi/EFI/Linux/6.4-x86_64-systemd-signed.efi:.osrel: раздел ниже базового значения образа
objcopy: /efi/EFI/Linux/6.4-x86_64-systemd-signed.efi:.cmdline: раздел ниже базового значения образа
objcopy: /efi/EFI/Linux/6.4-x86_64-systemd-signed.efi:.splash: раздел ниже базового значения образа
objcopy: /efi/EFI/Linux/6.4-x86_64-systemd-signed.efi:.linux: раздел ниже базового значения образа
objcopy: /efi/EFI/Linux/6.4-x86_64-systemd-signed.efi:.initrd: раздел ниже базового значения образа
when generating unified kernel images and I don’t want to mess with it now.
It has nothing to do with Manjaro though, but related to AUR’s sbupdate, but I thought I should warn others if anyone else uses it.
Seems I need to learn and move on to ukify…
UPD: switched to mkinitcpio-based ukis and ditched sbupdate.
I got these messages
warning: /etc/vconsole.conf saved as /etc/vconsole.conf.pacsave
( 1/61) upgrading filesystem [---------------------------------------------------------------------] 100%
( 2/61) upgrading systemd-libs [---------------------------------------------------------------------] 100%
( 3/61) upgrading systemd [---------------------------------------------------------------------] 100%
warning: directory permissions differ on /etc/credstore/
filesystem: 0 package: 700
warning: directory permissions differ on /etc/credstore.encrypted/
filesystem: 0 package: 700
Creating group 'systemd-journal-upload' with GID 947.
Creating user 'systemd-journal-upload' (systemd Journal Upload) with UID 947 and GID 947.
-
vconsole.conf is removed, is it the normal behavior ?
-
Those permissions errors, how I’m supposed to treat them ?
Previously, Manjaro included /usr/share/factory/etc/vconsole.conf in the filesystem package, whereas Arch does not. Now that file is included in systemd 254, so it was removed from filesystem.
/etc/vconsole.conf is usually created and updated using systemd-localed.service(8). localectl(1) may be used to instruct systemd-localed.service to query or update configuration.
– vconsole.conf(5) — Arch manual pages
You may also need to restart
systemd-vconsole-setup.serviceafter changing/etc/vconsole.conf.
Just to understand 100%, /etc/vconsole.conf should no longer exist at this location?
Is it somewhere else?
Does that mean I can safely remove the .pacsave file?
I got EXACTLY this yesterday too, but I got it on unstable and it didn’t break anything for me (I did the installation on a diferent tty from the desktop gui, maybe that “saved” me).
The curious part is that it reports 0 for filesystem on those 2 directories, but when I checked, it WAS 700 belonging to root, both directories.
Does those 2 directories belong to cryfs or plasma-vault btw?
If you use the sd-vconsole hook, you must have this file, otherwise mkinitcpio fails to create the initramfs.
I don’t understand your answer.
How do I do that? (nvm, I must have been REALLY tired yesterday, just checked, the file is there, I’m guessing I checked it before the whole update was done so the file was not created yet)
How do I find where the installer moved my vconsole.conf- Why did the installer report 0 when the directories are at 700?
- What does
/etc/credstore/and/etc/credstore.encrypted/belong to?
If I should start a new thread, just tell me to. 
Edit
The thing about directory permissions, that has started to happen in the last 2 weeks updates. Sometimes they are correct in the warning and I change them, other times, like above, there is nothing to do.
Is this a symptom I should be wary of? It has never presented itself before…
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 