On Thu, 10 Oct 2024 at 08:37, Helmut Grohne <hel...@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 <hel...@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.
