Public bug reported:
[Impact]
All `arm64` CPC livefs builds fail during `lb build` as `dpkg` can't
configure the `flash-kernel` and `linux-image` packages
```
Setting up flash-kernel (...) ...
coreutils: unknown program 'flash-kernel'
dpkg: error processing package flash-kernel (--configure):
old flash-kernel package postinst maintainer script subprocess failed ...
[...]
/etc/kernel/postinst.d/zz-flash-kernel:
coreutils: unknown program 'flash-kernel'
run-parts: /etc/kernel/postinst.d/zz-flash-kernel exited with return code 1
dpkg: error processing package linux-image-7.0.0-14-generic (--configure):
[...]
Errors were encountered while processing:
flash-kernel
linux-image-7.0.0-14-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
(FWIW `amd64` is unaffected as `flash-kernel` is arm64 specific)
[Root cause]
During the chroot stage, live-build (scripts/build/chroot_dpkg) disables
a few commands by diverting the real binary and symlinking the command
name to `/bin/true`:
```
ln -fs /bin/true chroot/usr/sbin/start-stop-daemon
ln -fs /bin/true chroot/usr/sbin/flash-kernel
```
This all relied on GNU coreutils shipping each utility as a standalone binary
though, where `true` ignores `argv[0]` and always exits 0, so a symlink of any
name to
`/bin/true` basically acts as a no op.
Since stonking switched the default coreutils to the Rust uutils
implementation, `/bin/true` is a `busybox-style` multicall binary that
dispatches on `argv[0]` now. Under another name it does not fall back to
`true`, it prints `coreutils: unknown program '<name>'` and exits 1. The
diverted `flash-kernel` therefore fails instead of just silently
succeeding, which then aborts the flash-kernel and linux-image scripts.
Technically this is expected multicall behaviour, and not a bug in
uutils. The "bad" assumption is the `ln -s /bin/true` in `live-build`.
[Workaround]
Add a `chroot_early` hook that rewrites `live-build`'s `/bin/true`
placeholder symlinks for `start-stop-daemon` and `flash-kernel` into a
real no op script (#!/bin/sh; exit 0) so the behaviour doesn't depend on
`argv[0]`. The hook only touches symlinks that actually point at
`/bin/true`, so this is safe and can stay around even after `live-build`
itself gets a fix.
[Proper `live-build` fix (?)]
The real fix belongs in `live-build`'s `scripts/build/chroot_dpkg`. We
need to replace the `ln -fs /bin/true` diversions with a `#!/bin/sh;
exit 0` wrapper. I'll raise a separate bug against live-build (this
`livecd-rootfs` change is a workaround to unblock arm64 image builds for
now).
[Test case]
Minimal reproducer on a stonking system (where `/bin/true` is the
`uutils` binary):
```
$ ln -s /bin/true /tmp/flash-kernel
$ /tmp/flash-kernel; echo "exit=$?"
coreutils: unknown program 'flash-kernel'
exit=1
```
(In GNU coreutils the same command prints nothing/gives exit=0)
** Affects: livecd-rootfs (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
[Impact]
All `arm64` CPC livefs builds fail during `lb build` as `dpkg` can't
configure the `flash-kernel` and `linux-image` packages
```
Setting up flash-kernel (...) ...
coreutils: unknown program 'flash-kernel'
dpkg: error processing package flash-kernel (--configure):
old flash-kernel package postinst maintainer script subprocess failed ...
[...]
/etc/kernel/postinst.d/zz-flash-kernel:
coreutils: unknown program 'flash-kernel'
run-parts: /etc/kernel/postinst.d/zz-flash-kernel exited with return code 1
dpkg: error processing package linux-image-7.0.0-14-generic (--configure):
[...]
Errors were encountered while processing:
- flash-kernel
- linux-image-7.0.0-14-generic
+ flash-kernel
+ linux-image-7.0.0-14-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
(FWIW `amd64` is unaffected as `flash-kernel` is arm64 specific)
[Root cause]
During the chroot stage, live-build (scripts/build/chroot_dpkg) disables
a few commands by diverting the real binary and symlinking the command
name to `/bin/true`:
```
ln -fs /bin/true chroot/usr/sbin/start-stop-daemon
ln -fs /bin/true chroot/usr/sbin/flash-kernel
```
This all relied on GNU coreutils shipping each utility as a standalone binary
though, where `true` ignores `argv[0]` and always exits 0, so a symlink of any
name to
`/bin/true` basically acts as a no op.
Since stonking switched the default coreutils to the Rust uutils
implementation, `/bin/true` is a `busybox-style` multicall binary that
dispatches on `argv[0]` now. Under another name it does not fall back to
`true`, it prints `coreutils: unknown program '<name>'` and exits 1. The
diverted `flash-kernel` therefore fails instead of just silently
succeeding, which then aborts the flash-kernel and linux-image scripts.
Technically this is expected multicall behaviour, and not a bug in
uutils. The "bad" assumption is the `ln -s /bin/true` in `live-build`.
[Workaround]
Add a `chroot_early` hook that rewrites `live-build`'s `/bin/true`
placeholder symlinks for `start-stop-daemon` and `flash-kernel` into a
real no op script (#!/bin/sh; exit 0) so the behaviour doesn't depend on
`argv[0]`. The hook only touches symlinks that actually point at
`/bin/true`, so this is safe and can stay around even after `live-build`
itself gets a fix.
[Proper `live-build` fix (?)]
The real fix belongs in `live-build`'s `scripts/build/chroot_dpkg`. We
need to replace the `ln -fs /bin/true` diversions with a `#!/bin/sh;
exit 0` wrapper. I'll raise a separate bug against live-build (this
`livecd-rootfs` change is a workaround to unblock arm64 image builds for
now).
-
--------------------------------------------------------------------------------
-
[Test case]
Minimal reproducer on a stonking system (where `/bin/true` is the
`uutils` binary):
```
$ ln -s /bin/true /tmp/flash-kernel
$ /tmp/flash-kernel; echo "exit=$?"
coreutils: unknown program 'flash-kernel'
exit=1
```
(In GNU coreutils the same command prints nothing/gives exit=0)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161656
Title:
`arm64` livefs builds fail with a flash-kernel and linux-image
configuration error (`coreutils: unknown program 'flash-kernel'`)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2161656/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
