#961671 Improve documentation for crypttab mapping renaming

#961671#5
Date:
2020-05-27 16:17:36 UTC
From:
To:
Every time I see bug #671037 referenced in the docs (README.initramfs.gz)
or do a rename I feel bad. When I first encountered this long before the
bug was submitted I found a easier/safer way. Sorry for not responding till
now.

if you have

old_name   /dev/... none luks

and you want new_name instead, modify your crypttab

new_name /dev/... none luks

rename the mapping

dmsetup rename old_name new_name

update the initramfs

update-initramfs -uk all

done.

As far as the currently booted system goes, it already sees the new names,
so a reboot is actually optional. I would recommend a reboot though as
you'd likely rather find out now that you have a problem than the next time
the power goes out.

Sorry I didn't send this nearly a decade sooner. Thanks for the fantastic
initram(rd/fs) support provided in Debian.

#961671#10
Date:
2020-06-01 20:56:41 UTC
From:
To:
Hi Ed,

README.initramfs §11 certainly has shortcomings and doesn't pretend to
cover all cases, but note that your solution doesn't cover all cases
either:

The device might be identified by /dev/mapper/old_name rather than UUID
in /etc/fstab, /etc/initramfs-tools/conf.d/resume, kernel command line,
or other places, in which case the rename needs to be performed there
too.

/proc/mounts appears not to though, and that's we use to identify the
source device in our hook scripts.  So `update-initramfs -u` will
complain that it can't find the root device if /dev/mapper/old_name is
used directly as the root file system.  The current instructions are
more robust in that regard.

Cheers,