1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.RC

  • Bug#1079329: closed by Debian FTP Masters

    From Helmut Grohne@21:1/5 to All on Fri Mar 28 22:40:01 2025
    Control: reopen -1

    Hi Luca,

    I ran the reproducer from the initial bug submission against your -5
    upload and figured that /lib64 -> usr/lib would still be created. I am
    thus reopening the bug.

    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Antonio Terceiro@21:1/5 to Luca Boccassi on Wed Apr 2 20:00:02 2025
    On Wed, Apr 02, 2025 at 12:09:13PM +0100, Luca Boccassi wrote:
    On Wed, 2 Apr 2025 12:05:17 +0200 Helmut Grohne <[email protected]>
    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
    <[email protected]> (reply to Luca Boccassi <[email protected]>).

    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.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAmfteB8ACgkQ/A2xu81G C96kohAA30qSonLi1iMWGouMIxQI4VyanefgsSR+1SdJNL4KeYN5JDqA9cLvsPcy ySqIi9+mdypw2LxmNB1t+7ivjVDp0FY5DfAe1GDNrbUgAM61aZjon5W3MD8T47x8 sQMsaub4+2PPufO40tmw+tcrA0eJzrFH7oWsrq0qQrdR+EWypX1fZ7DegxsZPHl7 SuCHAd7wmDTO1F82OPMLCoBEi78WfK+HzMQL01SsrXfNo96yy8rvpRrhmfQn5g61 cjmx2lr951lJly+yMTnbku7Eh5epCXz/SQ0Rp85AjKc74CZl2SEJdAB2KLw6wQiM KqjsH3Y+6wdt4eoGwTHV0hQYfE6le+O9q6wEn4ZvrMW2Ib1oDbXuYp+xkxgj9QRB yDqt6fIi/xtmvuV+xocLOWFgPjJjK8jjs+ByrkTTVIazJuxUk+7HyHesGHGw0AO3 pKuxqPqPJAhiAu0z0ZFmX7NNAC3G0fzQE4gkwflp6rLhWDYDcNnydDBPYT9Ene89 ni7AC/RIV/YRstXLuuR7nDBrVJljiuNLg9Z8y3M/PwzPAuaxTc8gxgn8AKd3qWwj ZunOSIMTq9v+mvDkuAx7b+6nOXqybS4WWjl6viMsx91DgNwLF5NvUWwzbqTo46CM bGCjcM3G6U4YozYTU1MGmvJZjv+5pmGGfnJoBqPT70BM7+gialw=
    =6Bwa
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Antonio Terceiro@21:1/5 to Luca Boccassi on Wed Apr 2 22:10:02 2025
    On Wed, Apr 02, 2025 at 06:08:27PM +0000, Luca Boccassi wrote:
    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.

    Note that I am not part of the TC. My interest here is merely as an
    arm64 user. I'm just coming to this, and I don't yet have the full
    context.

    I understand that you just want to get rid of a problem, but making systemd-container an empty package on arm64 is throwing the baby way
    together with the bath water. I don't have a practical suggestion at the moment, nor a patch, but maybe there is a solution that can be achieved.
    And maybe someone can discover it.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAmftlmkACgkQ/A2xu81G C97nbg/+NqLQYP2Gctk7XgR31yxmzHEoqmMrl1EOsu4rTXaqf00/9B9tL4hj9MP8 KKpPB1O+3krkBCZ/0bDO/i92sv9KjqLS0lMnz83Gp68IBAngpcQJw7JKkgWGZanI kPoOPgG+YEon8+55PqoAV8xJ2u9XNiL8vAOAGB4q2waUFTgKGUa49Ze3iGnhX88X 7LH44MQKIJSNZjSmVSlFO9U0t2LYdCeIg0Rj0xp4JOExXw8qJDrl/pR8RPVdPqGD f0DbFh8kWC/zbpSZlqZ+hcgj4SDR18aMSTXsne3G+xPP4M8dHKCX6aqLWgUG3ADF gjez/2tid1emefldV1ecztxvMbObRxlOXHu9tpnZmm+X/uyKKN34IoknSAzMm6wn wCSiS5UwfSSyeqXsLHSypLhfb3a2QGrYW4o6kHwiUr3mrhVpDeD8eUXYqcw60Cus 0pQ5noyFsQyLzcjefhAUvQO0Pn8Xuepk5CCdYaKFTF0Py0BGLyOkzPH1hz2u+a9L M509g2y7Q3uYjSZOa9HEepECZ6XRVLaq5UgV6pP776XZ5NBGuQccs29fB+kIUpmz 3cbh+ILYeYNl2QbzkJI7f0EzuCekhgFtN3/ZnCzWevb7vGhKqKbdBNrrGihj8krZ yiGO8x8KT1iOzZW1yu+/9eIrr4WQiLFLuhwHuGTvYP5S80VQ3CU=
    =65wi
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Luca Boccassi on Thu Apr 3 22:40:01 2025
    On Wed, 2 Apr 2025 at 12:09, Luca Boccassi <[email protected]> wrote:
    Do you have other suggestions on how to best encode this? If not, I
    could perhaps add an AssertArchitecture=!arm64 to the initrd-only
    switchroot unit? That is a runtime setting so less ideal as the
    feedback is not immediate, but it would allow tinkerers to break the
    warranty seal, mask it and do strange things on the other hand, which
    is nicer.

    Gentle ping on this?

    Also I wanted to mention the alternative to fixup things immediately
    after creating them, I'd still be happy to maintain that instead, as a
    unit that runs before everything else or so. Of course it's up to you
    to tell me whether it's acceptable as a solution or not.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)