You are not logged in.
So I am trying to switch from busybox based initial ramdisk to systemd based initial ramdisk.
But I have some queries / confusion and need clarification.
1) Mkinitcpio Wiki mentions that "base" HOOK is optional for systemd. Yet Arch default mkinitcpio.conf includes "base" HOOK even in case of systemd. Wiki does not mention what it would do in case of systemd esp. when recovery shell is not usable, then what is the use of "base" hook under systemd? Should I keep "base" HOOK or remove?
Answer: Highly recommended to include "base" hook
2) The default mkinitcpio.conf has "sd-encrypt" before "block" HOOK but dm-crypt/System configuration Wiki mentions "sd-encrypt" after "block" HOOK. Which order is correct? Or it does not make any difference?
3) Is it safe to include kernel parameters of both, encrypt and sd-encrypt hook? i.e. specify cryptdevice as well as rd.luks.name in kernel parameters. This way I can switch between encrypt and sd-encrypt hooks anytime without needing to modify grub.cfg. Or can some programs get confused due to existence of both kernel parameters and may do unexpected things?
4) In case of sd-encrypt hook I noticed that default password retries is 3. (See tries= option) but in my case it allows only 2 tries and then fails. Anyone else noticed the same?
Please clarify.
Thank you.
Last edited by amish (2025-07-17 09:02:14)
Offline
First question thought :
https://wiki.archlinux.org/title/Genera … ery_shells mentions init=/bin/sh being available if systemd is broken.
Maybe that starts a busybox init which requires the stuff added by the base hook ?
Last edited by Lone_Wolf (2025-07-16 12:24:25)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I removed "base" from HOOK.
Did mkinitcpio -P.
Rebooted with init=/bin/sh
And I was able to boot to /bin/sh and run fsck etc.
So init=/bin/sh still works without "base" hook.
Offline
More testing.
1) Ran mkinitcpio -P with "base" hook.
2) Extracted initrd to temporary directory say t1 (cd t1; bsdcpio -i -d < /boot/initramfs-linux.img)
3) Ran /boot/initramfs-linux.img without "base" hook.
4) Extracted initrd to temporary directory say t2 (cd t2; bsdcpio -i -d < /boot/initramfs-linux.img)
Ran: diff -r --brief t1 t2
This reports no difference in t1 and t2
However size of two initrd differs. One with "base" is bit more size than one without "base". About 400KB more.
So there is something extra but it does not get extracted via bsdcpio?
Am I missing something, technical?
Offline
Use lsinitcpio instead of bsdcpio, see https://wiki.archlinux.org/title/Mkinit … _the_image
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Great. Thank you very much for that tip.
So, mkinit CPIO images have two types of data embedded. Early and Main.
So Early cpio image remains same, regardless of, if "base" hook is included or not.
But when "base" hook is included, then Main cpio image has many additional and essential binaries (like chmod, chown etc).
So in general even though "base" hook is optional when using systemd hook, it should be highly recommended.
I think, Wiki page for Mkinitcpio should mention the importance of including "base" hook even for systemd based initial ramdisk.
Offline
For questions 2, 3, 4
2) I tried both ways in my case and did not seem to make any difference. But answer from experts may provide further clarity.
3) I tried this too and system booted in both cases (busybox or systemd). But not sure if any program/tool looking at kernel parameters may break or do unexpected thing.
4) Definitely seems to be bug. It asks for password just two times and not three times.
If anyone can clarify then please do.
Thank you.
Last edited by amish (2025-07-17 09:07:44)
Offline
The utilities added with the base hook come from busybox.
They tend to be less powerful then the coreutils equivalents but are statically built, don't need external deps and work 99.9999% of the time.
Once the coreutils get available, those are used.
You may want to start a discussion on the talk page for mkinitcpio about changing the entry for the base hook.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I went to talk page and realized that there is already discussion about base vs systemd, and the recovery shell
I could not figure out from that discussion if "base" should be added or not.
But I guess I will just add it. As it includes some binaries which may be needed.
Offline
Part of the reason you don't get responses may be that our forum users prefer 1 question per thread.
Creating new threads for each question might attract more attention.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Ok created three new threads for remaining 3 questions.
Q2) mkinitcpio.conf - should block hook be before sd-encrypt or after?
Q3) Is it safe to use kernel parameters of both sd-encrypt and encrypt?
Q4) systemd-cryptsetup asking for password one less time than tries=N?
Offline