On 12/26/2013 10:26 PM, Colin Guthrie wrote:
> It seems that when the device is unlocked, it will trigger a change
> event which in turn re-writes the settled job which was diligently
> removed after it was run.
>
> Due to the previous fix, this isn't crazy important as the triggered
> job should exit, but avoiding this in the first place is still
> desirable.
> ---
>
> Note, I'm not sure if this is wise or not. The previous patch alone
> fixes the issue, so this is just an efficiency saving. It might be
> that this is needed - e.g. if you have any encrypted volume on top
> of some other mapped device such as RAID, so please only apply this
> patch if you are sure it will not cause regressions!!
>
>
>
> modules.d/90crypt/parse-crypt.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/modules.d/90crypt/parse-crypt.sh b/modules.d/90crypt/parse-crypt.sh
> index a6b5252..cfa6ac9 100755
> --- a/modules.d/90crypt/parse-crypt.sh
> +++ b/modules.d/90crypt/parse-crypt.sh
> @@ -10,7 +10,7 @@ if ! getargbool 1 rd.luks -d -n rd_NO_LUKS; then
> else
> {
> echo 'SUBSYSTEM!="block", GOTO="luks_end"'
> - echo 'ACTION!="add|change", GOTO="luks_end"'
> + echo 'ACTION!="add", GOTO="luks_end"'
> } > /etc/udev/rules.d/70-luks.rules.new
>
> LUKS=$(getargs rd.luks.uuid -d rd_LUKS_UUID)
>
Hmm, dm-devices get only active on "change" :-/ So, if a crypt device is on
another dm-device, the rule would not trigger anymore.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
