On Sat, 2026-01-24 at 14:22 +0100, Santiago Vila wrote: > retitle 1125948 dracut: fails to detect 3cpio > thanks > > On Fri, Jan 23, 2026 at 09:39:07PM +0100, Benjamin Drung wrote: > > [...] > > > > Is the 3cpio --help call failing? If so, why? > > Thanks a lot for this detailed explanation about how all this is (was) > supposed to work. > > I'm doing a retitle to better reflect what we know about this failure. > (Based on your explanations, if the autodetection worked as designed > then there would be nothing wrong in calling "3cpio" as "3cpio"). > > > This looks like some kind of race condition to me, similar to this one > which happened some time ago in the "sumo" package. This is the > message where Niels diagnosed the problem and solved the mystery: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082135#19 > > With the sumo package in mind, I looked at the dracut script > to see if there was any occurrence of "&", and found that > there is a "parallel mode". > > Can you tell if this parallel mode is the default, and if not, what > other reasons for a race condition can be?
I am not aware of any "parallel mode" here. The postinst calls dracut just with >&2 to redirect stdout to stderr. > I would be willing to build linux-signed-amd64 a lot of times using a > modified dracut package with whatever debug changes we could add to > see what's going on (even if they are simple "echo foo"), so I'm > open for suggestions about those potential changes. Thanks. Could you try to run a test with this patch applied to dracut: https://github.com/dracut-ng/dracut-ng/pull/2109/changes Plus add an "exit 1" after those 3 dinfo/dwarning calls to let dracut fail, because I expect dracut to take the happy path. -- Benjamin Drung Debian & Ubuntu Developer
