Bug#1079329: closed by Debian FTP Masters <ftpmaster at ftp-master.debian.org> (reply to Luca Boccassi <bluca at debian.org>) (Bug#1079329: fixed in systemd 257.4-6)

Luca Boccassi bluca at debian.org
Wed Apr 2 19:08:27 BST 2025


On Wed, 2 Apr 2025 at 18:47, Antonio Terceiro <terceiro at debian.org> wrote:
>
> On Wed, Apr 02, 2025 at 12:09:13PM +0100, Luca Boccassi wrote:
> > On Wed, 2 Apr 2025 12:05:17 +0200 Helmut Grohne <helmut at subdivi.de>
> > wrote:
> > > Control: reopen -1
> > >
> > > On Sat, Mar 29, 2025 at 01:39:02AM +0000, Debian Bug Tracking System
> > wrote:
> > > > It has been closed by Debian FTP Masters
> > <ftpmaster at ftp-master.debian.org> (reply to Luca Boccassi
> > <bluca at debian.org>).
> > >
> > > I'm saddened that rather than addressing the root cause, you declare
> > > incompatibility with other components that happen to expose the
> > faulty
> > > behavior.
> >
> > Sorry, but this is not a supported combination, and the intention was
> > to make that explicit, in the simplest way possible (ie, so that's it's
> > noticed at build time already).
> > The default initrd generator in Debian is initramfs-tools, that's fully
> > supported.
> >
> > If you wish to experiment with dracut, that's great! You can use it
> > with many init systems (or no init system at all). The particular
> > combination of arm64+dracut+systemd is known bad and unsupported, and
> > any one of those 3 factors can be swapped with something else to get a
> > working solution.
>
> I think you are talking past each other.
>
> This issue is not related to dracut at all. The issue is that when you
> start a systemd-nspwn container on arm64, /lib64 is created while it
> should not be. I assume that it would do the same on any system that is
> booted from a rootfs that contains only /usr.
>
> A simple reproducer is this:
>
> # ls -l /var/lib/lxc/autopkgtest-testing/rootfs/ | grep lib64
> # systemd-nspawn -D /var/lib/lxc/autopkgtest-testing/rootfs/ --console=pipe -- ls -l / | grep lib64
> lrwxrwxrwx   1 0 0    7 Apr  2 14:29 lib64 -> usr/lib
>
> (I used a lxc container rootfs that I have here, but the behavior will
> likely be the same with any rootfs).
>
> AIUI, /lib64 should no longer exist on Debian arm64 systems, or if it
> exists, it should point exactly at usr/lib64 (which no longer exists
> AFAICT). systemd, instead, is looking for the arm64 linker and
> symlinking /lib64 exactly at where it is found.
>
> This seems to be implemented in src/shared/base-filesystem.c. Now,
> whether or not to create /lib64, and where it should point to, depends
> on what OS is in the rootfs.  I'm not sure where to go from here.

Yes, essentially on arm64 the expectations of Debian/base-files and
systemd have diverged irremediably on this aspect, and should not be
mixed and matched anymore as it's way too costly to support, and that
includes nspawn+arm64 and dracut+systemd+arm64, and I've taken steps
to try and make sure it doesn't happen (as per your ruling: no
incompatible symlink shall be created), even though there are some
small gaps evidently, but I believe they can be filled.

The standard, default and common use cases such as booting with
initramfs-tools, or with vastly more popular container managers like
Docker or LXD or Podman are not affected and continue to work
correctly, to be clear.



More information about the Pkg-systemd-maintainers mailing list