Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90938 > unrolled thread

Bug#1125948: dracut: Missing dependency on cpio (?)

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1125948: dracut: Missing dependency on cpio (?) Benjamin Drung <bdrung@debian.org> - 2026-01-23 21:50 +0100
    Bug#1125948: dracut: fails to detect 3cpio Santiago Vila <sanvila@debian.org> - 2026-01-24 14:30 +0100
      Bug#1125948: dracut: fails to detect 3cpio Benjamin Drung <bdrung@debian.org> - 2026-01-24 15:20 +0100
        Bug#1125948: dracut: fails to detect 3cpio Santiago Vila <sanvila@debian.org> - 2026-01-24 17:40 +0100
          Bug#1125948: dracut: fails to detect 3cpio Santiago Vila <sanvila@debian.org> - 2026-01-24 19:30 +0100

#90938 — Bug#1125948: dracut: Missing dependency on cpio (?)

On Mon, 2026-01-19 at 13:01 +0100, Santiago Vila wrote:
> During a rebuild of all packages in unstable, package src:linux-signed-amd64
> failed to build with this error message:
> 
> /usr/bin/dracut: line 2772: cpio: command not found
>
> So it seems as if dracut had a missing dependency on cpio. Or maybe it fails
> to detect that 3cpio is installed instead and keeps using cpio anyway. Or maybe
> 3cpio should provide cpio and use the alternatives mechanism so that /usr/bin/cpio
> exists and may be used. This is why I've put "?" in the subject. Please use
> reassign if appropriate.
> 
> The error does not always happen, which is strange, but it happens often enough
> to consider the issue as RC. I've put a bunch of failed build logs
> here (for linux-signed-amd64) for reference:
> 
> https://people.debian.org/~sanvila/build-logs/202601/
> 
> As always, if you cannot reproduce the bug please contact me privately, as I
> am willing to provide ssh access to a virtual machine where this randomness
> is reproducible.

I saw this failure in a log as well but was not able to reproduce it.
Help in debugging will be appreciated. Here is the current debugging
status:

dracut either needs 3cpio or cpio to read/write cpio files. It will
prefer 3cpio if available. dracut uses this check to see if 3cpio is
available (line 1489):

```
CPIO=cpio
if 3cpio --help 2> /dev/null | grep -q -- --create; then
    CPIO=3cpio
fi
```

Later on (line 2732) it will take different code paths based on CPIO:

```
if [[ -n $enhanced_cpio ]]; then
    [...]
elif [[ $CPIO == 3cpio ]]; then
    [...]
else
    [...]
fi
```

That's where dracut takes else branch and fails (only 3cpio is available
and not cpio).

We have line 1103 that ensures that $PATH has the common path included:

```
# Ensure that the standard search paths are searched.
for path in /usr/sbin /usr/bin /sbin /bin; do
    if ! [[ ":${PATH}:" =~ .*:${path}:.* ]]; then
        PATH="${PATH:+${PATH}:}$path"
    fi
done
```

Is the 3cpio --help call failing? If so, why?

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [next] | [standalone]

#90944 — Bug#1125948: dracut: fails to detect 3cpio

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 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.

[toc] | [prev] | [next] | [standalone]

#90946 — Bug#1125948: dracut: fails to detect 3cpio

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

[toc] | [prev] | [next] | [standalone]

#90949 — Bug#1125948: dracut: fails to detect 3cpio

> > 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 refer to this:

    if [[ $parallel != "yes" ]]; then
        for i in *; do
            [[ -f $i/modules.dep ]] || [[ -f $i/modules.dep.bin ]] || continue
            "$dracut_cmd" --kver="$i" "${dracut_args[@]}"
            _rc=$?
            if [[ $_rc -gt 0 ]]; then
                printf "%s\n" "dracut[F]: image generation failed for kernel '$i'." >&2
                ((ret += _rc))
            fi
        done
    else
        for i in *; do
            [[ -f $i/modules.dep ]] || [[ -f $i/modules.dep.bin ]] || continue
-->         "$dracut_cmd" --kver="$i" "${dracut_args[@]}" &
        done

This "&" at the end is what draw my attention and made me to remember
the funny bug in "sumo" which I pointed out before.

> > 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.

This first modified version fails a lot less, maybe because by adding those
additional lines we make the race condition to be less likely.

But I can't see any special thing in the logs (are they redirected somewhere?)

> Can you test with just[*] the stderr redirection to /dev/null removed?

This second modified version fails again quite often, but at least
we can see the error from 3cpio:

[...]
I: /vmlinuz is now a symlink to boot/vmlinuz-6.18.5+deb14-cloud-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.18.5+deb14-cloud-amd64
/etc/kernel/postinst.d/dracut:
dracut: Generating /boot/initrd.img-6.18.5+deb14-cloud-amd64

thread 'main' panicked at library/std/src/io/stdio.rs:1165:9:
failed printing to stdout: Broken pipe (os error 32)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
/usr/bin/dracut: line 2772: cpio: command not found
dracut[F]: Creation of /boot/initrd.img-6.18.5+deb14-cloud-amd64 failed
[...]


[*] Note that after cloning from salsa I still have to revert the
change made by Bastian so that it depends again on 3cpio|cpio. The
first time I forgot about such little detail and was suspiciously
surprised that it did not fail at all...


I believe the fact that 3cpio is written in Rust is related to this issue.

I'm going to try this instead and will let you know how it goes:

--- a/dracut.sh
+++ b/dracut.sh
@@ -1483,7 +1483,7 @@ elif [[ -n $persistent_policy && ! -d "/dev/disk/${persistent_policy}" ]]; then
 fi
 
 CPIO=cpio
-if 3cpio --help | grep -q -- --create; then
+if 3cpio --help 2> /dev/null | cat | grep -q -- --create; then
     CPIO=3cpio
 fi

You can try this for the equivalent simplified example:

if 3cpio --help | cat | true; then true; fi

Thanks.

[toc] | [prev] | [next] | [standalone]

#90953 — Bug#1125948: dracut: fails to detect 3cpio

On Sat, Jan 24, 2026 at 05:48:53PM +0100, Benjamin Drung wrote:

Note: My simple "cat" change did not solve the problem.

> > But I can't see any special thing in the logs (are they redirected somewhere?)
> 
> Does this really fail? help_output=$(3cpio --help) will always read the
> full output and therefore 3cpio should not fail with broken pipe. So I
> would expect this patch to be a workaround as side effect.

You are right.

The failure rate was extremely low, maybe I mixed some build logs from
the previous run.

Now I've tested it again and the failure rate is effectively zero.

> Thanks. That confirms my suspicion. grep terminates and 3cpio cannot
> write to the pipe any more. Instead of happily quitting, it throws an
> error message and exits with code 1. I'll fix 3cpio to handle the broken
> pipe case better.

Great. If you do that please retitle #1126301 to something more
suitable (I believed 3cpio was innocent but after knowing that Rust
treats pipes differently I agree that the bug make sense).

Thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web