On Thu, Jul 04, 2019 at 12:00:10PM -0400, Theodore Ts'o wrote: > On Wed, Jul 03, 2019 at 07:59:11PM +0200, Marc Haber wrote: > > I don't think that having an e2 file system on a LUKS device on an LVM > > logical volume is such an exotic thing to have. > > It's not exotic, but it's not something we had tested. So thanks for > your bug report! On my system I have the LVM PV on top of the LUKS > device (so that all of the LV's are encrypted), and on your system you > have it the other way around.
Yes, Debian does it like LV-on-PV-on-LUKS, I do it the other way because I have some LVs with very private contents that only get unlocked when I'm actually using it, and therefore the LUKS-on-LV scheme is more practical here. > So the problem is that when we scan for LVM devices: > > lvs -o lv_path --noheadings -S > "lv_active=active,lv_role=public,lv_role!=snapshot,vg_free>256" > > we get /dev/fan-c/root, Yes > but then when we then run lsblk on that > device, we get something like this: > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sdb 8:16 0 931,5G 0 disk > fan-c_root 253:0 0 417,2G 0 lvm > └─root 253:28 0 417,2G 0 crypt / Yes. > And so when we run lsblk -o NAME,MOUNTPOINT,FSTYPE -P -n -p > /dev/fan-c/root we get both the top-level and subdevice: > > NAME="/dev/mapper/fan-c_root" MOUNTPOINT="" FSTYPE="crypto_LUKS" > NAME="/dev/mapper/root" MOUNTPOINT="/" FSTYPE="ext4" Yes. > Thanks again for the bug report! Thanks for the reaction, for the analysis, and for the fix. > P.S. Sorry for the complexity; we were trying to use systemd to > handle the error reporting. I do wonder if we would have been better > off if we done things the more old-fashioned way, instead of trying to > take advantage of all of systemd's "value add". My personal opinion > is whether or not we like systemd, it's won the war, so we might as > well try to take advantages of it, since we're stuck with the > disadvantages. I agree with you there. A few word of explanation in some readme or in the mail sent out by /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_fail) would have been nice though. > e2scrub_all: correctly handle the case where LUKS is stacked on an LV > > We handle the case where an LVM's PV is stacked on top of a dm-crypt > device, but not the case where it's the other way around, where a LVM > LV contains a LUKS encrypted file system. Fix this oversight. > > Addresses-Debian-Bug: #931387 > > Reported-by: Marc Haber <m...@zugschlus.de> Please don't use the unplussed mail address that I have never communicated. mh+debian-b...@zugschlus.de would be enough, it's a valid and working address, and one that spammers don't handle too well. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
