Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
On Tue, 11 Jun 2024 at 00:15, Chad William Seys wrote: > > Hmm, was there a cleanup or migration script which failed to run? > > On 6/8/24 09:30, Paul Slootman wrote: > > On Tue, 23 May 2023 09:06:31 -0500 C Seys wrote: > > > >> After upgrading to bookworm there is an unowned /usr/bin/ps on the > >> filesystem: > >> > >> # dpkg -S /usr/bin/ps > >> dpkg-query: no path found matching pattern /usr/bin/ps > >> > >> There is also /bin/ps owned by procps: > >> > >> # dpkg -S /bin/ps > >> procps: /bin/ps > > > > I suspect that /bin is now a symlink to /usr/bin . > > So the /usr/bin/ps you see was installed as /bin/ps You probably need to check that symlink first. There was one or two versions where ps was in the wrong place and a cleanup script that (supposedly) fixed that. It's a bit of a corner-case because you have to had an update at specific times to trigger it. My (and probably the majority of peoples) setup is like this: $ ls -l /bin/ps -rwxr-xr-x 1 root root 150456 Jan 28 21:15 /bin/ps $ ls -l /bin lrwxrwxrwx 1 root root 7 Oct 28 2022 /bin -> usr/bin $ realpath /bin/ps /usr/bin/ps Or in other words, /bin is symlink to /usr/bin and /bin/ps is not a real file. So the trick here is to work out what you have here first. I'm also curious why you're at version 4.0.3-1 Bookworm is 4.0.2-3 and Trixie/Sid at 4.0.4-4; upgrading to the latest might clear this issue. 4.0.4-4 has a /usr/bin/ps because of the usrmerge/DEP-17 transistion. - Craig
Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
Hmm, was there a cleanup or migration script which failed to run? On 6/8/24 09:30, Paul Slootman wrote: On Tue, 23 May 2023 09:06:31 -0500 C Seys wrote: After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem: # dpkg -S /usr/bin/ps dpkg-query: no path found matching pattern /usr/bin/ps There is also /bin/ps owned by procps: # dpkg -S /bin/ps procps: /bin/ps I suspect that /bin is now a symlink to /usr/bin . So the /usr/bin/ps you see was installed as /bin/ps Regards, Paul
Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
On Tue, 23 May 2023 09:06:31 -0500 C Seys wrote: > After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem: > > # dpkg -S /usr/bin/ps > dpkg-query: no path found matching pattern /usr/bin/ps > > There is also /bin/ps owned by procps: > > # dpkg -S /bin/ps > procps: /bin/ps I suspect that /bin is now a symlink to /usr/bin . So the /usr/bin/ps you see was installed as /bin/ps Regards, Paul
Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
Package: procps Version: 2:4.0.3-1 Severity: normal Dear Maintainer, After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem: # dpkg -S /usr/bin/ps dpkg-query: no path found matching pattern /usr/bin/ps There is also /bin/ps owned by procps: # dpkg -S /bin/ps procps: /bin/ps I wasn't able to find a /usr/bin/ps in on non-upgraded versions of Debian (only /bin/ps). Thanks for your efforts! C. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.65.2 ii libc62.36-9 ii libncursesw6 6.4-4 ii libproc2-0 2:4.0.3-1 ii libtinfo66.4-4 Versions of packages procps recommends: ii psmisc 23.6-1 procps suggests no packages. -- no debconf information
