New install - issues with boot cmdlines (i'm assuming)

Mrkd1904 · 2025-04-26 01:13:07

Hello,

I recently rebuilt a RAID array with news disks on my PC. I'm having issues now with booting into this new system.

Here's the output of

lsblk

root@archiso ~ # lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                   7:0    0 824.9M  1 loop  /run/archiso/airootfs
sda                     8:0    1  57.3G  0 disk
├─sda1                  8:1    1   999M  0 part
└─sda2                  8:2    1   180M  0 part
nvme3n1               259:0    0   1.8T  0 disk
├─md126                 9:126  0   3.6T  0 raid5
│ └─mdroot            254:0    0   3.6T  0 crypt
│   ├─mdroot1         254:1    0     1T  0 part
│   │ └─vgroot        254:3    0  1024G  0 crypt
│   │   ├─linux0-root 254:4    0   124G  0 lvm   /var/local/mount/00
│   │   ├─linux0-home 254:5    0   256G  0 lvm   /var/local/mount/00/home
│   │   ├─linux0-var  254:6    0    64G  0 lvm   /var/local/mount/00/var
│   │   ├─linux0-opt  254:7    0    64G  0 lvm   /var/local/mount/00/opt
│   │   └─linux0-srv  254:8    0   512M  0 lvm   /var/local/mount/00/srv
│   └─mdroot2         254:2    0     1T  0 part
└─md127                 9:127  0     0B  0 md
nvme1n1               259:1    0   1.8T  0 disk
├─md126                 9:126  0   3.6T  0 raid5
│ └─mdroot            254:0    0   3.6T  0 crypt
│   ├─mdroot1         254:1    0     1T  0 part
│   │ └─vgroot        254:3    0  1024G  0 crypt
│   │   ├─linux0-root 254:4    0   124G  0 lvm   /var/local/mount/00
│   │   ├─linux0-home 254:5    0   256G  0 lvm   /var/local/mount/00/home
│   │   ├─linux0-var  254:6    0    64G  0 lvm   /var/local/mount/00/var
│   │   ├─linux0-opt  254:7    0    64G  0 lvm   /var/local/mount/00/opt
│   │   └─linux0-srv  254:8    0   512M  0 lvm   /var/local/mount/00/srv
│   └─mdroot2         254:2    0     1T  0 part
└─md127                 9:127  0     0B  0 md
nvme4n1               259:2    0   1.8T  0 disk
├─nvme4n1p1           259:4    0    16M  0 part
├─nvme4n1p2           259:5    0 495.8G  0 part
├─nvme4n1p3           259:6    0     1G  0 part
├─nvme4n1p4           259:7    0   100M  0 part
├─nvme4n1p5           259:8    0 496.1G  0 part
└─nvme4n1p6           259:9    0   822M  0 part
nvme2n1               259:3    0   1.8T  0 disk
├─md126                 9:126  0   3.6T  0 raid5
│ └─mdroot            254:0    0   3.6T  0 crypt
│   ├─mdroot1         254:1    0     1T  0 part
│   │ └─vgroot        254:3    0  1024G  0 crypt
│   │   ├─linux0-root 254:4    0   124G  0 lvm   /var/local/mount/00
│   │   ├─linux0-home 254:5    0   256G  0 lvm   /var/local/mount/00/home
│   │   ├─linux0-var  254:6    0    64G  0 lvm   /var/local/mount/00/var
│   │   ├─linux0-opt  254:7    0    64G  0 lvm   /var/local/mount/00/opt
│   │   └─linux0-srv  254:8    0   512M  0 lvm   /var/local/mount/00/srv
│   └─mdroot2         254:2    0     1T  0 part
└─md127                 9:127  0     0B  0 md
nvme0n1               259:10   0 931.5G  0 disk
├─nvme0n1p1           259:11   0     1G  0 part  /var/local/mount/00/boot/efi
└─nvme0n1p2           259:12   0 930.5G  0 part

The issue is that I'm having to manually run

partprobe

to get /dev/mapper/mdroot{1,2} to populate. At boot, it'll prompt to open /dev/mapper/mdroot but then hang on finding /dev/mapper/mdroot1 and /dev/mapper/linux0-root and then tell me the root account is locked therefor not getting me to the rescue screen.

Here's the output of /etc/kernel/cmdline:

nvme_load=yes rd.luks.uuid=luks-c3fe5524-cd73-4fa4-8d83-0b37a217cb9b rd.luks.uuid=luks-5954dac1-0544-4f9f-ad76-9a4c07d71727 rd.lvm.lv=linux0/root rd.md.uuid=74061e02:80b9df06:af6faf0c:1118aa96 luks.rd.option=fido2-device=auto root=/dev/mapper/linux0-root rootfstype=f2fs lockdown=integrity module.sig_enfore

Here's my /etc/mkinitcpio.conf:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=(vmd dm_mod dm_crypt md_mod f2fs xfs vfat)

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=(mdadm lvm partprobe)

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=(/etc/mdadm.conf)

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   This will create a systemd based initramfs which loads an encrypted root filesystem.
#    HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base systemd udev autodetect microcode modconf kms keyboard keymap sd-vconsole sd-encrypt mdadm_udev lvm2 consolefont block filesystems fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"

Here's the output of crypttab:

GNU nano 8.4                                             crypttab                                             Restricted
# Configuration for encrypted block devices.
# See crypttab(5) for details.

# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf).

# <name>       <device>                                     <password>              <options>
# home         UUID=b8ad5c18-f445-495d-9095-c9ec4f9d2f37    /etc/mypassword1
# data1        /dev/sda3                                    /etc/mypassword2
# data2        /dev/sda5                                    /etc/cryptfs.key
# swap         /dev/sdx4                                    /dev/urandom            swap,cipher=aes-cbc-essiv:sha256,size=2>
# vol          /dev/sdb7                                    none

mdroot UUID=2651b5d8-f3bc-437a-a192-30018dcb3c9c
mdroot1 UUID=5954dac1-0544-4f9f-ad76-9a4c07d71727
vgroot UUID=nVAeln-cHPe-7K2A-NRo9-Gihp-O2uR-rUtyHl

output of blkid:

root@archiso ~ # blkid
/dev/mapper/mdroot1: UUID="5954dac1-0544-4f9f-ad76-9a4c07d71727" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="921aa5a6-7f32-4e3a-8233-8f761bab1bfe"
/dev/nvme0n1p1: UUID="C9F4-EE24" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI" PARTUUID="ccebed9c-5aef-4161-87a5-a2f0ce7e42ff"
/dev/nvme0n1p2: UUID="e597408e-6437-40ee-9274-a82956a50424" TYPE="crypto_LUKS" PARTLABEL="endeavouros" PARTUUID="ab2720f0-ba6b-478d-a36e-1369250fecfa"
/dev/nvme3n1: TYPE="isw_raid_member"
/dev/mapper/linux0-srv: UUID="4134c8d9-6fff-4fb5-90c6-0369a45a8dae" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/linux0-var: UUID="ee488e2d-ae44-47f3-8e1f-3fdf55ef1703" BLOCK_SIZE="512" TYPE="xfs"
/dev/mapper/linux0-root: UUID="2bfb62c3-bfbd-45fc-8024-ebb090b88d7f" BLOCK_SIZE="4096" TYPE="f2fs"
/dev/nvme2n1: TYPE="isw_raid_member"
/dev/mapper/mdroot2: PARTLABEL="Linux filesystem" PARTUUID="8d534fc6-5bcc-4c7a-a899-ce7559c33fa1"
/dev/loop0: BLOCK_SIZE="1048576" TYPE="squashfs"
/dev/mapper/mdroot: PTUUID="2651b5d8-f3bc-437a-a192-30018dcb3c9c" PTTYPE="gpt"
/dev/md126: UUID="c3fe5524-cd73-4fa4-8d83-0b37a217cb9b" TYPE="crypto_LUKS"
/dev/mapper/linux0-opt: UUID="d4d70520-58a9-421f-b102-9e0129b2f762" BLOCK_SIZE="4096" TYPE="ext4"
/dev/nvme1n1: TYPE="isw_raid_member"
/dev/sda2: LABEL_FATBOOT="ARCHISO_EFI" LABEL="ARCHISO_EFI" UUID="679D-DB59" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5f3bc01a-02"
/dev/sda1: BLOCK_SIZE="2048" UUID="2025-02-01-08-29-13-00" LABEL="ARCH_202502" TYPE="iso9660" PARTUUID="5f3bc01a-01"
/dev/mapper/linux0-home: UUID="3d5a6643-0e38-4394-8657-e85af31b0af7" UUID_SUB="e44fb6d3-0ee7-4324-9a1c-c61b5d84f478" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/nvme4n1p5: BLOCK_SIZE="512" UUID="C612BA6612BA5ADF" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="b3cd2dcf-3fd6-4ab6-9733-5737f8d636cc"
/dev/nvme4n1p3: UUID="C4AB-B63E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Microsoft basic data" PARTUUID="130e4512-8879-43d8-971e-dca67dc7eba1"
/dev/nvme4n1p1: PARTLABEL="Microsoft reserved partition" PARTUUID="f672395e-7418-44ab-aa1f-bb2c49c9c94b"
/dev/nvme4n1p6: BLOCK_SIZE="512" UUID="4288C23A88C22C6B" TYPE="ntfs" PARTUUID="0d7d1a81-605d-4624-81da-82176acb5a6c"
/dev/nvme4n1p4: UUID="AEB9-10A8" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="bb5a34f0-1e3a-40c2-abbd-fdf49f373214"
/dev/nvme4n1p2: BLOCK_SIZE="512" UUID="7E743011742FCAAB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="36c6fc2c-149c-40fe-871c-1b36d68b2d3e"
/dev/mapper/vgroot: UUID="nVAeln-cHPe-7K2A-NRo9-Gihp-O2uR-rUtyHl" TYPE="LVM2_member"

I think what I'm missing here is a function to be able to add an initramfs script to run partprobe. Any help is appreciated.

seth · 2025-04-26 06:52:39

HOOKS=(base systemd udev autodetect microcode modconf kms keyboard keymap sd-vconsole sd-encrypt mdadm_udev lvm2 consolefont block filesystems fsck)

https://wiki.archlinux.org/title/Mkinit … mmon_hooks
Choose systemd XOR busybox, not both (and probably try either)

Mrkd1904 · 2025-04-28 19:37:44

seth wrote:

HOOKS=(base systemd udev autodetect microcode modconf kms keyboard keymap sd-vconsole sd-encrypt mdadm_udev lvm2 consolefont block filesystems fsck)
https://wiki.archlinux.org/title/Mkinit … mmon_hooks
Choose systemd XOR busybox, not both (and probably try either)

So just to be clear; it's either base, or systemd. Not both, correct? Going to try tonight. I was under the impression you needed base no matter the situation.

seth · 2025-04-28 19:39:45

base is optional for systemd, mandatory for busybox - the overlap in your hooks is udev/systemd

Mrkd1904 · 2025-04-30 21:53:49

seth wrote:

base is optional for systemd, mandatory for busybox - the overlap in your hooks is udev/systemd

Removing systemd and adding base & udev gets me to a rescue screen finally. After having to add usbhid to MODULES and cryptsetup to BINARIES I'm able to bail out, unlock the first disk, partprobe, and then unlock the second disk and vgchange -a y to finally populate my root partition. BUT, am either rusty or ignorant as even after adding all partitions to /new_root and hitting 'exit' I'm getting the "/sbin/init is not found" warning and then kernel panic if 'exit' is prompted again. I'm having trouble remembering how to run-init manually. Normally I'd just add the root partitions to /new_root and exit. So, almost there.

I remember at some point in the past I was in a similar situation and was able to chroot into /new_root, add all of the necessary sysfs, devtmpfs, etc and somehow use systemctl to either run init or somehow initialize the system. But I'm sure there's an easier way.

seth · 2025-05-01 07:54:54

If you're going for busybox, sd-encrypt and sd-vconsole are wrong, https://wiki.archlinux.org/title/Dm-cry … mkinitcpio

Mrkd1904 · 2025-07-15 16:15:44

Necro-bumping this as I still cannot figure it out.

In the meantime I have installed another less complex instance but still have been taking swipes at the instance I posted this about occasionally.

I have now tried: creating a systemd service, a HOOK, and even have tried booting into the emergency shell by setting a different root partition on the cmdline and fstab to no avail.

The best shot I think I had was trying to create a systemd service that executed /sbin/partprobe on the offending partition but still have had no luck.

I have it at /etc/systemd/system/sysd-partprobe.service:

[Unit]
Description=Run partprobe on decrypted cryptdisk
Requires=cryptsetup.target
After=cryptsetup.target
BindsTo=dev-mapper-mdroot.device  
After=dev-mapper-mdroot.device

[Service]
Type=oneshot
ExecStart=/sbin/partprobe /dev/mapper/mdroot
RemainAfterExit=yes

[Install]
WantedBy=local-fs.target

The service is enabled. mkinitcpio -P all is ran after every cmdline or config change.

I cannot get to the emergency shell no matter what I've tried. At least from there I can run partprobe manually. I have everything set in mkinitcpio.conf to run as a systemd system at boot. I have tried running the cmdlines: rd.break, emergency, and init=/bin/sh, etc. But keep getting that the console is locked because it can't find the root partition, because the containing partition needs to be partprobe'd. Is there something particular I need to do to tell systemd to run that specific service earlier than the rest?

Moderator Edit

Necro-bumping this as I still cannot figure it out.

You did add new info and are the topic starter. This post is not a necro-bump.

Last edited by Lone_Wolf (2025-07-16 13:00:19)

seth · 2025-07-15 21:31:59

Skip that service, instead see whether you can get more debug output, https://wiki.archlinux.org/title/Genera … l_messages
Also what does your mkinitcpio.conf look like atm?

Mrkd1904 · 2025-07-16 02:36:02

seth wrote:

Skip that service, instead see whether you can get more debug output, https://wiki.archlinux.org/title/Genera … l_messages
Also what does your mkinitcpio.conf look like atm?

/etc/mkinitcpio.conf:

# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=()

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=(mdadm lvm partprobe cryptsetup)

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=(/etc/mdadm.conf)

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   This will create a systemd based initramfs which loads an encrypted root filesystem.
#    HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck partprobe)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base systemd autodetect microcode modconf kms keyboard keymap sd-vconsole sd-encrypt mdadm_udev partprobe lvm2 consolefont block filesystems fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"

/etc/kernel/cmdline:

rd.driver.pre=btrfs rd.luks.uuid=luks-c3fe5524-cd73-4fa4-8d83-0b37a217cb9b rd.luks.uuid=luks-5954dac1-0544-4f9f-ad76-9a4c07d71727  rd.lvm.lv=linux0/rootrd.md.uuid=74061e02:80b9df06:af6faf0c:1118aa96 root=/dev/mapper/linux0-root rootfstype=f2fs rootflags=rw,relatime,lazytime,background_gc=on,nogc_merge,nodiscard,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,barrier,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,memory=normal,errors=continue debug

just added debug to cmdline.

EDIT: just tried running journalctl --reverse out of curiosity (in chroot) and got

No journal files were found.

Last edited by Mrkd1904 (2025-07-16 02:37:51)

seth · 2025-07-16 06:03:58

Are you dead-set on using systemd instead of busybox for the initramfs?
https://wiki.archlinux.org/title/RAID#C … mkinitcpio

Also put the encrypt hook between block and lvm2, https://wiki.archlinux.org/title/Dm-cry … n#Examples - ie. your block hook is too late.

Also sanity check: What does /etc/mdadm.conf look like? Did you manually create it or using mdadm --detail --scan ?
(The wiki example uses ">>" what will extend the exising file, if you didn't clean it up afterwards, it could be full of cruft)

Mrkd1904 · 2025-07-16 11:26:45

seth wrote:

Are you dead-set on using systemd instead of busybox for the initramfs?
https://wiki.archlinux.org/title/RAID#C … mkinitcpio
Also put the encrypt hook between block and lvm2, https://wiki.archlinux.org/title/Dm-cry … n#Examples - ie. your block hook is too late.
Also sanity check: What does /etc/mdadm.conf look like? Did you manually create it or using mdadm --detail --scan ?
(The wiki example uses ">>" what will extend the exising file, if you didn't clean it up afterwards, it could be full of cruft)

I'm not dead set on using systemd, but prefer it as I've used a Yubikey for unlock the past couple years on everything and wish to use systemd-cryptsetup instead of just cryptsetup. Tomorrow I'll have some time to play around with initramfs via busybox.

/etc/mdadm.conf:

ARRAY metadata=imsm UUID=74061e02:80b9df06:af6faf0c:1118aa96
ARRAY /dev/md/md0 container=74061e02:80b9df06:af6faf0c:1118aa96 member=0 UUID=a5164d25:0faaa475:06c24a2b:87308d5f

Was created using:

mdadm -E --scan > /etc/mdadm.conf

Adjusted the encrypt hook. Will report back if any changes.

EDIT: Alright, back to square two.

Adjusted mkinitcpio to run busybox. At boot, it hangs on finding /dev/mapper/linux0-root and doesn't prompt me to unlock anything. But, I was able to bail out into an emergency shell, unlock the initial RAID partition, partprobe, and then unlock the partition containing my LVM partitions... but; At first for whatever reason it wasn't loading the xfs (for my /var partition) mod which was rectified by adding it to the MODULES section of mkinitcpio.conf. But now, once all partitions are added to /new_root/ and i hit 'exit' it's telling me:

switch_root: failed to execute /sbin/init: Exec format error

which i find peculiar.

/etc/mkinitcpio.conf:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=(xfs)

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=(mdadm lvm partprobe cryptsetup)

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=(/etc/mdadm.conf)

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   This will create a systemd based initramfs which loads an encrypted root filesystem.
#    HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck partprobe)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap mdadm_udev encrypt partprobe lvm2 consolefont block filesystems fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"

Obviously once I try and bail and init fails the system locks up. Nothing of note in the debug output either.

EDIT2: upon a second glance I may be calling mdadm_udev too early? Just adjusted to set it behind block, letting the array resync and then will try again.

EDIT3: pretty sure adjusting the hooks, or the resync helped as now i'm just getting

Trying to continue (this will most likely fail) . . .
:: running cleanup hook [udev]

HOOKS in mkinitcpio is:

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap block mdadm_udev encrypt consolefont lvm2 filesystems fsck)

Still hanging after 'exit'

@seth

Last edited by Mrkd1904 (2025-07-18 19:09:04)

Mrkd1904 · 2025-08-13 02:27:56

Bump. So close yet so far. Going to take another pass at this in depth Thursday; but as of right now i'm unable to get the system to boot after bailing to shell, unlocking, partprob'ing, and then mounting all the partitions manually.

I'm just hitting 'exit' in which it'll hang. Any other more finessed ways to go about it?

cryptearth · 2025-08-13 05:39:09

so I tried to re-create your initial setup - but I wasn't able to

vda               254:0    0    50G  0 disk  
└─vda1            254:1    0     1G  0 part  
vdb               254:16   0    20G  0 disk  
└─md127             9:127  0    40G  0 raid5 
  └─mdroot        253:0    0    40G  0 crypt 
    └─vgroot-root 253:1    0    20G  0 lvm   
vdc               254:32   0    20G  0 disk  
└─md127             9:127  0    40G  0 raid5 
  └─mdroot        253:0    0    40G  0 crypt 
    └─vgroot-root 253:1    0    20G  0 lvm   
vdd               254:48   0    20G  0 disk  
└─md127             9:127  0    40G  0 raid5 
  └─mdroot        253:0    0    40G  0 crypt 
    └─vgroot-root 253:1    0    20G  0 lvm

according to how I understand your initial post you somehow partitioned the mdroot and then setup another luks container and then inside that the LVM?
whatever you did I wasn't able to replicate
yes - I could fdisk /dev/mapper/mdroot - but it never showed up a mdroot1 as partition

I was really eager to help - but I wasn't even able to recreate your initial setup with all this nested raid-luks-partition-luks-lvm magic
how you were able to partition the luks container?

seth · 2025-08-13 06:24:29

@seth

no, this doesn't work.
If you return after a while with updates on the situation you may post instead of edit - otherwise they go stealth.

https://wiki.archlinux.org/title/Dm-cry … lockdevice

One exception is when the mdadm_udev hook is used already (e.g. for the root device). In this case /etc/madadm.conf [sic] and the initramfs need updating to achieve the correct root raid is picked first.

=> https://wiki.archlinux.org/title/RAID#U … ation_file

Mrkd1904 · 2025-08-14 19:18:01

seth wrote:

@seth
no, this doesn't work.
If you return after a while with updates on the situation you may post instead of edit - otherwise they go stealth.
https://wiki.archlinux.org/title/Dm-cry … lockdevice
One exception is when the mdadm_udev hook is used already (e.g. for the root device). In this case /etc/madadm.conf [sic] and the initramfs need updating to achieve the correct root raid is picked first.
=> https://wiki.archlinux.org/title/RAID#U … ation_file

Ok this is confusing to me:

One exception is when the mdadm_udev hook is used already (e.g. for the root device). In this case /etc/madadm.conf and the initramfs need updating to achieve the correct root raid is picked first.

Do i need to add /dev/mapper/mdroot1 to /etc/mdadm.conf? Or do I need to add something additional to /etc/crypttab? Or add another mdadm_udev hook to mkinitcpio?

Particularly this portion:

and the initramfs need updating to achieve the correct root raid is picked first.

is unclear to me.

seth · 2025-08-14 20:48:23

Did you see https://wiki.archlinux.org/title/RAID#U … ation_file ?
Your probably updating the initramfs w/ https://wiki.archlinux.org/title/Mkinitcpio

Mrkd1904 · 2025-08-15 00:54:07

seth wrote:

Did you see https://wiki.archlinux.org/title/RAID#U … ation_file ?
Your probably updating the initramfs w/ https://wiki.archlinux.org/title/Mkinitcpio

Ok, now i must be totally missing something. I am using mkinitcpio, and am unaware of any other program to use to update the initramfs besides dracut, which errors out since chroot'd. I have /etc/mdadm.conf referenced in /etc/mkinitcpio.conf under FILES. Am I just being dense here?

Last edited by Mrkd1904 (2025-08-15 01:13:23)

seth · 2025-08-15 12:34:00

https://wiki.archlinux.org/title/RAID#U … ation_file
Did you run "mdadm --detail --scan >> /etc/mdadm.conf" and /then/ mkinitcpio and what does your /etc/mdadm.conf look like?

Mrkd1904 · 2025-08-17 12:07:21

seth wrote:

https://wiki.archlinux.org/title/RAID#U … ation_file
Did you run "mdadm --detail --scan >> /etc/mdadm.conf" and /then/ mkinitcpio and what does your /etc/mdadm.conf look like?

Yes, religiously after every config change I run mkinitcpio -P all.

/etc/mdadm.conf:

ARRAY metadata=imsm UUID=74061e02:80b9df06:af6faf0c:1118aa96
ARRAY /dev/md/md0 container=74061e02:80b9df06:af6faf0c:1118aa96 member=0 UUID=a5164d25:0faaa475:06c24a2b:87308d5f

That's why I was asking if i needed to add another array for some reason?

Mrkd1904 · 2025-08-17 12:20:31

cryptearth wrote:

so I tried to re-create your initial setup - but I wasn't able to
vda               254:0    0    50G  0 disk  
└─vda1            254:1    0     1G  0 part  
vdb               254:16   0    20G  0 disk  
└─md127             9:127  0    40G  0 raid5 
  └─mdroot        253:0    0    40G  0 crypt 
    └─vgroot-root 253:1    0    20G  0 lvm   
vdc               254:32   0    20G  0 disk  
└─md127             9:127  0    40G  0 raid5 
  └─mdroot        253:0    0    40G  0 crypt 
    └─vgroot-root 253:1    0    20G  0 lvm   
vdd               254:48   0    20G  0 disk  
└─md127             9:127  0    40G  0 raid5 
  └─mdroot        253:0    0    40G  0 crypt 
    └─vgroot-root 253:1    0    20G  0 lvm
according to how I understand your initial post you somehow partitioned the mdroot and then setup another luks container and then inside that the LVM?
whatever you did I wasn't able to replicate
yes - I could fdisk /dev/mapper/mdroot - but it never showed up a mdroot1 as partition
I was really eager to help - but I wasn't even able to recreate your initial setup with all this nested raid-luks-partition-luks-lvm magic
how you were able to partition the luks container?

So I apologize as I've been meaning to reply to you but have been stupid busy.

In short what I did was created the hardware RAID array, encrypted the full array, opened it to mdroot, and then partitioned that dm disk into three more partitions using gdisk (mdroot1, mdroot2, mdroot3). I then encrypted /dev/mapper/mdroot1 and turned that into a lvm physical volume and vg (linux0, opened in dm as vgroot), and then created a logical volume for each partition.

The crux of this whole thread is that when you partition a device mapper disk you need to partprobe it in order for the system to recognize it. So, if you were to fdisk /dev/mapper/mdroot, you have to run partprobe for the new partitions to populate.

Where I'm stuck, is that there's no process for the kernel, or systemd to run partprobe to get me from /dev/mapper/mdroot to /dev/mapper/mdroot[1,2,3] at boot to unlock the second encrypted luks volume at /dev/mapper/mdroot1, because the system doesn't find it.

So, to put it simply it's /dev/md0 > /dev/mapper/mdroot > /dev/mapper/mdroot[1,2,3] > /dev/mapper/vgroot > /dev/mapper/linux0-[root,home,var,opt,srv]

or

RAID array > encrypted luks volume > partioned luks volume x3 > another encrypted luks volume at partition 1 > lvm volume group > lvm partitions.

In closing the entire issue is that kernel has no mechanism to call partprobe to find the three nested partitions within the first encrypted volume.

├─md126                 9:126  0   3.6T  0 raid5
│ └─mdroot            254:0    0   3.6T  0 crypt
│   ├─mdroot1         254:1    0     1T  0 part
│   │ └─vgroot        254:3    0  1024G  0 crypt
│   │   ├─linux0-root 254:4    0   124G  0 lvm   /var/local/mount/00
│   │   ├─linux0-home 254:5    0   256G  0 lvm   /var/local/mount/00/home
│   │   ├─linux0-var  254:6    0    64G  0 lvm   /var/local/mount/00/var
│   │   ├─linux0-opt  254:7    0    64G  0 lvm   /var/local/mount/00/opt
│   │   └─linux0-srv  254:8    0   512M  0 lvm   /var/local/mount/00/srv

EDIT: I do appreciate the willingness to help, by the way.

Last edited by Mrkd1904 (2025-08-17 12:27:54)

cryptearth · 2025-08-17 14:14:25

ok - finally got it working with the help of gemini and some tricky issues
it is possible - without systemd and with just two simple additional hooks
to compress all that stuff: I managed to rebuild your setup after I learned that one has to call partprobe <device> instead of just partprobe without parameters (DOH)
the key is this: grub only gets one cryptdevice - the outer one - reason (as explained by AI): the encrypt hook tries to unlock ALL given cryptdevices and fails entirely if it struggles with just one before asking for any passphrases; that's why you not get asked for the outer container as the hook fails for the inner one which does not exist yet
after the encrypt hook unlocks the outer container then a custom hook for partprobe is run - and after that, as there's no way to add encrypt twice to re-run it a 2nd custom hook is run to call cryptsetup open on the now available mdroot1

custom hooks:

[main@crypto ~]$ cat /etc/initcpio/install/partprobe-mdroot 
#!/bin/bash
build() {
        add_binary "partprobe"
        add_runscript
}
[main@crypto ~]$ cat /etc/initcpio/install/unlock-vgroot 
#!/bin/bash
build() {
        add_binary "cryptsetup"
        add_binary "dmsetup"
        add_runscript
}
[main@crypto ~]$ cat /etc/initcpio/hooks/partprobe-mdroot 
#!/bin/bash
run_hook() {
        sleep 2
        /usr/bin/partprobe /dev/mapper/mdroot
}
run_late() {
        return 0
}
[main@crypto ~]$ cat /etc/initcpio/hooks/unlock-vgroot 
#!/bin/bash
run_hook() {
        sleep 2
        cryptsetup open /dev/mapper/mdroot1 vgroot
}

and the hook line in mkinitcpio becomes

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block mdadm_udev encrypt partprobe-mdroot unlock-vgroot lvm2 filesystems fsck)

gemini also suggested switching to system as it seems to be able to handle this - but I not tried that - maybe someone else want to give that a try?

// original post

well - although we should be careful when using AI I found gemini pro within google ai studio quite helpful and (although a bit simplified) there seems to be a way to trigger a call to partprobe within the initrd phase (for the sake of archiving I rather copy the prompt and the output than just linking as I don't know how long it will be available) https://aistudio.google.com/app/prompts … sp=sharing

upfront: I was NOT able to confirm this!
reason: after partition the mdroot and calling partprobe no additional mdroo1 showed up for me
as I'm already on 6.16 this could be specific to the new kernel version and might be different on lts-6.12 - but I don't know how to boot an install environment with an lts kernel without setting up an entire regular install

so - to everyone: please take the following with a big grain of salt - as I just copied over what gemini gave me and it sounds ok so far - but for me it just not worked while even setting up the initial install
if someone gets this to work maybe that's a base for further nesting just by adding additional hooks in order to unlock the nested luks containers within the partitions and then add LVM
it's pretty much the same idea but with an additional hook rather than a service

// update - according to gemini I need kpartx - worked so far ... diving deeper

prompt

For a new Arch Linux setup I'd like to use nested virtual containers. I begun by first create an md raid array over 3 physical drives as a RAID5. This gives me the first common node of /dev/md127. To protect my data I then create a LUKS container and open this to /dev/mapper/mdroot. Next I partition the opened crypto container into 3 partitions. In order for them to show up in /dev I have to run partprobe manually. After calling partprobe they show up as /dev/mapper/mdroot[1,2,3] and I proceed the install from there. As bootloader I install GRUB on a 4th physical drive not part of the md array.
Problem: On booting the kernel is not able to call partprobe during the initramfs phase to properly populate the partitions within the crypto container.
How do I get my system to boot?

output

It appears you're encountering a classic issue with complex storage setups in the early boot phase. The initramfs, a minimal root filesystem loaded into memory, is responsible for setting up your storage stack so the real root filesystem can be mounted. In your case, it unlocks the LUKS container but doesn't probe for partitions inside it. Here is a step-by-step guide to resolve this and get your system to boot.

The Problem: Missing Partition Discovery in Initramfs
The core of the problem is that after the encrypt hook in the initramfs unlocks your LUKS container (/dev/md127) and creates /dev/mapper/mdroot, the kernel is not aware of the partition table within this newly available device. Manually, you would run partprobe or kpartx to force the kernel to read the partition table and create the corresponding device nodes (/dev/mapper/mdroot1, etc.). To automate this during boot, you need to include this functionality within the initramfs itself.

The Solution: Customizing the Initramfs and GRUB
The solution involves modifying your mkinitcpio configuration to include the necessary tools and hooks, and ensuring your GRUB configuration passes the correct parameters to the kernel.

Step 1: Modify /etc/mkinitcpio.conf
First, you need to ensure your mkinitcpio.conf is set up to handle MD RAID and LUKS, and to include the partprobe utility.
1. Edit the HOOKS array: Open /etc/mkinitcpio.conf with a text editor. The order of the hooks is crucial. A correct hook order for your setup would be:

HOOKS=(base udev autodetect keyboard keymap modconf block mdadm_udev encrypt filesystems fsck)

- mdadm_udev: This assembles your RAID array.
- encrypt: This handles the unlocking of your LUKS container. It needs to run after the underlying RAID device is available.
2. Add partprobe to the BINARIES array: To make the partprobe command available in the initramfs, add it to the BINARIES array. If this array is commented out or doesn't exist, add it:

BINARIES=(partprobe)

Step 2: Add a Hook to Run partprobe
While partprobe is now included in the initramfs, you need to ensure it runs at the correct time—specifically, after the LUKS container is opened. The udev hook should ideally handle this, but in complex nested setups, it can fail. A reliable method is to add a small custom hook.
1. Create a new hook file for partprobe:
Create the file /etc/initcpio/hooks/partprobe-mdroot:

#!/bin/sh

run_hook() {
    partprobe /dev/mapper/mdroot
}

2. Make the hook executable:

chmod +x /etc/initcpio/hooks/partprobe-mdroot

3. Add the new hook to /etc/mkinitcpio.conf:
Insert your new partprobe-mdroot hook immediately after the encrypt hook:

HOOKS=(base udev autodetect keyboard keymap modconf block mdadm_udev encrypt partprobe-mdroot filesystems fsck)

Step 3: Regenerate the Initramfs
After saving your changes to /etc/mkinitcpio.conf, you need to regenerate the initramfs images:

mkinitcpio -P

Step 4: Configure GRUB
Finally, you need to ensure your GRUB configuration tells the kernel where to find your encrypted root filesystem.
1. Edit /etc/default/grub:
You need to set the GRUB_CMDLINE_LINUX variable. This will pass the necessary parameters to the kernel at boot.
- First, get the UUID of your MD RAID device (/dev/md127) by running lsblk -f.
- Then, edit /etc/default/grub and set the following, replacing <your-md127-uuid> with the actual UUID:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=<your-md127-uuid>:mdroot root=/dev/mapper/mdroot1"

- cryptdevice=UUID=<your-md127-uuid>:mdroot: This tells the encrypt hook to unlock the device with the specified UUID and map it to /dev/mapper/mdroot.
- root=/dev/mapper/mdroot1: This specifies that your root filesystem is on the first partition of the decrypted container. Adjust the number if your root is on a different partition (e.g., mdroot2).
2. Generate the GRUB configuration file:
After saving the changes, run the following command to generate the final GRUB configuration:

grub-mkconfig -o /boot/grub/grub.cfg

After completing these steps, reboot your system. The initramfs should now successfully assemble the RAID array, unlock the LUKS container, probe for the partitions within it, and mount your root filesystem, allowing the boot process to continue normally.

Last edited by cryptearth (2025-08-17 17:16:34)

Mrkd1904 · 2025-10-09 16:01:12

cryptearth wrote:

ok - finally got it working with the help of gemini and some tricky issues
it is possible - without systemd and with just two simple additional hooks
to compress all that stuff: I managed to rebuild your setup after I learned that one has to call partprobe <device> instead of just partprobe without parameters (DOH)
the key is this: grub only gets one cryptdevice - the outer one - reason (as explained by AI): the encrypt hook tries to unlock ALL given cryptdevices and fails entirely if it struggles with just one before asking for any passphrases; that's why you not get asked for the outer container as the hook fails for the inner one which does not exist yet
after the encrypt hook unlocks the outer container then a custom hook for partprobe is run - and after that, as there's no way to add encrypt twice to re-run it a 2nd custom hook is run to call cryptsetup open on the now available mdroot1
custom hooks:
[main@crypto ~]$ cat /etc/initcpio/install/partprobe-mdroot 
#!/bin/bash
build() {
        add_binary "partprobe"
        add_runscript
}
[main@crypto ~]$ cat /etc/initcpio/install/unlock-vgroot 
#!/bin/bash
build() {
        add_binary "cryptsetup"
        add_binary "dmsetup"
        add_runscript
}
[main@crypto ~]$ cat /etc/initcpio/hooks/partprobe-mdroot 
#!/bin/bash
run_hook() {
        sleep 2
        /usr/bin/partprobe /dev/mapper/mdroot
}
run_late() {
        return 0
}
[main@crypto ~]$ cat /etc/initcpio/hooks/unlock-vgroot 
#!/bin/bash
run_hook() {
        sleep 2
        cryptsetup open /dev/mapper/mdroot1 vgroot
}
and the hook line in mkinitcpio becomes
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block mdadm_udev encrypt partprobe-mdroot unlock-vgroot lvm2 filesystems fsck)
gemini also suggested switching to system as it seems to be able to handle this - but I not tried that - maybe someone else want to give that a try?
// original post
well - although we should be careful when using AI I found gemini pro within google ai studio quite helpful and (although a bit simplified) there seems to be a way to trigger a call to partprobe within the initrd phase (for the sake of archiving I rather copy the prompt and the output than just linking as I don't know how long it will be available) https://aistudio.google.com/app/prompts … sp=sharing
upfront: I was NOT able to confirm this!
reason: after partition the mdroot and calling partprobe no additional mdroo1 showed up for me
as I'm already on 6.16 this could be specific to the new kernel version and might be different on lts-6.12 - but I don't know how to boot an install environment with an lts kernel without setting up an entire regular install
so - to everyone: please take the following with a big grain of salt - as I just copied over what gemini gave me and it sounds ok so far - but for me it just not worked while even setting up the initial install
if someone gets this to work maybe that's a base for further nesting just by adding additional hooks in order to unlock the nested luks containers within the partitions and then add LVM
it's pretty much the same idea but with an additional hook rather than a service
// update - according to gemini I need kpartx - worked so far ... diving deeper
prompt
For a new Arch Linux setup I'd like to use nested virtual containers. I begun by first create an md raid array over 3 physical drives as a RAID5. This gives me the first common node of /dev/md127. To protect my data I then create a LUKS container and open this to /dev/mapper/mdroot. Next I partition the opened crypto container into 3 partitions. In order for them to show up in /dev I have to run partprobe manually. After calling partprobe they show up as /dev/mapper/mdroot[1,2,3] and I proceed the install from there. As bootloader I install GRUB on a 4th physical drive not part of the md array.
Problem: On booting the kernel is not able to call partprobe during the initramfs phase to properly populate the partitions within the crypto container.
How do I get my system to boot?
output
It appears you're encountering a classic issue with complex storage setups in the early boot phase. The initramfs, a minimal root filesystem loaded into memory, is responsible for setting up your storage stack so the real root filesystem can be mounted. In your case, it unlocks the LUKS container but doesn't probe for partitions inside it. Here is a step-by-step guide to resolve this and get your system to boot.
The Problem: Missing Partition Discovery in Initramfs
The core of the problem is that after the encrypt hook in the initramfs unlocks your LUKS container (/dev/md127) and creates /dev/mapper/mdroot, the kernel is not aware of the partition table within this newly available device. Manually, you would run partprobe or kpartx to force the kernel to read the partition table and create the corresponding device nodes (/dev/mapper/mdroot1, etc.). To automate this during boot, you need to include this functionality within the initramfs itself.
The Solution: Customizing the Initramfs and GRUB
The solution involves modifying your mkinitcpio configuration to include the necessary tools and hooks, and ensuring your GRUB configuration passes the correct parameters to the kernel.
Step 1: Modify /etc/mkinitcpio.conf
First, you need to ensure your mkinitcpio.conf is set up to handle MD RAID and LUKS, and to include the partprobe utility.
1. Edit the HOOKS array: Open /etc/mkinitcpio.conf with a text editor. The order of the hooks is crucial. A correct hook order for your setup would be:
HOOKS=(base udev autodetect keyboard keymap modconf block mdadm_udev encrypt filesystems fsck)
- mdadm_udev: This assembles your RAID array.
- encrypt: This handles the unlocking of your LUKS container. It needs to run after the underlying RAID device is available.
2. Add partprobe to the BINARIES array: To make the partprobe command available in the initramfs, add it to the BINARIES array. If this array is commented out or doesn't exist, add it:
BINARIES=(partprobe)
Step 2: Add a Hook to Run partprobe
While partprobe is now included in the initramfs, you need to ensure it runs at the correct time—specifically, after the LUKS container is opened. The udev hook should ideally handle this, but in complex nested setups, it can fail. A reliable method is to add a small custom hook.
1. Create a new hook file for partprobe:
Create the file /etc/initcpio/hooks/partprobe-mdroot:
#!/bin/sh

run_hook() {
    partprobe /dev/mapper/mdroot
}
2. Make the hook executable:
chmod +x /etc/initcpio/hooks/partprobe-mdroot
3. Add the new hook to /etc/mkinitcpio.conf:
Insert your new partprobe-mdroot hook immediately after the encrypt hook:
HOOKS=(base udev autodetect keyboard keymap modconf block mdadm_udev encrypt partprobe-mdroot filesystems fsck)
Step 3: Regenerate the Initramfs
After saving your changes to /etc/mkinitcpio.conf, you need to regenerate the initramfs images:
mkinitcpio -P
Step 4: Configure GRUB
Finally, you need to ensure your GRUB configuration tells the kernel where to find your encrypted root filesystem.
1. Edit /etc/default/grub:
You need to set the GRUB_CMDLINE_LINUX variable. This will pass the necessary parameters to the kernel at boot.
- First, get the UUID of your MD RAID device (/dev/md127) by running lsblk -f.
- Then, edit /etc/default/grub and set the following, replacing <your-md127-uuid> with the actual UUID:
GRUB_CMDLINE_LINUX="cryptdevice=UUID=<your-md127-uuid>:mdroot root=/dev/mapper/mdroot1"
- cryptdevice=UUID=<your-md127-uuid>:mdroot: This tells the encrypt hook to unlock the device with the specified UUID and map it to /dev/mapper/mdroot.
- root=/dev/mapper/mdroot1: This specifies that your root filesystem is on the first partition of the decrypted container. Adjust the number if your root is on a different partition (e.g., mdroot2).
2. Generate the GRUB configuration file:
After saving the changes, run the following command to generate the final GRUB configuration:
grub-mkconfig -o /boot/grub/grub.cfg
After completing these steps, reboot your system. The initramfs should now successfully assemble the RAID array, unlock the LUKS container, probe for the partitions within it, and mount your root filesystem, allowing the boot process to continue normally.

Ok - I apologize as the tab holding one of my m.2 drives from the RAID array broke which was causing havoc system wide before I noticed it, but finally fixed it.

Right before I started having those issues I did, successfully, follow your steps on creating the above HOOKS. But, and there's always a but, now whenever I boot into the system it'll start looking for the disks, and then I'll get a kernel panic. I'm still not getting any logs into journalctl so I can't further diagnose still. It's giving me that stupid blue screen with the exit code of "tried to kill init" which doesn't help either. I have a suspicion one or more of the HOOKS is overloading systemd at boot and causing the boot process to bail. Any thoughts?

Arch Linux

#1 2025-04-26 01:13:07

New install - issues with boot cmdlines (i'm assuming)

#2 2025-04-26 06:52:39

Re: New install - issues with boot cmdlines (i'm assuming)

#3 2025-04-28 19:37:44

Re: New install - issues with boot cmdlines (i'm assuming)

#4 2025-04-28 19:39:45

Re: New install - issues with boot cmdlines (i'm assuming)

#5 2025-04-30 21:53:49

Re: New install - issues with boot cmdlines (i'm assuming)

#6 2025-05-01 07:54:54

Re: New install - issues with boot cmdlines (i'm assuming)

#7 2025-07-15 16:15:44

Re: New install - issues with boot cmdlines (i'm assuming)

#8 2025-07-15 21:31:59

Re: New install - issues with boot cmdlines (i'm assuming)

#9 2025-07-16 02:36:02

Re: New install - issues with boot cmdlines (i'm assuming)

#10 2025-07-16 06:03:58

Re: New install - issues with boot cmdlines (i'm assuming)

#11 2025-07-16 11:26:45

Re: New install - issues with boot cmdlines (i'm assuming)

#12 2025-08-13 02:27:56

Re: New install - issues with boot cmdlines (i'm assuming)

#13 2025-08-13 05:39:09

Re: New install - issues with boot cmdlines (i'm assuming)

#14 2025-08-13 06:24:29

Re: New install - issues with boot cmdlines (i'm assuming)

#15 2025-08-14 19:18:01

Re: New install - issues with boot cmdlines (i'm assuming)

#16 2025-08-14 20:48:23

Re: New install - issues with boot cmdlines (i'm assuming)

#17 2025-08-15 00:54:07

Re: New install - issues with boot cmdlines (i'm assuming)

#18 2025-08-15 12:34:00

Re: New install - issues with boot cmdlines (i'm assuming)

#19 2025-08-17 12:07:21

Re: New install - issues with boot cmdlines (i'm assuming)

#20 2025-08-17 12:20:31

Re: New install - issues with boot cmdlines (i'm assuming)

#21 2025-08-17 14:14:25

Re: New install - issues with boot cmdlines (i'm assuming)

#22 2025-10-09 16:01:12

Re: New install - issues with boot cmdlines (i'm assuming)

Board footer