I’ve done that switch many years ago and am happy with it.
For an encrypted system with lvm I use in an override file in /etc/mkinitcpio.conf.d:
HOOKS=(systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt lvm2 filesystems fsck)
Upstream is switching to systemd by default:
Money quote IMHO:
busybox hooks are not getting any of these improvements and have generally stalled for years
Alright, there are two hook alternatives possible, either busybox (base, etc…) or systemd (systemd, etc…).
Table 3.3.4 common hooks - Mkinitcpio
As upstream is switching to systemd by default, will Manjaro follow for new installs?
So my mkintitcpio hooks for systemd init are:
HOOKS=(systemd autodetect microcode modconf kms block keyboard sd-vconsole sd-encrypt filesystems fsck)
Is that correct?
hm, i try switch to systemd and if i not use base hook
i get WARNING: Possibly missing ‘/bin/sh’ for script: /usr/bin/fsck.btrfs
looks like it need for fsck hook
odd that in the description on the arch wiki it is listed as optional only for busybox recovery shell.
I have been using that for years already. The systemd hook supplants the udev hook, and part of the base hook.
The base hook is only really needed anymore if you want a rescue shell in the initramfs, but by default, the systemd daemon — not the hook — disables the rescue shell, unless you add “SYSTEMD_SULOGIN_FORCE=1” to your kernel’s boot parameters.
Note that with the systemd hook, you can also replace both the keymap and consolefont hooks by the sd-vconsole hook.
This is only really required if you have the fsck hook, which you don’t normally need with btrfs, given that btrfs performs its own filesystem integrity checks upon mounting the volume.
btrfs is a lot more sophisticated in maintaining its own internal consistency than ext4, given that it keeps checksums on files and directories, as well as that the metadata are stored in duplicate. It will even perform mount-time journal playbacks on read-only mounted volumes.
In addition to that, it also pays to run the btrfsmaintenance package and configure it for periodic background scrubs, background balancing (if needed), and on spinning HDDs, background defragmentation.
yes, but what about efi fat32 partition ?
in my fstab it mark for check when boot, so i guess i still need fsckhook . Fat32 is not very reliable
/boot/efi vfat umask=0077 0 2
There’s no need for that — it is rarely ever written to. On my own system, I have the EFI partition (and several btrfs subvolumes) mounted read-only all the time, except for system updates.
well, I have to do this occasionally as I was experimented with grub-git , they recently added full support for luks2 , but unfortunately it didn’t work for me and I had to run a few grub-install while I tested everything. Maybe someone will also want to test it?
probably most it really does not need, but for me it is useful
Well, in that case, include the base and fsck hooks, and be done with it. 
little something i noticed;
i’m used to seeing initramfs being regenerated with all new systemd updates. didnt see that happening with latest systemd updates 258.2-1
thought it worth mentioning, ran a mkinitcpio -P anyway
On my system w/ grub+luks2 it was a bit tricky to migrate to systemd hooks:
I had to edit:
GRUB_CMDLINE_LINUX="cryptdevice=<uuid>:cryptroot"
to:
GRUB_CMDLINE_LINUX="rd.luks.key=/crypto_keyfile.bin rd.luks.name=<uuid>=cryptroot"
I also faced this
change
cryptdevice=UUID=device-UUID:root root=/dev/mapper/root
to
rd.luks.name=device-UUID=root root=/dev/mapper/root
should be enough + create link from crypttab to crypttab.initramfs
don’t know why they didn’t make it compatible with each other
honestly I see the complexity, but I do not see the benefits of switching to systemd hook, but since arch has switched to it by default, I guess we’ll have to accept it
I see the benefit in altering my own system to systemd hooks, if Manjaro decides to follow that upstream switch, even in the given complexity with a full encrypted system.
I’m hesitant in changing anything concerning encryption, certainly based on issues with it after a grub update back in 2021 or 2022?
Sorry, I don’t understand what you meant, you didn’t describe any benefits. in any case if you like it I don’t mind
certainly based on issues with it after a grub update back in 2021 or 2022?
Not sure what you meant
Finally, it’s your decision, your are admin for your own system. I kept the old standard without having any issues and use
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)
some tests with hook systemd shows bad results in mount disks nvme
the better result are to put first nvme in modules for /etc/mkinitcpio.conf
# MODULES=(usbhid xhci_hcd)
MODULES=(nvme usbhid xhci_hcd)this cant be compare to udev , and only concerns nvme
And so it was and should have been. Apparently someone forgot to upstream it and it’s coming now:
ping @Yochanan
Done earlier with mkinitcpio 40-3. 
toolchain got updated. All kernels are currently rebuilding against the updated binutils …
With the update of linux-6.17.8-1 no fallback image was generated. linux-6.12 have two default generations. I didn”t update to systemd.
Yep, that is known and actually wanted …