On Sat, 2026-01-24 at 15:17 +0100, Benjamin Drung wrote:
> 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.
I came up with an possible explanation. Can you test with just the
stderr redirection to /dev/null removed?
```
CPIO=cpio
if 3cpio --help | grep -q -- --create; then
CPIO=3cpio
fi
```
My assumption is that grep finds `--create` and exits while 3cpio still
tries to write to stdout and then fail. This snippet shows this
behaviour:
```
$ if 3cpio --help | true; then true; fi
thread 'main' panicked at library/std/src/io/stdio.rs:1123:9:
failed printing to stdout: Broken pipe (os error 32)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
--
Benjamin Drung
Debian & Ubuntu Developer
