<div dir="ltr">On Wed, 08 May 2024 13:48:16 +0100 Luca Boccassi <<a href="mailto:bluca@debian.org">bluca@debian.org</a>> wrote:<br>> On Wed, 8 May 2024 12:00:34 +0200 Roderich Schupp<br>> <<a href="mailto:roderich.schupp@gmail.com">roderich.schupp@gmail.com</a>> wrote:<br>> > I just saw that the missing libkmod (dlopen'ed by udevadm) is already taken<br>> > care of by /usr/share/initramfs-tools/hooks/udev.<br>> <br>> Again, what was the issue exactly? kmod is already taken care of, that<br>> leaves gcrypt or lz4 which are only used for the journal, why would the<br>> abscence of those cause issues for cryptsetup? What was the actual<br>> error and what actually fixed it, precisely?<br><div><br></div><div>Sorry for the late answer, but I didn't receive your comments on this bug</div><div>(as the reporter, shouldn't I be subscribed to it automatically?).</div><div><br></div><div>Anyway, the culprit is definitely the missing libkmod.</div><div>I was looking at /usr/share/initramfs-tools/hooks/udev and thought that it</div><div>would have added it to the initrd, but in systemd/256~rc1-1~exp2 that</div><div>did work only if update-initramfs is called while standing in /, e.g. when installing</div><div>a kernel, but **not** when invoking update-initramfs "by hand" in some random</div><div>directory. </div><div>This is fixed in 256-rc2 and decryption of my root device works</div><div>as expected (even though the initrd is lacking libgcrypt and libgpg-error).</div><div><br></div><div>Cheers, Roderich<br></div></div>