Reinstall without losing @home on encrypted partition

[clownshow]

Hey fellow garuda fans,

I wanted to reset my Garuda installation or better reinstall everything.
Since Garuda comes with multiple BTRFS volumes, I thought it would be no problem to keep @home and just let the new system be installed into @.

Since calamaris does not support BTRFS setups in manual partitioning yet, I have followed: Multiple installations on one partition | Garuda Linux wiki

During that I would move @ and @home to their respecituve _old locations. The root, just tk have a backup to roll back to for now.

I then followed the instructions for calamaris on there, chose my unlocked (via gParted) partitions for EFI and / and tried to install Garuda.

The installer failed. I have not looked at the exact error message, since I do not think it is relevant (see below).
The encrypted partitions were locked again afterwards.

The setuo could not work, since the partition itself is not actually my /, the unencrypted /dev/mapper/luks-xxxxxx ‘partition’ is. Since I can not chose that in the GUI, I can not properly overwrite the current system.

Since the guide above does not mention encryption, I guess it is not considering it.

How would you go about this?

[SGS]

@clownshow

How would you go about this?

Please search before you open a help request.

BTRFS reinstalling without losing @home

Garuda has some known performance issues when installed in a VM, so bear that in mind while you do your testing and don’t judge to harshly. When you are ready to install on the metal, that will give you the best performance. You can complete the installation while leaving the existing subvolumes intact, but you will have to rename them first so they don’t use names that the default installation will try to use (@, @cache, @home, @log, @root, @srv, and @tmp). An easy way to do this is make a …

[clownshow]

@SGS

Please search before you open a help request.

I did and that post is not helpful in my case, since it seems to be the basis on which the wiki article was made from.

It does not take into consideration that the partitions are encrypted, so it does not apply here.

Or am I missing something?

[BluishHumility]

The complicating factor in this case is Calamares doesn’t support reusing encrypted partitions (only creating new ones and using those). Additionally, as you have discovered, part of the routine Calamares goes through before doing the installation is to unmount all block devices. See this related issue:

Calamares closes LUKS and/or LVM device before trying to install to it

As you can see from the comments in that issue, there is a workaround. It was not mentioned in the article you linked because the workaround is a little hacky, and who knows how long it will actually continue to work.

Essentially the trick is to prefix the mapping name with “live-” when you unlock the LUKS device; Calamares recognizes this prefix as part of its process and will leave the device mounted.

sudo cryptsetup open /dev/[foo] live-[bar]

“[foo]” is the Btrfs partition and “[bar]” is whatever you want to call the mapping ( for example, “live-root”, “live-btrfs”, “live-luks”, whatever–it doesn’t matter as long as you have the “live-” part).

After you have unlocked the LUKS device, start the installer and follow the process described in the wiki article you linked.

[clownshow]

Thx @BluishHumility

As my understanding goes, Calamaris would then use the encrypted partition as root and not the unencrypted device /dev/mapper/live-..., wouldn’t it?

On the summary page it says, that it would use /dev/nvme… and not /dev/mapper/live-… to install garuda on

[BluishHumility]

@clownshow

As my understanding goes, Calamaris would then use the encrypted partition as root and not the unencrypted device /dev/mapper/live-..., wouldn’t it?

I don’t understand what you are asking.

---

I forgot to mention, when I was first figuring out how to get this working another obstacle I ran into was Calamares would error out when it noticed the installation was encrypted, but it did not have a keyfile for the encrypted device. My way of working around that was so remove the luksbootkeyfile option from /etc/calamares/settings.conf. install.sh · main · BluishHumility / garuda-setup · GitLab

Before you start the installer, open /etc/calamares/settings.conf in an editor and delete that line. Or use something like sed:

sed -i '/luksbootkeyfile/d' /etc/calamares/settings.conf

Then, after the installation is finished you can chroot into the installed system and set up the keyfile manually. chroot-install.sh · main · BluishHumility / garuda-setup · GitLab

I ended up scripting it for my purpose as you can see. To do it manually would be like this:

From the chroot, remove the dracut config Calamares sets up since it isn’t going to work.

rm /etc/dracut.conf.d/calamares-luks.conf

Generate a keyfile.

dd bs=512 count=4 if=/dev/random of=/crypto_keyfile.bin iflag=fullblock
chmod 000 /crypto_keyfile.bin
cryptsetup -v luksAddKey "/dev/[btrfs partition]" /crypto_keyfile.bin

Obviously replace “[btrfs partition]” with whatever the disk partition identifier is.

Add the keyfile to a dracut config.

echo 'install_items+=" /crypto_keyfile.bin "' > /etc/dracut.conf.d/keyfile.conf

Regenerate the initramfs

dracut-rebuild

Edit /etc/default/grub and add the cryptdevice kernel parameter to the GRUB_CMDLINE_LINUX line. It should be like this:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=[cryptdevice UUID]:[device mapping]"

You can get the cryptdevice UUID like this:

blkid -s UUID -o value "/dev/[btrfs partition]

And then “[device mapping]” is whatever you decided to call the mapping (“live-root”, “live-luks”, or whatever). Note there is a colon in between the cryptdevice UUID and the device mapping.

Reinstall Grub and regenerate the Grub configuration file.

grub-install --no-nvram
update-grub

Finally, exit the chroot and reboot.

As you can see, this whole process is pretty complicated and kind of hacky because you have to sort of work around the installer to do it. That’s why I decided encrypted installations are beyond the scope of the wiki document you linked; I figure for most folks, it’s more trouble than it is worth.