On Tue, 11 Jun 2024 at 00:15, Chad William Seys <cws...@physics.wisc.edu> 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 <cws...@physics.wisc.edu> 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
