well, there was finally an issue on my computer.
I replaced the /etc/mkinitcpio.conf with the pacnew. After mkinitcpio -P the computer stayed stucked during boot sequence just right after grub menu.
I had to revert to the older mkinitcpio.conf file, then mkinitcpio -P again to be able to boot again.
I hope I won’t have to touch this file again for a long time
You are not supposed to do that. The idea of a .pacnew is that it introduces some new upstream defaults — which may or may not be suitable for your system — and that you inspect both files and wisely merge the new defaults (if applicable) into your existing configuration.
If things were as simple as that the .pacnew could replace the existing file, then the package manager could have done so itself. But it doesn’t, because the .pacnewis only advisory — that’s the whole point.
as stated earlier… pacnews should never be considered a direct replacement for a conf file… you need to compare and merge the appropriate changes for your system… if you are unsure, create a support thread and someone will likely help you out, and until then, leave the old conf as is.
Just stick to your old configs. The change to new systemd default is optional. Obviously, just copying over would be clearly wrong approach as for example encrypt (if really required for you) would have needed to be “translated” into sd-encrypt etc. We can’t see if there have been other settings lost when just copying over the pacnew-file.
The .pacnew isn’t even correct, because it omits the sd-encrypt and plymouth hooks, and it still contains the keymap hook, which is unneeded with sd-vconsole.
Either way, I’ve already explained all of this — including a link to the Arch Wiki article — in this post (and others) on the 2025.12.08 Stable Update thread, but if people only want to post their grievances without looking at the information that’s already up there…
If your system is working with the first HOOKS line, it means your root filesystem is encrypted, so you must keep the sd-encrypt hook — the pacnew version removed it, which is why your system got stuck before booting.
Here is the minimal correct HOOKS array for your setup:
Then to prevent my computer being stuck again in case the const were wrong (and having to USB boot and chroot to fix), I install linux-6.18 as new kernel using the Manjaro tool (6.12 and 6.6 are already installed).
During kernel installation I can see in logs that mkinitcpio is executed (and mentions about the new hooks), but only on 6.18.
After reboot I landed in Emergency Mode.
Then I reboot on 6.12, put back the HOOKS const as it was prior to the last stable update:
Then mkinitcpio -P
This time I was able to boot on 6.18.
Mod edit:- Removed picture of text. Modified text for continuity. No charge. @ms34 Please avoid posting picturs of text when a brief description will suffice.
I can only suggest collecting a bit more system information so someone more experienced with systemd initramfs and encrypted setups can take a look and help.
If you can, please post the outputs of the following:
With an encrypted system,
when you switch from the previous HOOKS that are busybox based
to the now systemd based HOOKS
you also need to change the syntax of the kernel command line in /etc/default/grub
… just keep it as it is for now
make copies of the files
and then start to experiment converting to systemd based HOOKS
the device names in /etc/default/grub start with rd.
… don’t ask me why - I don’t know
it’s the naming convention for a systemd based setup is all I know
perhaps you see the reasoning and logic behind it easier than I do - because I still don’t
The Arch wiki will be helpful, as it always is.
Do not worry just yet.
Just keep everything as it is - it will keep working for quite some time.
No need to rush to implement the “new” systemd based defaults.
Plenty of time to research and try - have backups of the files you alter
to be able to revert to a working setup.
.
.