I agree with you about the problem with an encrypted root partition. To
understand how safe it is to ignore the error I investigated the
behaviour of cryptsetup and lvm during shutdown and reboot.
- Cryptsetup. The only effect of luksClose, correct me if I am wrong,
is to remove the device mappings. I deduced it from reading the
output of "strace cryptsetup luksClose ...", of which here is an
excerpt:
[...]
3702 open("/dev/mapper/control", O_RDWR|O_LARGEFILE) = 3
[...]
3702 ioctl(3, DM_VERSION, 0x8b101d0) = 0
3702 ioctl(3, DM_TABLE_STATUS, 0x8b101d0) = 0
3702 ioctl(3, DM_DEV_REMOVE, 0x8b101d0) = 0
3702 close(3) = 0
3702 stat64("/dev/mapper/wd3-crypt", {st_mode=S_IFBLK|0660,\
st_rdev=makedev(254, 6), ...}) = 0
3702 unlink("/dev/mapper/wd3-crypt") = 0
3702 exit_group(0) = ?
- LVM. The command "/sbin/vgchange -aly --ignorelockingfailure" fails
when the devices created by cryptsetup are still present. After some
more use of strace this is what I think "vgchange" exactly does:
- remove the VG from the list of available VGs;
- remove the devices in /dev/mapper, etc.;
- update /etc/lvm/cache/.cache.
Since the system is doing shutdown/reboot then it is not a problem if
the devices are not unlinked and not made unavailable; the file
/etc/lvm/cache/.cache is not updated but it should be generated again
during the next boot phase anyway.
It seems, in the end, things don't need to change. Maybe the error
string displayed by the lvm2 init script ("...Failed!", etc.) is a bit
misleading, in that it makes one think about some serious issue while
instead its content is only informational.
Maybe the people maintaining the lvm2 package could be informed about it
and then decide if they agree about the lack of risks in not doing a
vgchange upon shutdown and also about the displayed error message.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
