[pkg-cryptsetup-devel] Bug#507721: Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it
Christian Jaeger
christian at jaeger.mine.nu
Tue Dec 16 01:07:34 UTC 2008
Jonas Meurer wrote:
> tags 507721 + help
> thanks
>
> Hello,
>
> I just tried to understand the whole issue. I'll try to describe what I
> got so far, please tell me If i got something wrong:
>
> On 03/12/2008 Christian Jaeger wrote:
>
>> I did install the system using the capabilities of the Debian
>> installer to create encrypted root partitions and LVM setups, and it
>> worked for some time; probably the first occurrence of the problem was
>> when I already started compiling and installing kernels manually (from
>> kernel.org's Git, using make install and make modules_install),
>> although this too worked upon the first (few?) kernel version(s). And,
>> again, sometimes it still works, like when I installed 2.6.27.5 I
>> could not reproduce the problem. This is also documented on a bug I
>> reported against initramfs-tools, here:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
>>
>
> Does this mean, that you've chosen 'Guided - use entire disk and setup
> encrypted LVM' at the debian installer partitioner?
>
No, I didn't choose "entire disk", since I had a couple oem windows
partitions on the new laptop which I wanted to keep (which turned out
not to work (windows didn't boot anymore), but that's another story).
So from what I remember I did:
- choose custom partitioning
- created a handful of partitions (as I always do, on all machines I'm
using lvm on, just create some handy number of partitions which can be
used as physical volumes or whatever later on)
- made of one of these partitions an encrypted one
- made that encrypted one a physical volume
- made out of that physical volume a volume group, named "main"
- created on that volume group swap, and the root partition
- made sda7 /boot (no lvm, no encryption)
This was all from the debian installer.
> And you didn't change that setup except compiling custom kernels, right?
>
I did:
- create a second volume group named "plain", which is based on multiple
unencrypted sdaX partitions as physical volumes
- on that "plain" volume group, I created a new swap, because I've had
quite terrible latency issues with the encrypted-everything in
combination with nvidia and 2 cores--this is an ongoing search, too;
though going to unencrypted swap didn't help much, and so some time
later I also moved most of the root partition (the whole /usr directory)
to a partition on the "plain" volume group. I've also got a "media"
partition on that group.
>
>> --- Logical volume ---
>> LV Name /dev/main/root
>> VG Name main
>> LV UUID M51c6n-rw9j-vKBU-UnIJ-GvXD-nVw0-7yisre
>> LV Write Access read/write
>> LV snapshot status source of
>> /dev/main/root_snap_23nov [INACTIVE]
>> LV Status available
>> # open 2
>> LV Size 17.43 GB
>> Current LE 4462
>> Segments 2
>> Allocation inherit
>> Read ahead sectors auto
>> - currently set to 256
>> Block device 253:2
>> [...]
>> novo:~# dmsetup ls
>> plain-rootextend-real (253, 8)
>> main-root (253, 2)
>> sda8_crypt (253, 0)
>> plain-gpgbackups (253, 5)
>> plain-rootextend_snap_23nov-cow (253, 10)
>> plain-rootextend_snap_23nov (253, 11)
>> plain-plainswap2 (253, 12)
>> plain-media (253, 6)
>> main-root_snap_23nov (253, 4)
>> plain-rootextend (253, 9)
>> plain-plainswap (253, 7)
>> main-root-real (253, 1)
>> plain-spdvd (253, 13)
>> main-root_snap_23nov-cow (253, 3)
>>
>
> Ok, that one looks like you've much more dm-crypt mappings than a
> default setup. you do have main-root, main-root-real,
> main-root_snap_23nov and root_snap_23nov.
>
See the attached _vgdisplay, _fdisk, and _dmsetup_ls files, from:
vgdisplay -v > _vgdisplay
fdisk -l /dev/sda > _fdisk
dmsetup ls > _dmsetup_ls
Something possibly relevant I've just noticed: the device numbers shown
by dmsetup ls seem not to be stable, in the new run they are +-all
different.
>
>> novo:~# l /dev/dm-0
>> brw-rw---- 1 root disk 253, 0 2008-12-03 21:00 /dev/dm-0
>>
>> thus dm-0 is sda8_crypt
>>
>> novo:~# cat /etc/crypttab
>> sda8_crypt /dev/sda8 none luks
>> novo:~#
>>
>> novo:~# cat /etc/fstab |perl -wne 'print if m|\s/\s|'
>> /dev/mapper/main-root / reiserfs defaults,noatime 0 1
>> novo:~#
>>
>
> ok, you use main-root as rootfs, and main-root depends on main-root-real,
> which itself depends on sda8_crypt, correct?
>
I've never told any tool anything about main-root-real; my guess is that
it is used by the device mapper as some helper thing because I did
create a snapshot of main-root. This is confirmed now that I did
"lvremove /dev/main/root_snap_23nov":
novo:~# diff -u _dmsetup_ls _dmsetup_ls2
--- _dmsetup_ls 2008-12-16 01:38:33.000000000 +0100
+++ _dmsetup_ls2 2008-12-16 01:53:18.000000000 +0100
@@ -6,9 +6,6 @@
plain-rootextend_snap_23nov (253, 6)
plain-plainswap2 (253, 7)
plain-media (253, 1)
-main-root_snap_23nov (253, 13)
plain-rootextend (253, 4)
plain-plainswap (253, 2)
-main-root-real (253, 10)
-main-root_snap_23nov-cow (253, 12)
plain-spdvd (253, 8)
> is this the reason why your LVM over dm-crypt setup has one more level
> than the usual setups?
>
So the answer is no, right?
Except if the initrd scripts cannot deal with snapshots, maybe ?
Does creating a snapshot really make the main-root device appear as
having an additional level inbetween for the initrd scripts?
> Could you try to explain what the reason is why your setup fails while
> others work?
No of course not or I would have long told you.
> and if the missing recursion of get_lvm_deps() is really
> the reason, why does it only fail on some kernels for you?
As I did say in my previous mails, I don't know.
And I don't know whether it's got anything to do with kernels. Or the
order in which something is initialized at boot, or the phase of moon,
or maybe whether I've got snapshots running.
> I'm not
> confident that you tracked the real bug.
Well, I'm confident that I've tracked the code at the place where the
bug manifests itself correctly in the sense of "I could 100% confirm
that if I make it recurse it sees the crypto stuff and will get me the
crypto stuff into the initrd, whereas if I don't make it recurse the
crypto file will be missing".
What I don't know about is this sort of code duplication for copying
kernel object files; why is it there, is it bad that my code calls,
because it's having an unexpected crypt/non-crypt (which one was it?)
argument at that place, the sort-of copied code with an unexpected
argument--but if it the object file copying code would be unified,
wouldn't it be clean?
> And as David Härdeman, the one
> who wrote all the cryptroot initramfs scripts, isn't available
> currently, i hesitate to apply your patch.
>
Well, hard decision; I wouldn't want to apply it without review that
late in the Debian release cycle either, but then it may bite quite a
number of people, too, so, maybe possibly there is a middle ground? Like
how about providing the patched script as an alternative and mention in
the docs where it is? And certainly leave these bug reports open as long
as they are not really resolved; as I did my first search and report on
initramfs, could maybe the archived bug there be made found again?
Christian.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _vgdisplay
Url: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20081216/e41acf99/attachment.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _fdisk
Url: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20081216/e41acf99/attachment-0001.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _dmsetup_ls
Url: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20081216/e41acf99/attachment-0002.txt
More information about the pkg-cryptsetup-devel
mailing list