On Tue, Sep 09, 2014 at 23:52:03 CEST, Ross Boylan wrote: > My system uses LVM, with LUKS encryption on top of individual logical > volumes. The volume group has some free space, and I would like to > extend the volume and then grow the encrypted container and then the > file system on it. You cannot "grow the encrypted container". A LUKS mapping has no fixed size associated with it. It merely takes the size of the underlying raw container as its size. So if you resize the raw container, the LUKS container changes size automatically on re-mapping. > When expanding I'll use free space that I don't believe has ever been > zeroed or random filled. It's possible it was used for a file system > at some point. > > Is that much of a concern? The FAQ advises wipeing it, though the > only explicit reasons seem not much of a concern for space in a volume > group (but later there are references to attacks available if the > attacker can determine which sectors are unused). As far as I know > there is no way to access the unused area of the volume group (well, > except for mapping all physical device sectors in use and operating on > the remainder after somehow figuring out where metadata is kept), and > attempting to do so seems hazardous. It seems particularly hazardous > because there are active snapshots, and it seems possible they grab > freespace dynamically. Youa re overlooking one thing: If you resize the raw container and re-map LUKS, you will still have the old filesystem size in the LUKS container. Filesystems do nto grow by themselves. You could just zero the space behinf the filesystem. If you get it wrong, you may kill the filesystem though. But resizing a partition or filesystem is not something you should do without a full, verified backup anyways. > Is > cryptsetup resize /dev/VG/LV > the right way to expand the container once the LV is extended? No. cryptsetup resize resizes the mapping temporarily to something else than the underlying raw container size. > Are there any things I should look out for in the whole process? Do I > need to reboot or remount anywhere along the way for changes to take > effect? The filesystems are ext3 and reiser. Aehm, you need to umount and unmap everything before doing this? You need a full, verified backup of _all_ data? Seriously, I do not think you understand what you want to do enough to do it safely. Better make that full backup and recreate the raw container in question with the new size, make a new LUKS container out of it and put a new filesystem in it after zero-wiping it. > The software on the system is quite old, Debian Lenny + some > backports. cryptsetup is at 1.0.6 (Debian version 2:1.0.6-7) and the > kernel is 2.6.32 (which is a backport). That should not matter. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
