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.
--- Volume group ---
VG Name main
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 35
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 18.62 GB
PE Size 4.00 MB
Total PE 4767
Alloc PE / Size 4718 / 18.43 GB
Free PE / Size 49 / 196.00 MB
VG UUID W5Hqed-zQba-aRdc-sAsc-XF2K-G0AM-xjJd8k
--- 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:11
--- Logical volume ---
LV Name /dev/main/root_snap_23nov
VG Name main
LV UUID 5m5J20-JSZY-fa4r-cgWd-rcib-KBWI-ChUYtK
LV Write Access read/write
LV snapshot status INACTIVE destination for /dev/main/root
LV Status available
# open 0
LV Size 17.43 GB
Current LE 4462
COW-table size 1.00 GB
COW-table LE 256
Snapshot chunk size 4.00 KB
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:13
--- Physical volumes ---
PV Name /dev/dm-9
PV UUID 16lgMw-dDfK-BlUw-lWLE-ZIxl-Kcxh-2YRFhP
PV Status allocatable
Total PE / Free PE 4767 / 49
--- Volume group ---
VG Name plain
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 49
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 7
Open LV 3
Max PV 0
Cur PV 4
Act PV 4
VG Size 107.09 GB
PE Size 4.00 MB
Total PE 27415
Alloc PE / Size 27159 / 106.09 GB
Free PE / Size 256 / 1.00 GB
VG UUID Ypp8Lx-Kms7-8RpD-rmeH-FvJx-uBmF-9el18I
--- Logical volume ---
LV Name /dev/plain/gpgbackups
VG Name plain
LV UUID BHk28n-2Y83-oazR-NFdA-vcBJ-dbjJ-8zWwKR
LV Write Access read/write
LV Status available
# open 0
LV Size 45.00 GB
Current LE 11520
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Logical volume ---
LV Name /dev/plain/media
VG Name plain
LV UUID nP6Bg9-Hgbw-dvFv-wr04-XYiU-aRQe-9x4K47
LV Write Access read/write
LV Status available
# open 2
LV Size 32.00 GB
Current LE 8192
Segments 10
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
--- Logical volume ---
LV Name /dev/plain/plainswap
VG Name plain
LV UUID Vg3DdO-7nXi-GKBO-g5he-Vq2x-xexZ-tZJf1I
LV Write Access read/write
LV Status available
# open 2
LV Size 4.00 GB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
--- Logical volume ---
LV Name /dev/plain/rootextend
VG Name plain
LV UUID cI0k1y-tdxM-KcLL-b6Gw-7E4j-Lbbi-9JqEYN
LV Write Access read/write
LV snapshot status source of
/dev/plain/rootextend_snap_23nov [active]
LV Status available
# open 2
LV Size 12.49 GB
Current LE 3197
Segments 5
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
--- Logical volume ---
LV Name /dev/plain/plainswap2
VG Name plain
LV UUID H5eCgL-cwyk-KMmt-up2X-TmF2-vLfz-HfbnxN
LV Write Access read/write
LV Status available
# open 0
LV Size 4.00 GB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:7
--- Logical volume ---
LV Name /dev/plain/spdvd
VG Name plain
LV UUID dgDEbm-WghB-rUUZ-inh5-fpi7-cOLR-c0gCPy
LV Write Access read/write
LV Status available
# open 0
LV Size 4.60 GB
Current LE 1178
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:8
--- Logical volume ---
LV Name /dev/plain/rootextend_snap_23nov
VG Name plain
LV UUID Jvomj6-aLAt-sahH-TJB2-frQR-0EZH-2vO9v2
LV Write Access read/write
LV snapshot status active destination for /dev/plain/rootextend
LV Status available
# open 0
LV Size 12.49 GB
Current LE 3197
COW-table size 4.00 GB
COW-table LE 1024
Allocated to snapshot 24.95%
Snapshot chunk size 4.00 KB
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:6
--- Physical volumes ---
PV Name /dev/sda12
PV UUID 0joLcE-bvH3-oft7-q58t-9Lu3-SIy6-PIiP7D
PV Status allocatable
Total PE / Free PE 7152 / 0
PV Name /dev/sda13
PV UUID 1cfDDT-glhc-f8uU-CPMT-Z0hb-SwTa-woQfwK
PV Status allocatable
Total PE / Free PE 7152 / 256
PV Name /dev/sda10
PV UUID juQbmw-c5NE-Q4D1-IGEf-y6l6-NTS0-VurSwb
PV Status allocatable
Total PE / Free PE 7152 / 0
PV Name /dev/sda6
PV UUID mLDOzL-9VYT-Waa8-Zoed-QtGq-RLgS-872Sos
PV Status allocatable
Total PE / Free PE 5959 / 0
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x5d15d97d
Device Boot Start End Blocks Id System
/dev/sda1 1 592 4749312 7 HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/sda2 593 1200 4876200 83 Linux
Partition 2 does not end on cylinder boundary.
/dev/sda3 1200 30401 234564120 5 Extended
Partition 3 does not end on cylinder boundary.
/dev/sda5 1200 4117 23435968+ 83 Linux
/dev/sda6 4117 7156 24411208+ 83 Linux
/dev/sda7 7156 7181 196528+ 83 Linux
/dev/sda8 7181 9612 19527448+ 83 Linux
/dev/sda9 9612 13259 29294968+ 83 Linux
/dev/sda10 13259 16906 29294968+ 83 Linux
/dev/sda11 16906 20553 29294968+ 83 Linux
/dev/sda12 20553 24200 29294968+ 83 Linux
/dev/sda13 24200 27847 29294968+ 83 Linux
/dev/sda14 27847 30401 20517808+ 83 Linux
plain-rootextend-real (253, 3)
main-root (253, 11)
sda8_crypt (253, 9)
plain-gpgbackups (253, 0)
plain-rootextend_snap_23nov-cow (253, 5)
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)
