Re: Fwd: LVM/BTRFS on LUKS unreadable

[Klemens Nanni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I tried this again out of curiosity, but instead of just reformatting
the test disk I wiped the header first using
        $ head -c 3145728 /dev/urandom > /dev/sdb

before setting up the disk as already described (BTRFS on LUKS). This
time, still using the same GRUB installation, I was able to decrypt,
mount and read files from the disk having it connected via USB.

This seems very odd to me but also indicates that the issue does not
neccessarily have to be with GRUB but (re)formatting the disk.

Since I now had multiple working as well as non working set ups on the
same machine using the same GRUB installation, it would be helpful get
some feedback from other people/user/set ups.

Klemens Nanni:
> -------- Forwarded Message -------- Subject: LVM/BTRFS on LUKS
> unreadable Date: Mon, 17 Aug 2015 23:24:32 +0000 From: Autoboot
> <address@hidden> To: address@hidden
> 
> Hello,
> 
> GRUB 2.02~beta2 as of commit
> afd0f21b2027310fda52b00ac1b964041d39a363 used as autoboot payload
> on a ThinkPad X201 here.
> 
> After setting up LVM on LUKS and writing random test files on the
> disk, GRUB2 opens the disk but cannot read it's content at
> (crypto0).
> 
> Disk setup: $ cryptsetup luksFormat /dev/sdb $ cryptsetup open
> /dev/sdb test $ pvcreate /dev/mapper/test $ vgcreate test
> /dev/mapper/test $ lvcreate test -L 50G -n root $ mkfs.ext4 -L
> test_root /dev/mapper/test-root $ mount /dev/mapper/test-root /mnt 
> $ dd if=/dev/urandom bs=1M count=20M of=/mnt/20M
> 
> GRUB Shell: (all modules incl. lvm properly loaded) $ cryptomount
> (ahci0) [...] Slot 0 opened
> 
> $ cat (proc)/luks_script luks_mount <hexcode> 4096 aes-xts-plain
> <other hexcode>
> 
> $ ls (proc) (memdisk) (cbfsdisk) (crypto0) (ahci0)
> 
> $ ls -l [...] Device ahci0: No known Filesystem detected [...] 
> Device crypto0: Filesystem cannot be accessed
> 
> $ debug=cryptodisk
> 
> $ ls (crypto0) disk/cryptodisk.c:531: Opening device crypto0 error:
> disk `crypto0' not found.
> 
> 
> The same happens when replacing LVM with BTRFS, both disk setups
> can be mounted but are read fine from userspace, though. I set up
> the disk on two different machines to make sure, but with no
> avail.
> 
> Note that this setup does not have any MBR/GPT at all, LUKS and 
> LVM/BTRFS both use raw device paths since they are capable of
> completely replacing partition tables.
> 
> I tried manually opening one of my actual installation disks (/boot
> on sda1, LVM on LUKS on sda2) the same way, but with no avail. Note
> that this disk gets booted every day using the very same X201, so
> it's definetely a GRUB2 problem.
> 
> Setting up the test disk exactly like shown above but without
> encryption (LVM on raw device /dev/sdb) works, I can successfully
> read it's content in GRUB
> 
> $ ls [...] (lvm/test-root)
> 
> $ ls (test/lvm-root)/ lost+found 20M
> 
> which seems to make it an issue with cryptomount only. To further 
> verify it's not the test disk being incorrectly read by GRUB, I 
> "wiped" it by running $ cryptsetup luksFormat -c serpent /dev/sdb <
> open LUKS, create LVM/BTRFS, mount, write data > < test in GRUB
> shell >
> 
> since writing zeros or random data using $ dd
> if=/dev/(zero|urandom) bs=1M /dev/sdb
> 
> to the device results in the same state as encrypting it with
> another cipher rendering all old data look random as well (correct
> me if I'm wrong). Still the same behaviour.
> 
> Has anyone else experiences this before? I don't know what to do,
> any help is highly appreciated.
> 
> 
> Regards, Klemens Nanni (kl3 on IRC)
> 
> 

- -- 
Encrypt your messages using GNUPG if you can - nobody likes snoopers!
For more detailed information, look at the FSF's Email Self-Defense
Guideguide under https://emailselfdefense.fsf.org
Autoboot Key ID: 0xB375A7EE | fingerprint: 6D43 AB28 A92C 9278 E8F8
40A9 0A3A 37D8 B375 A7EE
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJV+GyZAAoJEAo6N9izdafuuYYP/jmggIi8sVFsf0d+VUVDa1W0
tgkmCBVf5kQf+2LerYiEaAO+RVS6/4VLvumV7k196DZZUAdelmUzOx4XNvyfMVkX
ptU2PWDLh62c4Bqiv+op2oHJIZOUEzisu7ok5CmqkuntKYFhiGVxSjDjhajb4HCB
6mGadK1wqMXXhUs3Q8DGyxna46wW125aSXXgK4xCqxT3kvJr7G5euQd0LjvI5poa
+Lx8xJZlT04j0UIENTNimb/l459VtArPAt5uT0QumjwntkOcFAMk7BurqhlAtgMV
lxN1Vo/9hTQMxOrA1R00a5oLxdc6DF7JiyP5qnXJdu+7MOP3y1tFhDAj1veWd5D/
CLYYkKh+qT/5DXg8k+jBnjd3SV2D6ZvC47uvr7nWuf1BwEAefGXyrWwPcSFBrtSN
OY1aRZVbwgjg3jmGpx49srH+xbZ4FKjH8OqdBZKHZBKg8ZRGEXYXNDMbVNzhEe1V
j3xP+4LWieqCa67O+w54yxPErZkP1EzNhC2rNyyU5QRGZ6Rr9+kfMMTNWzTF44FY
7jQIViBKv9XM722kKvbiJglYf4lWDgzkImqeqBZb8I7qRkjaRZAAN6DIiply7cov
IXHipQA4DiF09k8nk8zTC716llOtnEzF3Pe24GBXc0Aj98Zc3jJaYzBvb+vL9W3D
L4AdvqyY4oUn2s6WtpII
=xLej
-----END PGP SIGNATURE-----