Score:4

Change encrypted 18.04 install to dual-boot along side 22.04?

cn flag

I'm trying to install Jammy in a dual-boot, side-by-side on laptops with an existing LUKS-encrypted Bionic install.

(We need access to both on the same PC for development purposes, and VMs aren't really an option.) 18.04 was installed with encryption, using the LVM/LUKS configuration offered as an option in the installer.

I think I'm most of the way there, but I'm having trouble getting the bootloader to decrypt the partition.

Here's the steps I'm trying so far:

(Tiny disk sizes since I'm just testing in a VM to come up with a repeatable process):

Boot 22.04 installer in live mode unlock the disk by clicking the encrypted volume that shows in Nautilus.

sudo lvs

Shows:

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root vgubuntu -wi-a---- <30g
swap_1 vgubuntu -wi-a---- 976.00m

Shrink the existing logical volume that 18.04 root FS is on:

sudo lvreduce --resizefs --size 10G /dev/ubuntu-vg/root

Create a new logical volume (LV) for the installer to use for 22.04:

sudo lvcreate -n jammy-root -L 15G ubuntu-vg

At this point, I can see the the new and existing LVs when I look.

Next, I launch the 22.04 installer from the desktop.

  1. Select manual partitioning.
  2. Select the new LVM volume, "/dev/mapper/ubuntu--vg-jammy-root" Choose format, use as EXT4, mount point: /
  3. Select the existing swap, reuse as swap for both OSes
  4. Select the existing /boot partition to use as /boot for both OSes (hopefully this doesn't cause too many issues and is workable, it seemed WAY easier than moving all the partitions around and resizing to allow for 2 /boot partitions. Which I'm trying to avoid since I need to do this procedure multiple times.)

The install completes with these settings. At this point if I reboot, I get a grub menu for both OS installs, neither install seem to be aware of the LVs being on an encrypted volume. I get the following message:

Volume group "ubuntu-vg" not found
Cannot process volume group ubuntu-vg

And I'm put into a BusyBox shell.

I also tried running the same procedure as above, instead of rebooting when the installer finishes running the following commands:

echo 'ubuntu-vg UUID=(uuid without quotes) none luks,discard' > /target/etc/crypttab
mount -t proc proc /target/proc

mount --rbind /sys /target/sys

mount --rbind /dev /target/dev

chroot /target

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader=ubuntu --boot-directory=/boot/efi/EFI/ubuntu --recheck /dev/sda

grub-mkconfig --output=/boot/efi/EFI/ubuntu/grub/grub.cfg

update-initramfs -ck all

exit

reboot

This gives the same result.

Anyone have any tips about how I can get this to work and be an easily repeatable procedure?

Thanks!

Adding additional info as requested by commenter:

Layout of drives is as follows:

/dev/vda1 - A single fat32 EFI partition - 512MB
/dev/vda2 (an ext4 /boot partition) - 732MB
/dev/vda3 LUKS encrypted PV containing: 2 LVs for the root of each OS and 1 LV for shared swap.

Tree summary:

Drive: /dev/vda
├─ Partition: /dev/vda1/ [single fat32 EFI partition]
├─ Partition: /dev/vda2/ [ext4, boot partition, created by 18.04 installer, will use for both, mountpoint: boot]
├─ Partition: /dev/vda3/ [LUKS encrpyted PV]
│  ├─ VG: ubuntu-vg [Default LVM VG created by 18.04 installer]
│    ├─ LV: root [Default LVM LV created by 18.04 installer]
│       ├─ Partition: ext4, description/use: Default 18.04 root partition created by 18.04 installer, mountpoint: /
│    ├─ LV: swap_1 [Default LVM LV created by 18.04 installer]
│       ├─ Partition: swap, description/use: 18.04 and 22.04 swap partition created by 18.04 installer, will use for both, use as swap
│    ├─ LV: jammy-root [LVM LV manually created before 22.04 install]
│       ├─ Partition: ext4, description/use: 22.04 root partition manually created and used during 22.04 install as described in original post., mountpoint: /
  1. Boot method is UEFI
  2. It's the default LUKS scheme the installer uses, i.e., encrypted PV containing an ext4 LV for /, and an LV for the swap.
  3. LUKS version info:

LUKS header information for /dev/vda3

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
mx flag
please add more details: 1. tree structure of all your disk partitions, we want to know how many efi partitions you have, which one was in use. if bios where do you installed grub. 2. UEFI or BIOS? 3. your luks scheme: lvm over full disk luks? luks on lvm? luks on some partition of lvm? etc. 4. version of your luks.
chris avatar
cn flag
Hi Wang, I just added the additional info you requested. Thanks for the help.
mx flag
how do u plan to unlock your luks during boot? by grub or by script embed in initrd?
Score:0
sy flag

Wouldn't using a pair of USB drives with grub for each of the versions of his Ubuntu installations work for him, i.e. plug in a USB drive and boot the version he wants to use because the individual drive mounts the appropriate /dev/vda*/. I know that's probably not a practical way to do things, but it should work in the mean time to backup files

Score:0
mx flag

first I don't think your grub bootloader open the luks. your setup actually have clear data /boot. What you saw is after kernel boot up already.

The major problem that you try to share /boot. The /boot contains kernels and grub info for one specific OS. initramfs-tools will remove/change the files in there. The OS does not know if that vmlinz or initrd belongs to itself. The update-grub will change the bootloader and scripts in /boot/grub for itself thus it won't be able to correctly handle the os in your other ubuntu installation. Please do not do this.

The reason that your old 18.04 won't boot because now the /boot/grub contains new grub config that does not match it. the /boot also does not contain correct initrd and vmlinz for it. Thus forget about 18.04. It won't work at all at this point. Unless you go through trouble to chroot into your 18.04 and fix your /boot.

Your step to update crypttab is roughly ok. I see you will expect to see luks passphrase input interface. But this can be timed out. So please make sure you boot with verbose. Then you see more about what happened.

make sure your UUID in crypttab is correct. It is the vda3 not ubuntu-vg uuid.

You might end up boot up into wrong kernel or the kernel actually using wrong initrd since you try to mix up 2 OSs. I highly suggest you create a new /boot or format your old one. Then reinstall again. Before restart chroot into your installation as the normal encryption setup suggested. Then update your crypttab and initrd.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.