I have a Linux system with the following disk setup (MBR-formatted, BIOS-booted):

sda                                             32G disk              
└─sda1                                          32G part  crypto_LUKS 001b349b-2a70-4408-bae2-107d035c96e9
  └─luks-001b349b-2a70-4408-bae2-107d035c96e9   32G crypt btrfs       8c72adab-63cf-4526-b77e-78f11d2585e2

It works great, but I want to change the UUIDs of both the LUKS volume and the filesystem. This is because I am creating a bootable rescue USB off my main machine, and so I need to avoid UUID collisions when booted from the USB.

So I try:

sudo sed -i 's/001b349b/101b349b/g' /etc/default/grub
sudo sed -i 's/001b349b/101b349b/g' /etc/fstab
sudo sed -i 's/001b349b/101b349b/g' /boot/grub/grub.cfg
sudo sed -i 's/8c72adab/7c72adab/g' /etc/default/grub
sudo sed -i 's/8c72adab/7c72adab/g' /etc/fstab
sudo sed -i 's/8c72adab/7c72adab/g' /boot/grub/grub.cfg
sudo update-grub
sudo grub-install /dev/sda --modules=btrfs

Once done, I attach the disk to another machine and adjust both UUIDs:

sudo cryptsetup luksUUID /dev/sda1 --uuid "101b349b-2a70-4408-bae2-107d035c96e9"
sudo btrfstune -U 7c72adab-63cf-4526-b77e-78f11d2585e2 /dev/mapper/sda1-crypt

When I try to boot from the resulting disk I see:

error: no such cryptodisk found.
error: disk 'cryptouuid/001b349b2a704408bae2107d035c96e9' not found.
Entering rescue mode...
grub rescue> _

That said, somewhere the old LUKS UUID is still sitting. I expected it to be overwritten with the new one when I ran grub-install, but it didn't happen.

Why is grub still trying the old UUID? What am I missing to make it try the new one?


It appears that when grub-install is run, it possibly takes the old UUID from the currently mounted LUKS device (as opposed to from any config file) because I can't see where else the old UUID could come from. Is this what happens? Is there any way to override this behavior?

  • 1
    Can you check /etc/crypttab? Aug 12, 2023 at 14:44
  • Also, did you regenerate your initramfs? Aug 12, 2023 at 14:45
  • @Ginnungagap Included /etc/crypttab in the sed replace list, ran update-initramfs -u before update-grub but it didn't make any difference. The old UUID gets embedded in the code that unlocks the LUKS on boot (which sits in the MBR gap before the 1st partition). I am yet to find out why the new UUID doesn't make its way in there instead.
    – Greendrake
    Aug 13, 2023 at 2:28


You must log in to answer this question.

Browse other questions tagged .