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

Groups > linux.debian.bugs.rc > #409491 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.rc

Contents

  Bug#1125948: dracut: Missing dependency on cpio (?) Santiago Vila <sanvila@debian.org> - 2026-01-19 13:10 +0100
    Bug#1125948: dracut: Missing dependency on cpio (?) Paul Gevers <elbrus@debian.org> - 2026-01-23 20:30 +0100
      Bug#1125948: dracut: Missing dependency on cpio (?) Adrian Bunk <bunk@debian.org> - 2026-01-23 22:00 +0100
    Processed: Re: Bug#1125948: dracut: Missing dependency on cpio (?) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-01-23 21:50 +0100
    Processed: Re: Bug#1125948: dracut: Missing dependency on cpio (?) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-01-24 11:00 +0100
    Bug#1126301: 3cpio: something wrong with it (?) Santiago Vila <sanvila@debian.org> - 2026-01-24 14:50 +0100
    Bug#1125948: dracut: fails to detect 3cpio Benjamin Drung <bdrung@debian.org> - 2026-01-24 17:00 +0100
    Bug#1125948: dracut: fails to detect 3cpio Benjamin Drung <bdrung@debian.org> - 2026-01-24 18:00 +0100

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

Package: dracut
Version: 109-7
Tags: forky sid
Severity: serious
Control: affects -1 src:linux-signed-amd64

Dear maintainer:

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.

Thanks.

[toc] | [next] | [standalone]

#409770

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, 19 Jan 2026 13:01:10 +0100 Santiago Vila <sanvila@debian.org> wrote:
> /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:

I've had discussions on IRC on #debian-release about the current version 
of src:linux, mentioning this bug, because for some time during the past 
week src:linux was blocked by piuparts regressions where the same text 
was found as in this bug. It seems that the failed piuparts runs were 
retried and installing of the linux binaries is now marked as OK.

I'm very much not comfortable with the situation, which appear to me 
like an intermittent failure. If I understood waldi correctly the 
version of linux in unstable is the first to use dracut. Because of this 
bug report "error does not always happen" and the piuparts failures that 
turned OK, I have put a block on migration of linux until either this 
bug is fixed, or it's explained why migrating of linux with this issue 
present is OK. Please assume I don't know how packaging and installing 
linux works when explaining.

Any Release Team member that is convinced migration is fine can unblock 
linux before I react, no need to wait for me.

Paul

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

#409775

On Fri, Jan 23, 2026 at 08:25:51PM +0100, Paul Gevers wrote:
> Hi,
> 
> On Mon, 19 Jan 2026 13:01:10 +0100 Santiago Vila <sanvila@debian.org> wrote:
> > /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:
> 
> I've had discussions on IRC on #debian-release about the current version of
> src:linux, mentioning this bug, because for some time during the past week
> src:linux was blocked by piuparts regressions where the same text was found
> as in this bug. It seems that the failed piuparts runs were retried and
> installing of the linux binaries is now marked as OK.
> 
> I'm very much not comfortable with the situation, which appear to me like an
> intermittent failure. If I understood waldi correctly the version of linux
> in unstable is the first to use dracut. Because of this bug report "error
> does not always happen" and the piuparts failures that turned OK, I have put
> a block on migration of linux until either this bug is fixed, or it's
> explained why migrating of linux with this issue present is OK. Please
> assume I don't know how packaging and installing linux works when
> explaining.
>...

Nothing of this looks specific to linux packaging:

  Package: dracut-core
  Depends: 3cpio | cpio, ...

cpio does provide a "cpio" program, 3cpio does not.
dracut calls "cpio".

This is a clear bug in dracut-core.

The "error does not always happen" is likely related to the fact that 
this will work when the cpio package already is/gets installed for a 
different reason (other dependencies, cpio is "Priority: important").

> Paul

cu
Adrian

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

#409773 — Processed: Re: Bug#1125948: dracut: Missing dependency on cpio (?)

Processing control commands:

> clone -1 -2
Bug #1125948 {Done: Bastian Blank <waldi@debian.org>} [dracut] dracut: Missing dependency on cpio (?)
Bug 1125948 cloned as bug 1126301
> reassign -2 3cpio
Bug #1126301 {Done: Bastian Blank <waldi@debian.org>} [dracut] dracut: Missing dependency on cpio (?)
Bug reassigned from package 'dracut' to '3cpio'.
No longer marked as found in versions dracut/109-7.
No longer marked as fixed in versions dracut/109-8.

-- 
1125948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125948
1126301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126301
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

#409806 — Processed: Re: Bug#1125948: dracut: Missing dependency on cpio (?)

Processing control commands:

> reopen -1
Bug #1126301 {Done: Bastian Blank <waldi@debian.org>} [3cpio] dracut: Missing dependency on cpio (?)
Bug reopened
Ignoring request to alter fixed versions of bug #1126301 to the same values previously set

-- 
1126301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126301
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

#409836 — Bug#1126301: 3cpio: something wrong with it (?)

severity 1126301 normal
thanks

Paul Gevers wrote:
> The cloned bug was already closed, as the issue was worked around, but 
> I'm pretty sure that Bastian intended 3cpio to have an open bug.

For completeness, I think 3cpio is actually innocent and does not
deserve a serious bug for this, so I'm also downgrading the clone for now.

The package provides /usr/bin/3cpio and it's intended to be called as
"3cpio". This looks simple enough to me and I would be greatly
surprised if it had anything to do with the dracut failure (but of
course I may be wrong).

Thanks.

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

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

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

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

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

On Sat, 2026-01-24 at 17:33 +0100, Santiago Vila wrote:
> > > 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.
> > 

Oh, that code path is only taken when dracut is called with
--regenerate-all (plus --parallel). That is not the case in our case.

> > > 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?)
> 

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.

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

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.

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web