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)
--
1.8.4.5
--
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
