Bug#1079329: systemd(?) still creates /lib64 on arm64

[Luca Boccassi]

On Thu, 10 Oct 2024 at 08:37, Helmut Grohne <helmut at subdivi.de> wrote:
>
> Hi Luca,
>
> On Wed, Oct 09, 2024 at 04:20:25PM +0100, Luca Boccassi wrote:
> > On Wed, 9 Oct 2024 at 15:35, Helmut Grohne <helmut at subdivi.de> wrote:
> > > On Wed, Oct 09, 2024 at 12:28:03PM +0100, Luca Boccassi wrote:
> > > > Yes that's the use case, just as you defined it. The problem is that
> > > > these links need to exist, and they need to be created at runtime in
> > > > an ephemeral root, and the target needs to be figured out <somehow>.
> > > > The best we have so far, that has been working fine over the years, is
> > > > to target it to where the loader is located. If you think there's a
> > > > better way, that works everywhere, please feel free to propose such a
> > > > change upstream, via a pull request ideally, or at least via an issue
> > > > (but please do note that PRs are better). In the end I think that's
> > > > the right place to discuss such details, rather than a downstream bug.
> > >
> > > Thanks for confirming. Please go ahead and remove the creation of /lib64
> > > from systemd then.
> >
> > Sorry, I do not follow. As mentioned, this cannot just be removed.
>
> You appeared to agree with my general description of the mechanism. You
> detailed that systemd needs to create these links when needed at
> runtime, but for arm64 there is no known nor documented need for /lib64,
> so I read that as you agreeing the /lib64 link on arm64 should be
> removed upstream. If you believe that it cannot be removed, please give
> details why you think so.

Sorry, but I am still not following. I do not understand, why would
lib64 not be needed? It's a 64bit architecture, no? If I download a
Fedora 40 aarch64 image from:

https://fedoraproject.org/server/download

and check the root directory, this is what I see:

total 16
dr-xr-xr-x.   2 root root    6 Jan 24  2024 afs
lrwxrwxrwx.   1 root root    7 Jan 24  2024 bin -> usr/bin
drwxr-xr-x.   2 root root    6 Apr 15 00:02 boot
drwxr-xr-x.   2 root root    6 Apr 15 00:02 dev
drwxr-xr-x. 121 root root 8192 Apr 15 00:26 etc
drwxr-xr-x.   2 root root    6 Jan 24  2024 home
lrwxrwxrwx.   1 root root    7 Jan 24  2024 lib -> usr/lib
lrwxrwxrwx.   1 root root    9 Jan 24  2024 lib64 -> usr/lib64
drwxr-xr-x.   2 root root    6 Jan 24  2024 media
drwxr-xr-x.   2 root root    6 Jan 24  2024 mnt
drwxr-xr-x.   2 root root    6 Jan 24  2024 opt
drwxr-xr-x.   2 root root    6 Apr 15 00:02 proc
dr-xr-x---.   3 root root  126 Apr 15 00:27 root
drwxr-xr-x.   2 root root    6 Apr 15 00:02 run
lrwxrwxrwx.   1 root root    8 Jan 24  2024 sbin -> usr/sbin
drwxr-xr-x.   2 root root    6 Jan 24  2024 srv
drwxr-xr-x.   2 root root    6 Apr 15 00:02 sys
drwxrwxrwt.   2 root root    6 Apr 15 00:02 tmp
drwxr-xr-x.  12 root root  144 Apr 15 00:03 usr
drwxr-xr-x.  20 root root 4096 Apr 15 00:12 var

> If you insist on cargo culting this code, there is another way. We know
> for a fact that in the hermetic-/usr case, there is no package manager
> on whose toes systemd could step. In particular, there is no
> /var/lib/dpkg. So systemd could simply check that location and skip
> bothering with aliasing links if it exists. Thus we would turn the
> broken code in systemd into dead code on Debian systems until you
> transform the installation hermetic and then it would return.

Thanks for the suggestion. This might not be necessarily the case
though, there can still be (and in fact there likely will) be a /var/
partition, even if / is a tmpfs. More importantly, I'm afraid this is
sort of debianism has no chance of being accepted upstream, sorry.