From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1eWk4AJ01t9 for ; Tue, 2 Aug 2011 11:00:58 +0200 (CEST) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 2 Aug 2011 11:00:58 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-166-21.dclient.hispeed.ch [84.74.166.21]) by v4.tansi.org (Postfix) with ESMTPA id C7172205FCF for ; Tue, 2 Aug 2011 11:00:57 +0200 (CEST) Date: Tue, 2 Aug 2011 11:00:56 +0200 From: Arno Wagner Message-ID: <20110802090056.GA27025@tansi.org> References: <20110801235305.GA4857@tansi.org> <1312270544.22484.24.camel@scapa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <1312270544.22484.24.camel@scapa> Subject: Re: [dm-crypt] cryptsetup FAQ montly posting 8/2011 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2011 at 09:35:44AM +0200, Yves-Alexis Perez wrote: > On mar., 2011-08-02 at 01:53 +0200, Arno Wagner wrote: > >=20 > > * Can I resize a dm-crypt or LUKS partition? > >=20 > > Yes, you can, as neither dm-crypt nor LUKS stores partition size. > > Whether you should is a different question. Personally I recommend > > backup, recreation of the encrypted partition with new size, > > recreation of the filesystem and restore. This gets around the > > tricky business of resizing the filesystem. Resizing a dm-crypt or > > LUKS container does not resize the filesystem in it. The backup is > > really non-optional here, as a lot can go wrong, resulting in > > partial or complete data loss. Using something like gparted to > > resize an encrypted partition is slow, but typicaly works. This > > will not change the size of the filesystem hidden under the > > encryption though. > >=20 > > You also need to be aware of size-based limitations. The one > > currently relevant is that aes-xts-plain should not be used for > > encrypted container sizes larger than 2TiB. Use aes-xts-plain64 > > for that.=20 >=20 > It might be worth mentioning LVM setups for this? >=20 > What I do is (exactly like the Debian installer ???setup encrypted LVM??? > does): >=20 > - /dev/sda1 =3D /boot > - /dev/sda2 -> dm-crypt -> /dev/mapper/sda2_crypt > - /dev/mapper/sda2_crypt =3D physical volume for LVM >=20 > then create a volume group in /dev/mapper/sda2_crypt and logical volumes > in there. My advice would be to not use the full volume group space (I > usually do 10G for /, 10G for /home and 1-2G for swap), then you can > lvextend and resize2fs the stuff. Encryption doesn't get in the way. >=20 > Regards, > --=20 > Yves-Alexis Well, conceptually it is a cliose topic. But I do not want to make the "cryptsetup FAQ" redundant with the LVM documentation. It is large enough as it is. If you have a URL that sums up LVM (and the usage above) nicely, I could add that to the FAQ, possibly in the section on RAID vs. encryption. I am also thinking about doing some restructuring, mainly to split "Backup" into "Backup" and "Disaster recovery", but I could maybe add a section on "Encryption, LVM, RAID" as well. Arno --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.nam= e=20 GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier=20 --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFON7zIGC7wC1BV+QYRAvMjAJ4mR726sTLzL+RLtanCfgJFsht6YgCfbkt5 JRfY6n4w8AXEdzh9zpQC6MA= =rkCk -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--