Control: severity -1 normal Hi!
On Mon, 2024-04-29 at 00:01:02 +0200, Chris Hofstaedtler wrote: > Control: reassign -1 dpkg > > * Vincent Lefevre <vinc...@vinc17.net> [240428 22:33]: > > Package: fdisk > > Version: 2.40-8 > > Severity: serious > ... > > Setting up util-linux (2.40-8) ... > > fstrim.service is a disabled or a static unit not running, not starting it. > > dpkg: error: dpkg frontend lock was locked by another process with pid 58569 > > Note: removing the lock file is always wrong, can damage the locked area > > and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. > > ====== How can you help? (doc: https://wiki.debian.org/how-can-i-help ) > > ====== > > > > ----- Show old opportunities as well as new ones: how-can-i-help --old > > ----- > > E: Sub-process /usr/bin/dpkg returned an error code (2) > > Setting up bsdextrautils (2.40-8) ... > > dpkg: dependency problems prevent configuration of fdisk: > > fdisk depends on libfdisk1 (= 2.40-8); however: > > Version of libfdisk1:amd64 on system is 2.40-6. > > > > dpkg: error processing package fdisk (--configure): > > dependency problems - leaving unconfigured > > Setting up eject (2.40-8) ... > > Setting up perl-modules-5.38 (5.38.2-4) ... > > Setting up mount (2.40-8) ... > > Setting up libperl5.38t64:amd64 (5.38.2-4) ... > > Setting up util-linux-extra (2.40-8) ... > > Setting up perl (5.38.2-4) ... > > Processing triggers for libc-bin (2.37-19) ... > > Processing triggers for man-db (2.12.1-1) ... > > Processing triggers for mailcap (3.70+nmu1) ... > > Errors were encountered while processing: > > fdisk > > > > There seem to be 2 issues: one with the dpkg lock (which may be > > bug 1069183 in aptitude) and one > Possible. I don't think dpkg is at fault here, I assume something else is either getting activated in the middle of the transaction while the package manager frontend driving dpkg has released the lock (which it should not), or the package manager frontend driving dpkg is performing the locking dance incorrectly. > > with fdisk. > > I see no evidence of that in the log. Right, it seems to me, like when dpkg fails due to the already held lock, then the frontend is not recomputing the transaction and keeps as if nothing had gone incorrectly, until it then notices later on. In any case, given that dpkg is not being very helpful in diagnosing this, I'll implement support to print the process name in addition to the pid, as this has also hit me, and it's never clear what was the actual culprit. So that's why I'm leaving this assigned to dpkg, but with a lower severity. If you'd like to file this elsewhere, then please clone and reassign that. Thanks, Guillem
