[Partially solved] Problem booting a devices after encryption

Succulent of your garden · 2026-03-17 12:15:30

So I'm adding to my script to install Arch Linux that automatically adds the UUID to /etc/default/grub and makes the last adjustments so the home encrypted partition gets mounted correctly.

so Here is the last part of the script:

#Setting up lusk partition for booting up
partitionLuskID=$(blkid | awk -F'"' 'NR == 3 { print $2 }') #Same as before
partitionHardwareID=$(blkid | awk -F'"' 'NR == 4 { print $2 }') #These lines assumes that always the second drive is encrypted

echo "Checking partition variables: "
echo "$partitionHardwareID"
echo "$partitionLuskID"


sed -i "/^GRUB_CMDLINE_LINUX_DEFAULT=/ s/\"$/ cryptdevice=UUID=$partitionHardwareID:cryptlvm root=UUID=$partitionLuskID\"/" /mnt/etc/default/grub

sed -i "/^HOOKS=/ s/\([^)]*\)/\1 encrypt lvm2/" /mnt/etc/mkinitcpio.conf

cp /root/ArchLinuxInstaller/endingSetup.sh /mnt/endingSetup.sh

echo "Checking variables before chrooting: "
echo "DISK: $DISK"
echo "BiosOrUefi: $BiosOrUefi"
sleep 10
arch-chroot /mnt /endingSetup.sh "$DISK" "$BiosOrUefi"

umount -R /mnt

$DISK and BiosOrUefi are variables that are previous initiated in the beginning of the script. They are okey because I check the values from the main script and also inside endingSetup.sh script. They have /dev/vda and 0 , because I'm testing in a BIOS virtual machine.

the endingSetup.sh script is this:

#!/bin/sh

DISK="$1"
BiosOrUefi="$2"


echo "Checking variables after chrooting: "
echo "DISK: $DISK"
echo "BiosUEFI: $BiosOrUefi"
sleep 10

mkinitcpio -P

if [ "$BiosOrUefi" = '64' ]
then
    grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
elif [ "$BiosOrUefi" = '32' ]
then
    grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
else
    grub-install "$DISK"
fi

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

exit

The issues is that when I reboot the boot gets idle in Loading init ramdisk. I don't know why. The script without encrypting with LUSK2 just works fine in the virtual machine, is just that when I encrypt the drive it does stays over there a couple of minutes and then send the failure signal into screen. I checked the sed commands to inject the UUID of the drive and the UUID of the /dev/mapper devices. Seems correct, also inside the " ", /etc/mkinitcpio.conf does have in HOOKS= the encrypt and lvm2 arguments. Also made the swap of $partitionHardwareID and $partitionLuskID [ yeah I know they are not "partitions" they are UUID, but gonna change the name into something different in the future that makes it more intuitive to what really the variable have] in the sed line that adds the UUID to the /etc/default/grub , just in case I had made the mistake by how goes first. But I mostly sure they are okey. Also checked the UUID with blkid command to see that matches the /dev/vda and /dev/mapper/"name of the encrypted drive by lusk command"

So I don't know what is happening. I'm makin this with the lastest arch iso realease, or at least the one that I downloaded the last sunday.

EDIT:

Also in this line:

    grub-install "$DISK"

I had added the flag --target=i386-pc and tried once, it doesn't works, and seems that grub always uses i386 in that context by default.

Last edited by Succulent of your garden (2026-03-22 23:54:22)

RealsteelArch · 2026-03-19 17:06:09

In your sed command for /etc/mkinitcpio.conf, you are appending encrypt lvm2 to the end of the HOOKS array. If encrypt and lvm2 appear after filesystems, the boot process will fail because the kernel tries to mount the filesystem before it has the tools to decrypt the container. Make sure encrypt and lvm2 come before filesystems. A safer way to do this:

sed -i 's/\(block\)/\1 encrypt lvm2/' /mnt/etc/mkinitcpio.conf

The "Loading initial ramdisk" hang occurs because the kernel can't find the cryptdevice. Your sed command

 sed -i "/^GRUB_CMDLINE_LINUX_DEFAULT=/ s/\"$/ cryptdevice=UUID=$partitionHardwareID:cryptlvm root=UUID=$partitionLuskID\"/" /mnt/etc/default/grub

: Your command uses :cryptlvm. Ensure that when you originally opened the device with cryptsetup open, you actually named it cryptlvm. If the names don't match the boot will hang. When the display is on

 Loading initial ramdisk

the kernel is working in the background but not telling you what's going on. In your script remove quiet from

GRUB_CMDLINE_LINUX_DEFAULT

. This will give you a verbose boot and tell you the real error which hopefully I can help with. Hope you figure it out

Succulent of your garden · 2026-03-19 22:54:44

RealsteelArch wrote:

sed -i 's/$block$/\1 encrypt lvm2/' /mnt/etc/mkinitcpio.conf

Thanks for the Regex ^^, the last days I notice that mistake and put the encrypt and lvm2 before filesystem. But still doesn't solve the issues, but it's an step ^^

RealsteelArch wrote:

Your command uses :cryptlvm. Ensure that when you originally opened the device with cryptsetup open, you actually named it cryptlvm. If the names don't match the boot will hang. When the display is on

I had now fix that, because in my script the cryptsetup open is in reality: cryptsetup open rootDrive . SO now :cryptlvm is now :rootDrive .Still it does not solve the issue.

Then i was thinking that maybe it was the absence of /etc/vconsole.conf like this: https://bbs.archlinux.org/viewtopic.php?id=310236 that maybe it was like corrupting the mkinitcpio. So I made the dummy "empty" /etc/vconsole.conf file and also it didn't solve the issue. Now just mkinitcpio -P does not show the warning/error

RealsteelArch wrote:

the kernel is working in the background but not telling you what's going on. In your script remove quiet from

I remove it, and now I can see this while booting:

Dependcy failed for File System Check on /dev/disk/by-uuid/<UUID that i had setup>

First try like a minute and a half to mount the device, but it does fail. I'm just sure that the UUID order in grub was right, so I change the order to see what happens. And this is the error if I do that:

linux failed to mount /sysroot

It just goes straight, it doesn't take a minute and a half. So I'm assuming that the kernel is noticing the pair of UUID and kinda link them. it's not saying like: Hey this is wrong, is kinda trying it.

I don't know what is going on wrong, I had made this manually like many maaany times and always works, not sure what I'm missing with my eyes and head

If you want to see the full script here it is: https://paste.ofcode.org/33gpBe8B5t8K4XSpH8Vh5JQ

Just forgive about some redundant stuff and some lines of code as comments
After solving this I'm gonna clean all of that.
And your sed regex is going to be implemented tomorrow
I'm tired I need to take a break and then sleep

Also readme is kinda outdated, just chmod also the other ending script

seth · 2026-03-20 08:53:32

https://wiki.archlinux.org/title/Dm-cry … ation#root
You don't have to specify root= at all and if, why are you not using the /dev/mapper/… syntax?

What do blkid, the generated grub.cfg and mkinitcpio.conf actually look like? And what is the UUID of the missing device?

Succulent of your garden · 2026-03-21 22:36:51

seth wrote:

You don't have to specify root= at all and if, why are you not using the /dev/mapper/… syntax?

Thanks! I didn't knew that. It seems that is in the /boot/grub/grub.cfg at the end. What do you mean about using the /dev/mapper/... syntax ? I know what a /dev/mapper is but how you can put it and in which file ? Please make an example ^^

seth wrote:

What do blkid, the generated grub.cfg and mkinitcpio.conf actually look like? And what is the UUID of the missing device?

This evening I had tried like everything that I can think of. And nothing changes :C. Here are the files:

/etc/defaul/grub: https://paste.c-net.org/AddieYankee

/etc/mkinitcpio.conf: https://paste.c-net.org/RevenueContrast

/etc/fstab: https://paste.c-net.org/MarchingCreator

/boot/grub/grub.cfg: https://paste.c-net.org/MobsterSnappy

blkid command: https://paste.c-net.org/CommentInward

All those files had been generated inside the chroot environment in /mnt. Including the blkid execution, as I saw it seems that it doesn't matter extracting the blkid info from out of /mnt chroot or in the arch-chroot /mnt . The UUID are fetched outside the arch-chroot /mnt as you can see in my first post of this thread. Grub is detected so in the first partition is everything okey, is the mounting of the second one that is causing the loading init ramdisk idle error :C

/dev/vda1 is the boot partition, /dev/vda2 have the encrypted root. So the /dev/mapper in /etc/fstab belongs to /dev/vda2 decryption. It's been opened by that name. You can see it in my full script.

I don't know what is happening. Like the UUIDs as I can see matches well in every file. I don't think that uncle Chuck break the latest Arch Linux Iso

I had been all the week trying to fix this and find the issue. I'm now into the hurry up face because I need to setup a device with Arch Soon
So any help much appreciated as always ^^

Probably I'm like bias and not seeing something because I had saw the code too much ? maybe who knows, time will tell ^^

EDIT:

Yes I'm testing it in a virtual machine. That's why /dev/vda
But I had also tried it in bare metal. It does makes the same error :C

Last edited by Succulent of your garden (2026-03-21 22:38:36)

frostschutz · 2026-03-21 23:02:26

Encrypt hook does not work with systemd, needs sd-encrypt. Different kernel parameters, too.

Alternatively switch to busybox based initcpio instead of using the systemd one.

Succulent of your garden · 2026-03-21 23:50:09

frostschutz wrote:

Encrypt hook does not work with systemd, needs sd-encrypt.

The Arch Wiki says that, but I have currently right now a machine in the state of the art of all the packages and that does work with the encrypt hook. So I'm not totally sure about that. I had been always using the encrypt hook in many other occasions, and always it had worked.

frostschutz wrote:

Alternatively switch to busybox based initcpio instead of using the systemd one.

It can be a potential solution, but for now I really want it to work with systemd and with the core utils, because basically are the defaults of Arch Linux. So it's more like the weight of tradition argument. But using busybox is totally fine to be honest, maybe I'm going to make the change in the not so distant future.

But the thing that doesn't makes sense is why having right now a systemd + core utils and making "the same" config setup it just works fine.

Scimmia · 2026-03-22 01:10:47

Succulent of your garden wrote:

a machine in the state of the art of all the packages and that does work with the encrypt hook.

Right, running a busybox initramfs. systemd only became the default recently and if you didn't update your config to use it, you wouldn't have it. It has nothing to do with what packages you have, it's how you're configured.

Succulent of your garden · 2026-03-22 12:36:20

Scimmia wrote:

Right, running a busybox initramfs. systemd only became the default recently and if you didn't update your config to use it, you wouldn't have it. It has nothing to do with what packages you have, it's how you're configured.

So I notice now that you mention that in the hooks in mkinitcpio.conf:

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

it does uses the systemd, which on other previous systems I don't have. Why now Arch adds the systemd hook into mkinitcpio.conf by default ? I'm going to supermarket right now and when I came back gonna check if now I can fix the issue by replacing encrypt with sd-encrypt hook.

But previous Arch isos doesn't added the systemd flag as I notice, and the busy box thing just worked out of the box fine. Why has been this added ?

Scimmia · 2026-03-22 14:55:16

It works out of the box this way, too, what doesn't work anymore is your custom configuration that you didn't adapt for the new defaults.

Succulent of your garden · 2026-03-22 23:53:55

Thanks everyone in helping there. I made it ^^

It was the HOOKS declaration in the mkinitcpio.conf. As how Scimmia said you need to go with the systemd approach or the busybox one, you can mix the hooks arguments of both.

Since new images of Arch Linux adds systemd and sd-vconsolse into the hooks, that creates the issue.

I wonder why the default systemd hooks decision was made into the mkinitcpio.conf in Arch. LIke if you do it with busybox the system just boots fine. So with all my heart in not creating another "why systemd is more than an init system discussion" : Why starting to use the systemd hook in the mkinitcpio.conf by default now days ? I mean the busybox I guess is less bloated, so I assume it's better than using the systemd, at least for my case. So I'm mostly sure i'm not seeing the whole picture

Arch Linux

#1 2026-03-17 12:15:30

[Partially solved] Problem booting a devices after encryption

#2 2026-03-19 17:06:09

Re: [Partially solved] Problem booting a devices after encryption

#3 2026-03-19 22:54:44

Re: [Partially solved] Problem booting a devices after encryption

#4 2026-03-20 08:53:32

Re: [Partially solved] Problem booting a devices after encryption

#5 2026-03-21 22:36:51

Re: [Partially solved] Problem booting a devices after encryption

#6 2026-03-21 23:02:26

Re: [Partially solved] Problem booting a devices after encryption

#7 2026-03-21 23:50:09

Re: [Partially solved] Problem booting a devices after encryption

#8 2026-03-22 01:10:47

Re: [Partially solved] Problem booting a devices after encryption

#9 2026-03-22 12:36:20

Re: [Partially solved] Problem booting a devices after encryption

#10 2026-03-22 14:55:16

Re: [Partially solved] Problem booting a devices after encryption

#11 2026-03-22 23:53:55

Re: [Partially solved] Problem booting a devices after encryption

Board footer