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

[Luca Boccassi]

Control: tags -1 moreinfo

On Thu, 22 Aug 2024 15:28:08 +0200 Helmut Grohne <helmut at subdivi.de>
wrote:
> Package: systemd
> Severity: serious
> Justification: causes base-files.preinst to fail
> User: helmutg at debian.org
> Usertags: dep17
> Control: block 1077866 by -1
> X-Debbugs-Cc: jochensp at debian.org
> 
> Hi,
> 
> we're not 100% sure yet that this is systemd at cause, but it seems
so
> likely that I'm filing the bug here initially for further
investigation.
> 
> Jochen observed that an arm64 machine with dracut would have a /lib64
->
> usr/lib symbolic link. The presence of such a link makes
> base-files.preinst fail. debvm can be used to reproduce the problem:
> 
> $ debvm-create -- --architecture=arm64 --include=dracut
> # creates a ./rootfs.ext4
> $ debvm-run --append "rd.shell rd.break=pre-pivot"
> 
> That --append should drop you into a shell right before dracut does
> pivot_root and hands off to systemd. At that time, now /sysroot/lib64
> exists. Once the machine has booted /lib64 exists. At this time, the
> most plausible hypothesis is that systemd still creates it despite
> having been improved earlier.
> 
> Would you happen to know a good way to validate this hypothesis?
> 
> A possible approach could be enabling linux-level tracing and hooking
on
> the symlinkat syscall to see which processes issue it, but it could
be
> many. Any idea for narrowing down the component?
> 
> Thanks in advance
> 
> Helmut

Hi,

That's correct, as the dynamic loader is at /usr/lib/ld-linux-
aarch64.so.1 and the symlink will be created to the first directory
between /usr/lib64 and /usr/lib that exists and has the loader, in that
order.

So it seems to me either base-files needs to be able to deal with this,
or the loader should be symlinked in /usr/lib64 (like Fedora does)?