crypt-cleanup.sh question

crypt-cleanup.sh question

[Mr Dash Four]

What is the rationale behind closing all /dev/mapper/luks-* devices 
which are not 'busy' in this shell script? Why would they have to be 
'busy' (I presume already mapped) to be left open?

I am asking this because when the smartcard module opens a LUKS drive 
(not root - '/') - this drive later to be mapped from the actual root 
/etc/fstab file as '/dev/mapper/luks-XXX /some/directory' - this 
operation does not succeed and I presume crypt-cleanup.sh closes it up 
before the actual root can get it and therefore it cannot be mapped.

Re: crypt-cleanup.sh question

[Mr Dash Four]

> What is the rationale behind closing all /dev/mapper/luks-* devices 
> which are not 'busy' in this shell script? Why would they have to be 
> 'busy' (I presume already mapped) to be left open?
>
> I am asking this because when the smartcard module opens a LUKS drive 
> (not root - '/') - this drive later to be mapped from the actual root 
> /etc/fstab file as '/dev/mapper/luks-XXX /some/directory' - this 
> operation does not succeed and I presume crypt-cleanup.sh closes it up 
> before the actual root can get it and therefore it cannot be mapped.
Further to the above, I was able to verify that the above script is 
indeed to blame for closing LUKS partitions. The only 'busy' partition 
at the time crypt-cleanup.sh runs is the root (/sysroot) so I don't see 
how a LUKS partition (other than root) specified at the kernel command 
line could be opened, unless I am missing something obvious...

Re: crypt-cleanup.sh question

[Mr Dash Four]

>>> What is the rationale behind closing all /dev/mapper/luks-* devices 
>>> which are
>>> not 'busy' in this shell script? Why would they have to be 'busy' (I 
>>> presume
>>> already mapped) to be left open?
>>>
>>> I am asking this because when the smartcard module opens a LUKS 
>>> drive (not
>>> root - '/') - this drive later to be mapped from the actual root 
>>> /etc/fstab
>>> file as '/dev/mapper/luks-XXX /some/directory' - this operation does 
>>> not
>>> succeed and I presume crypt-cleanup.sh closes it up before the 
>>> actual root can
>>> get it and therefore it cannot be mapped.
>> Further to the above, I was able to verify that the above script is 
>> indeed to
>> blame for closing LUKS partitions. The only 'busy' partition at the time
>> crypt-cleanup.sh runs is the root (/sysroot) so I don't see how a 
>> LUKS partition
>> (other than root) specified at the kernel command line could be 
>> opened, unless I
>> am missing something obvious...
>
> So, what's the problem? You get real root and can do everything on the 
> real system afterwards...
Well, 'the problem' as you put it, is that when I open a LUKS partition 
within initramfs (which isn't root!) the crypt-cleanup.sh script in the 
crypt module closes it before switching the real root and therefore that 
partition is no longer available and cannot be mapped.

The same goes if I use the crypt module itself - it asks me for a 
password, opens the required partition and then promptly closes that 
same partition before switching root.

My original query (and the reason for starting this thread) is what is 
the rationale behind this - why not leave the LUKS partitions which were 
open within initramfs to stay open so that they could be mapped by the 
userspace tools/the kernel itself?

Re: crypt-cleanup.sh question

[Harald Hoyer]

On 10/27/2010 02:07 PM, Mr Dash Four wrote:
>
>>>> What is the rationale behind closing all /dev/mapper/luks-* devices which are
>>>> not 'busy' in this shell script? Why would they have to be 'busy' (I presume
>>>> already mapped) to be left open?
>>>>
>>>> I am asking this because when the smartcard module opens a LUKS drive (not
>>>> root - '/') - this drive later to be mapped from the actual root /etc/fstab
>>>> file as '/dev/mapper/luks-XXX /some/directory' - this operation does not
>>>> succeed and I presume crypt-cleanup.sh closes it up before the actual root can
>>>> get it and therefore it cannot be mapped.
>>> Further to the above, I was able to verify that the above script is indeed to
>>> blame for closing LUKS partitions. The only 'busy' partition at the time
>>> crypt-cleanup.sh runs is the root (/sysroot) so I don't see how a LUKS partition
>>> (other than root) specified at the kernel command line could be opened, unless I
>>> am missing something obvious...
>>
>> So, what's the problem? You get real root and can do everything on the real
>> system afterwards...
> Well, 'the problem' as you put it, is that when I open a LUKS partition within
> initramfs (which isn't root!) the crypt-cleanup.sh script in the crypt module
> closes it before switching the real root and therefore that partition is no
> longer available and cannot be mapped.
>
> The same goes if I use the crypt module itself - it asks me for a password,
> opens the required partition and then promptly closes that same partition before
> switching root.
>
> My original query (and the reason for starting this thread) is what is the
> rationale behind this - why not leave the LUKS partitions which were open within
> initramfs to stay open so that they could be mapped by the userspace tools/the
> kernel itself?
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Hmm, maybe this could do it:


diff --git a/modules.d/90crypt/crypt-cleanup.sh b/modules.d/90crypt/crypt-cleanup.sh
index e9fc6ba..4722425 100755
--- a/modules.d/90crypt/crypt-cleanup.sh
+++ b/modules.d/90crypt/crypt-cleanup.sh
@@ -4,6 +4,11 @@
  # close everything which is not busy
  rm -f /etc/udev/rules.d/70-luks.rules >/dev/null 2>&1

+if getargs rd_LUKS_UUID || getarg rd_NO_LUKS; then
+    # do not clean up, if we did not autoassemble
+    exit 0
+fi
+
  while true; do
      local do_break="y"
      for i in /dev/mapper/luks-*; do

Re: crypt-cleanup.sh question

[Mr Dash Four]

> Hmm, maybe this could do it:
>
>
> diff --git a/modules.d/90crypt/crypt-cleanup.sh 
> b/modules.d/90crypt/crypt-cleanup.sh
> index e9fc6ba..4722425 100755
> --- a/modules.d/90crypt/crypt-cleanup.sh
> +++ b/modules.d/90crypt/crypt-cleanup.sh
> @@ -4,6 +4,11 @@
>  # close everything which is not busy
>  rm -f /etc/udev/rules.d/70-luks.rules >/dev/null 2>&1
>
> +if getargs rd_LUKS_UUID || getarg rd_NO_LUKS; then
> +    # do not clean up, if we did not autoassemble
> +    exit 0
> +fi
> +
>  while true; do
>      local do_break="y"
>      for i in /dev/mapper/luks-*; do
That is good, but I have a better idea (currently implementing it - will 
post the patch later today) - keep open only the partitions specified 
via rd_LUKS_UUID and close everything else. Close everything if 
rd_NO_LUKS is used (there shouldn't be any LUKS partitions open if that 
parameter was used, but you can't be too careful!). How's that?

On a side note: I thought rd_LUKS_UUID, rd_LUKS_KEYPATH, rd_LUKS_KEYDEV 
and rd_NO_LUKS are sort of 'deprecated' in favour of the new rd.luks.* 
format - is that not the case?

Another query - is there any particular reason why all rd_LUKS_UUID need 
to be mapped to luks-UUID? I'd rather be able to choose a more 
meaningful name than the 'standard' luks-UUID - just a thought.

Re: crypt-cleanup.sh question

[Harald Hoyer]

On 10/27/2010 03:17 PM, Mr Dash Four wrote:
>
>> Hmm, maybe this could do it:
>>
>>
>> diff --git a/modules.d/90crypt/crypt-cleanup.sh
>> b/modules.d/90crypt/crypt-cleanup.sh
>> index e9fc6ba..4722425 100755
>> --- a/modules.d/90crypt/crypt-cleanup.sh
>> +++ b/modules.d/90crypt/crypt-cleanup.sh
>> @@ -4,6 +4,11 @@
>> # close everything which is not busy
>> rm -f /etc/udev/rules.d/70-luks.rules >/dev/null 2>&1
>>
>> +if getargs rd_LUKS_UUID || getarg rd_NO_LUKS; then
>> + # do not clean up, if we did not autoassemble
>> + exit 0
>> +fi
>> +
>> while true; do
>> local do_break="y"
>> for i in /dev/mapper/luks-*; do
> That is good, but I have a better idea (currently implementing it - will post
> the patch later today) - keep open only the partitions specified via
> rd_LUKS_UUID and close everything else. Close everything if rd_NO_LUKS is used
> (there shouldn't be any LUKS partitions open if that parameter was used, but you
> can't be too careful!). How's that?
>
> On a side note: I thought rd_LUKS_UUID, rd_LUKS_KEYPATH, rd_LUKS_KEYDEV and
> rd_NO_LUKS are sort of 'deprecated' in favour of the new rd.luks.* format - is
> that not the case?

yes, they will be.

> Another query - is there any particular reason why all rd_LUKS_UUID need to be
> mapped to luks-UUID? I'd rather be able to choose a more meaningful name than
> the 'standard' luks-UUID - just a thought.

hmm, yes/no... I like meaningful symlinks :)

Re: crypt-cleanup.sh question

[Mr Dash Four]

>> On a side note: I thought rd_LUKS_UUID, rd_LUKS_KEYPATH, 
>> rd_LUKS_KEYDEV and
>> rd_NO_LUKS are sort of 'deprecated' in favour of the new rd.luks.* 
>> format - is
>> that not the case?
>
> yes, they will be.
When is this planned?

>> Another query - is there any particular reason why all rd_LUKS_UUID 
>> need to be
>> mapped to luks-UUID? I'd rather be able to choose a more meaningful 
>> name than
>> the 'standard' luks-UUID - just a thought.
>
> hmm, yes/no... I like meaningful symlinks :)
OK, how about "luks-<meaningful_name>" then? ;-)

Re: crypt-cleanup.sh question

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Excerpts from Mr Dash Four's message of Wed Oct 27 16:16:05 +0200 2010:
> 
> >> On a side note: I thought rd_LUKS_UUID, rd_LUKS_KEYPATH, 
> >> rd_LUKS_KEYDEV and
> >> rd_NO_LUKS are sort of 'deprecated' in favour of the new rd.luks.* 
> >> format - is
> >> that not the case?
> >
> > yes, they will be.
> When is this planned?

I'm improving my patch at the moment, so I hope - soon. :-)
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: crypt-cleanup.sh question

[Harald Hoyer]

On 10/27/2010 04:16 PM, Mr Dash Four wrote:
>
>>> On a side note: I thought rd_LUKS_UUID, rd_LUKS_KEYPATH, rd_LUKS_KEYDEV and
>>> rd_NO_LUKS are sort of 'deprecated' in favour of the new rd.luks.* format - is
>>> that not the case?
>>
>> yes, they will be.
> When is this planned?

I am working on it for the rest of dracut.