Per Mike's request https://bugs.gentoo.org/645508#c8 Recent dracuts started breaking cryptsetup boots. 046 situation is described in https://bugs.gentoo.org/645508#c2 Updating to 047 today, I discovered it still needs additional `master` commits on top to work correctly, since once again I had a boot hang Since there aren't very many commits on top of 047 right now, https://github.com/dracutdevs/dracut/commit/3aa37cafde734719f2377600a17459fad30edfbc is my strongest suspect for making things work again.
(In reply to Leho Kraav (:macmaN @lkraav) from comment #0) > Since there aren't very many commits on top of 047 right now, > https://github.com/dracutdevs/dracut/commit/ > 3aa37cafde734719f2377600a17459fad30edfbc is my strongest suspect for making > things work again. dracut-047-r1 already included mentioned commit. If you still have issues with cryptsetup, please provide more info: add "rd.debug systemd.log_level=debug" to the kernel cmdline and when you get in an emergency shell, copy /run/initramfs/rdsosreport.txt on persistent storage and attach to this bug report. If boot hangs for too long, try to play with rd.retry and rd.timeout options, e.g. "rd.retry=5 rd.timeout=10"
With some `git bisect` effort, I think I was able to identify the culprits. It's about the plymouth module changes they made in the 047 release cycle, then "re-fixed" things on current master. On Gentoo, it's apparently about a fight between `/usr/lib/plymouth` vs `/usr/libexec/plymouth`. First they broke things for us here during 047 release cycle https://github.com/dracutdevs/dracut/commit/421b46f8ae89cfe2b62e880a8a5079ee8c1b3aae Then the probable fix is in the current master https://github.com/dracutdevs/dracut/commit/fe6c7e0f06cde65effb3503a47c31ac39aceefb6 In our case, `plymouth-populate-initrd` sits in `/usr/libexec`.
(In reply to Leho Kraav (:macmaN @lkraav) from comment #2) > On Gentoo, it's apparently about a fight between `/usr/lib/plymouth` vs > `/usr/libexec/plymouth`. This was fixed in 047-r1. See bug 651132.
It's not fixed even with 047-r1, but I have no time to debug and it's highly likely 048 has it fixed upstream. I'll file a version bump bug next.
fixed in 0.48
