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)

[Antonio Terceiro]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250402/5bb64615/attachment-0001.sig>