Control: tags -1 moreinfo On Thu, 22 Aug 2024 15:28:08 +0200 Helmut Grohne <hel...@subdivi.de> wrote: > Package: systemd > Severity: serious > Justification: causes base-files.preinst to fail > User: helm...@debian.org > Usertags: dep17 > Control: block 1077866 by -1 > X-Debbugs-Cc: joche...@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)?
