Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
On Thu, 2024-02-29 at 13:31 -0700, Sam Hartman wrote: > > > > > > I tried to make the revert work either if you didn't have libpam0t64 > at > all or if you did, but we're more focused on people who never > upgraded. > > If you do run into breakage, we'll work with you to find a solution. I guess right now going back isn't anyway possible yet, as e.g. util- linux and some others have already depended on the t64 package, and't I'd assume those haven't been rebuilt yet with the reversion. Means however also, that possibly more and more people (on unstable) get the libpam0t64 installed, unless they completely wait until the transition is over. Cheers, Chris.
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
> "Christoph" == Christoph Anton Mitterer writes: Christoph> Do you happen to know whether there's anything needed in Christoph> terms of clean up for people who had already upgraded Christoph> now? Like manually doing whatever was done via the Christoph> runuser? I think that so long as libpam0g 1.5.3-5 installs cleanly, it will be fine. I think that the runuser is from debian-security-support and is run on every upgrade, so you should be good there. I tried to make the revert work either if you didn't have libpam0t64 at all or if you did, but we're more focused on people who never upgraded. If you do run into breakage, we'll work with you to find a solution. --Sam
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
On Thu, 2024-02-29 at 08:14 +0100, Helmut Grohne wrote: > Can you locate a more complete upgrade log? Attached is the excerpt from APT's term.log, if that helps. Cheers, Chris. term.log.xz Description: application/xz
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
On Thu, 2024-02-29 at 08:50 -0700, Sam Hartman wrote: > > > > > > Steve and I agreed to revert the rename on IRC, effectively > accepting > the ABI break because it doesn't matter for the archive. > We may look at better solutions when we have a bit of time. Do you happen to know whether there's anything needed in terms of clean up for people who had already upgraded now? Like manually doing whatever was done via the runuser? >From the log it looked to me as this would have happened during removal of libpam0g, that doesn't call it (at least no directly). Cheers, Chris.
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
> "Helmut" == Helmut Grohne writes: Helmut> I believe pam will have to be reverted and implemented as Helmut> dual ABI instead. I'm not very comfortable with this approach. The tentative patch did not fill me with confidence; my gut is that it was not as robust as an approach that libraries like libc6 took, and unfortunately I do not have enough experience with the internals of libc6 and various multi-ABI approaches across the years to have confidence either way. I could use some help from someone who has approached this sort of issue and deployed changes like this in production. Steve and I agreed to revert the rename on IRC, effectively accepting the ABI break because it doesn't matter for the archive. We may look at better solutions when we have a bit of time. --Sam signature.asc Description: PGP signature
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
On Thu, Feb 29, 2024 at 08:14:30AM +0100, Helmut Grohne wrote: > Ideally, we'd get a reproducer using > >mmdebstrap SOMERELEASE /dev/null --variant=apt --include=SOMEPACKAGES > --customize-hook='echo SOURCES_LIST_LINE > "$1/etc/apt/sources.list"' > --chrooted-customize-hook="apt-get update" > --chrooted-customize-hook="aptitude dist-upgrade" mmdebstrap trixie /dev/null --variant=apt --include debian-security-support --customize-hook='sed -i -e s/trixie/sid/ "$1/etc/apt/sources.list"' --chrooted-customize-hook="apt-get update && apt-get install debian-security-support libpam0t64" debian-security-support installs a dpkg.cfg.d snipped that configures a post-invoke action which calls out to runuser. I think what it does is policy-compliant. > Technically speaking, I believe this is a Debian policy 3.8 violation. > runuser is essential and removing libpam0g causes runuser to no longer > work. I'm tentatively upgrading severity hoping that we don't get into a > severity pingpong. Julian Andres Klode also thinks that it is likely to > affect apt. Yes, it does affect apt as we can see above. While the consequences are not really fatal in this case, we still have an essential runuser that happens to not work briefly. I believe pam will have to be reverted and implemented as dual ABI instead. And I really expect the same to hold for libtirpc. We just haven't seen the user reports for that yet as it hasn't built. Helmut
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
Control: severity -1 serious On Thu, Feb 29, 2024 at 02:36:12AM +0100, Christoph Anton Mitterer wrote: > During upgrade to 1.5.3-4 I got: > Removing libpam0g:amd64 (1.5.2-9.1+b1) ... > runuser: error while loading shared libraries: libpam.so.0: cannot open > shared object file: No such file or directory > > Guess there may be some timing issue, when libpam0g is already gone > but hasn't been replaced by libpam0t64 yet? > > That happened only a bit later: > … > Unpacking libpam0t64:amd64 (1.5.3-4) ... > Setting up libpam0t64:amd64 (1.5.3-4) ... >From what you write here, it is difficult to reproduce the problem. A minimal upgrade does not reproduce this. Given that apt and aptitude use the very same solver, it is very likely that this is not an aptitude-specific problem. Can you locate a more complete upgrade log? Ideally, we'd get a reproducer using mmdebstrap SOMERELEASE /dev/null --variant=apt --include=SOMEPACKAGES --customize-hook='echo SOURCES_LIST_LINE > "$1/etc/apt/sources.list"' --chrooted-customize-hook="apt-get update" --chrooted-customize-hook="aptitude dist-upgrade" Technically speaking, I believe this is a Debian policy 3.8 violation. runuser is essential and removing libpam0g causes runuser to no longer work. I'm tentatively upgrading severity hoping that we don't get into a severity pingpong. Julian Andres Klode also thinks that it is likely to affect apt. I very much think that we're in the same spot as with libselinux here and really need to revert the pam one and replace it with ABI duality just like we will be doing with libselinux. Helmut
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
Source: pam Version: 1.5.3-4 Severity: normal Hey. During upgrade to 1.5.3-4 I got: Removing libpam0g:amd64 (1.5.2-9.1+b1) ... runuser: error while loading shared libraries: libpam.so.0: cannot open shared object file: No such file or directory Guess there may be some timing issue, when libpam0g is already gone but hasn't been replaced by libpam0t64 yet? That happened only a bit later: … Unpacking libpam0t64:amd64 (1.5.3-4) ... Setting up libpam0t64:amd64 (1.5.3-4) ... Thanks, Chris. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
