I am currently experiencing problems with a setup of luks on lvm on raid. The problems may or may not have anything to do with the disks; the system ran several days of memtest without any reported errors. The problem is that the system becomes totally unresponsive: screen blank, no reaction to input devices, no response to ssh. However, the power is on. Perhaps it rebooted and then hung up at the luks prompt. BTW, does anyone know if the luks prompt can time out and produce a system in the state I just described? This appeared to happen in the early AM (c. 3:30am is last log entry), and there don't seem to be any clues in the logs. However, sometimes it does stay up overnight. Maintenance scripts run via anacron, so it's hard to tell what, if anything is running at that time. Setup: 2 identical disks with 3 partitions on each. The first, small one is software RAID 1 and holds /boot. Each of the 2nd partitions are encrypted swap (non-raid). 3rd (big) partition is software RAID 1 with LVM built on top of that. Some of the LVM volumes are LUKS encrypted. Debian Lenny on 64 bit Xeon, 8 cores. Because of a mistake during setup one of the swap partitions was originally LUKS. I changed it to random later. I did cryptsetup luksClose and modified /etc/crypttab, but perhaps some LUKS vestige is confusing things? I would, of course, welcome any suggestions. Also, Clayton Shepherd wrote that a script to enter the same password repeatedly shouldn't be too hard to write. I thought so too, but my efforts to do so under Debian have so far been unsuccessful. See http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2009-March/002533.html for details. Ross Boylan On Tue, 2009-03-10 at 08:26 +0100, Wolfgang Sailer wrote: > Hi! > > I have it the other way round so far: > I built a RAID, onto this I put LVM with a few partitions. Currently I use > luks only on one of those partitions, I run an encrypted swap. So far, I > have not experienced problems. > I will run another few tests like growing the RAID, expanding the logical > volume, move data from one physical volume to another (and remove the old > one) and will check how well my cswap reacts to it. If everything survives, > then I will be confident enough to move my /home, which currently resides on > a separate raid without lvm, to a freshly created logical volume. > > So far, raid expansion and filesystem expansion has worked absolutely > flawlessly for me! I did it a few times, once with the filesystem umount-ed, > once mounted, all went well. > > regards, > sulla > > Clayton Shepard wrote: > > I would like to note that you have a couple options on where you put the > > LUKS. On my setup I did it after the raid but before the LVM if I recall > > correctly. Unfortunately this only allows one dmcrypt process to run, which > > ends up being a huge bottleneck for any relatively new raid array (my > > throughput dropped from 500MB/s to 80MB/s). If you put LUKS on each drive > > individually before setting up mdadm, then you have N dmcrypt processes > > which could potentially give you much better performance if you have an SMP > > system. Unfortunately this also means you would have to enter your password > > N times, but a script to do it automatically shouldn't be too hard to write, > > although there may be some security considerations there... > > > > Regards, > > > > -Clay > > > > On Thu, Feb 5, 2009 at 2:01 AM, Ryan Castellucci <ryan.castellucci@xxxxxxxxx > >> wrote: > > > >> On Mon, Nov 10, 2008 at 3:45 PM, Wolfgang Sailer > >> <Wolfgang@xxxxxxxxxxxxxx> wrote: > >>> Dear all! > >>> > >>> I have a question regarding luks on lvm: > >>> > >>> Currently I am running LUKS on a 6-disk raid 5, where every disk has 1 > >>> primary partition that takes part in the raid. So far no problems. But > >> I'm > >>> running out of space. > >>> > >>> So I would like to buy 2 new drives, set them up as a raid 1 (for > >>> convenience i would add the whole drives to the raid without creating > >>> partitions on them), add the raid as (the only) volume to a lvm volume > >> group > >>> and put several partitions on the lvm: unencrypted ones for root, home > >> ... > >>> and one encrypted to hold critical data. Then I intend to copy over the > >> data > >>> from the 6 disk encrypted raid5 to the new drives' encrypted logical > >>> partition and dismantle the 6 drives. > >>> > >>> I think such a setup is perfectly valid, but is there any concern putting > >>> luks on a virtual partition in a volume group consisting of a raid1? Do I > >>> need to take something special into account, like setting up lvm in a > >>> special way (certain block size...) to make it work smoothly with luks? > >> Do I > >>> need to tell luks some additional information such that it is installed > >> on > >>> lvm? Is such a setup as stable as putting luks on real partitions? > >>> > >>> Should I fill the whole disk with /dev/urandom or just the partition that > >>> will hold the luks volume? > >>> > >>> What if I add another disk (or raid volume) to the volume group in order > >> to > >>> expand the space in future? Will that disturb luks? I have done a smooth > >>> raid5 expansion from 4 to 5 to 6 disks in the past followed by a luks > >>> expansion and an ext3 expansion, but never an lvm expansion... > >> I've been running LUKS on LVM2 on RAID6 for almost two years. It's > >> been unfazed by disk failure, lvresizes, hard power offs, etc. The > >> defaults work fine for me, though they may be sub-optimal.. I've used > >> both XFS and ext3 without problems. > >> > >> -- > >> Ryan Castellucci http://ryanc.org/ > >> > >> --------------------------------------------------------------------- > >> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > >> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > >> For additional commands, e-mail: dm-crypt-help@xxxxxxxx > >> > >> > > > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
