From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Zbvad-0005Hj-6m for mharc-grub-devel@gnu.org; Tue, 15 Sep 2015 15:08:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbvaW-0005Gi-UB for grub-devel@gnu.org; Tue, 15 Sep 2015 15:08:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbvaT-0003zW-Mr for grub-devel@gnu.org; Tue, 15 Sep 2015 15:08:20 -0400 Received: from alpheca.uberspace.de ([185.26.156.48]:43026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbvaT-0003zS-EV for grub-devel@gnu.org; Tue, 15 Sep 2015 15:08:17 -0400 Received: (qmail 10162 invoked from network); 15 Sep 2015 19:08:14 -0000 Received: from localhost (HELO 127.0.0.1) (127.0.0.1) by alpheca.uberspace.de with SMTP; 15 Sep 2015 19:08:14 -0000 Subject: Re: Fwd: LVM/BTRFS on LUKS unreadable To: grub-devel@gnu.org References: <55DDF9BB.8050503@autoboot.org> From: Klemens Nanni X-Enigmail-Draft-Status: N1110 Message-ID: <55F86C9B.6090901@autoboot.org> Date: Tue, 15 Sep 2015 19:08:11 +0000 MIME-Version: 1.0 In-Reply-To: <55DDF9BB.8050503@autoboot.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 185.26.156.48 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 19:08:25 -0000 -----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 > To: bug-grub@gnu.org > > 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 4096 aes-xts-plain > > > $ 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-----