Package: libpam-modules Version: 1.1.8-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts
While on initial install there is a defined ordering between libpam-modules and libpam-runtime, these two packages may be upgraded in any order. I noticed this bug because piuparts complained on some stretch->buster upgrade paths that /var/lib/pam/seen was not matching the reference chroot. Looking in depth the "mkhomedir" entry was missing. This is the upgrade order for some libpam* packages, the first block is for creating the reference chroot, the second one for the actual test that failed: $ grep -E 'starting over|(Setting up|Unpacking) libpam' /tmp/pamlog.bad.log Unpacking libpam0g:amd64 (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam0g:amd64 (1.1.8-4) ... Unpacking libpam-modules-bin (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam-modules-bin (1.1.8-4) ... Unpacking libpam-modules:amd64 (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam-modules:amd64 (1.1.8-4) ... Unpacking libpam-runtime (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam-runtime (1.1.8-4) ... 1m19.2s INFO: Notice: package selections and meta data from target distro saved, now starting over from source distro. See the description of --save-end-meta and --end-meta to learn why this is neccessary and how to possibly avoid it. Unpacking libpam-runtime (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam-runtime (1.1.8-4) ... Unpacking libpam0g:amd64 (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam0g:amd64 (1.1.8-4) ... Unpacking libpam-modules-bin (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam-modules-bin (1.1.8-4) ... Unpacking libpam-modules:amd64 (1.1.8-4) over (1.1.8-3.6) ... Setting up libpam-modules:amd64 (1.1.8-4) ... So pam-auth-upgrade got called with all the old packages installed. Only thereafter libpam-modules got unpacked that brought a new pam-config: /usr/share/pam-configs/mkhomedir This may be harmless in this case (the new module is disabled by default), but in general libpam-modules should ensure that any updated configuration it delivers gets processed by pam-auth-update. One option would be to have libpam-runtime Depends: libpam-modules (>= ${source:Version}) but that would still allow partial upgrades of libpam-modules over an old libpam-runtime version (that does not get updated). Another option could be to add trigger support to libpam-runtime and have libpam-modules.postinst trigger libpam-runtime. The full log from the failing case is attached. The only difference between success and failure is the way the upgrade is performed, which changes the order of upgrading the packages: GOOD: apt-get dist-upgrade BAD: apt-get upgrade && apt-get dist-upgrade Andreas
pamlog.bad.log.gz
Description: application/gzip