On Wed, 2 Apr 2025 at 18:47, Antonio Terceiro <terce...@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 <hel...@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 > > <ftpmas...@ftp-master.debian.org> (reply to Luca Boccassi > > <bl...@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.
