4

While doing other maintenance tasks I noticed that dpkg -l listed about 90 packages with status ri instead of expected ii.

I maintain packages solely with apt and aptitude and I haven't forced any packages but I regulary do apt install --no-install-recommends ... to avoid getting unneeded packages. I also try to carefully maintain the "automatically installed" flags and I have 2914 packages with status "automatically installed" (aptitude search '~i~M') and 422 packages with status "manually installed" (aptitude search '~i!~M').

What could be the reason for packages to have status Remove + Inst (ri) in dpkg -l listing when I haven't requested those packages to be removed? It seemed that the packages with this status were packages that I actually want to keep in the system. Could e.g. sudo apt dist-upgrade cause this without me noticing?

(I know that I can reinstall those packages with apt install --reinstall package-name to get status back to ii. I also often purge removed packages and aptitude search '~c' lists no packages.)

Additional details from another system with the same issue:

$ sudo apt dist-upgrade && sudo apt autoremove && dpkg -l | grep ^ri | wc -l
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  virtualbox-6.0
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
171

So dist-upgrade nor autoremove do not touch the 171 packages with ri status.

Example package with ri status:

$ dpkg -l ca-certificates-java
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                            Version                      Architecture                 Description
+++-===============================================-============================-============================-===================================================================================================
ri  ca-certificates-java                            20160321ubuntu1              all                          Common CA certificates (JKS keystore)

and additional info for the same package:

$ aptitude show ca-certificates-java
Package: ca-certificates-java            
State: installed
Automatically installed: no
Multi-Arch: foreign
Version: ...

$ aptitude why ca-certificates-java 
i   default-jre-headless   Depends openjdk-8-jre-headless
iBA openjdk-8-jre-headless Depends ca-certificates-java


$ apt-mark showhold
virtualbox-6.0

Additional info after reading about possible causes:

As explained in answer https://askubuntu.com/a/802612/50254 the status of these packages can be fixed to match currently installed packages by running (note that the line feed after IFS is not a typo but this command requires setting IFS to single linefeed):

export IFS='
'
for i in $(dpkg -l |egrep '^[a-z]i.*' |awk '{print $2" install"}') ; do echo $i|dpkg --set-selections  ; done
unset IFS

The reason/cause for this problem is still unknown. The ri status is supposed to mean that dselect (old debian package manager nowadays completely replaced by apt) has used to mark package to be removed from the system and if you actually want to apply those selection states you can run apt-get dselect-upgrade. See man dpkg and section "INFORMATION ABOUT PACKAGES" for more information.

The apt install --reinstall package-name is also okay but it will do more than the minimum change to system to fix the problem.

Mikko Rantalainen
  • 3,360
  • I'm not 100% sure, but it sound to me that the packages marked with ri could have been a dependent of another package that was removed but they weren't removed as maybe the --autoremove switch for apt wasn't used. But I don't recommend using --autoremove as you may remove other needed packages. I wish that part of package management was perfect, but it's not. I have accidentally killed systems because an app set them all for autoremove. – Terrance Jul 16 '21 at 12:50
  • That was a good suggestion but it wasn't the cause. I added info how neither dist-upgrade nor autoremove do anything to these packages. – Mikko Rantalainen Jul 16 '21 at 13:06
  • 1
    Hmmmmm, yeah, sorry, I am out of suggestions on this one. +1 and hopefully someone else has stumbled across this. Running dpkg -l | grep -w "ri" yields nothing on my system, but dpkg -l | grep -w "rc" does, but thats for config and a completely different scenario. I hope you find an answer! – Terrance Jul 16 '21 at 13:13
  • 1
    I have been looking a little deeper into your situation and while I am really not finding any solid answers for what is actually causing this, maybe some clues to be able to remedy might be found in https://askubuntu.com/posts/1352232/edit , https://askubuntu.com/a/165961/231142 and https://askubuntu.com/a/166254/231142 – Terrance Jul 16 '21 at 14:29
  • @Terrance: It seems that the packages marked ri match this list: dpkg --get-selections | awk '$2 == "deinstall" {print $1}'. So the question is what process could accidentally mark deinstall for dselect when I don't use dselect for anything? – Mikko Rantalainen Jul 17 '21 at 14:34
  • Oops, I just realized that in my above comment the first link is one that was in my buffer. My bad. Let me see if I can find the correct link there. It had some decent info in it. – Terrance Jul 17 '21 at 14:38
  • Unfortunately, I don't know what exactly is causing it. I guess you can look through the logs in /var/log/dpkg.log or maybe something like journalctl -xe. I really wish I was experiencing the same issue as it would really help to have a second pair of eyes. Another link that I did find was where the --clear-selections was ran and caused something similar. It is hard to say if this might have been ran either. https://askubuntu.com/questions/687272/revert-accidental-dpkg-clear-selections?rq=1 – Terrance Jul 17 '21 at 14:51
  • 1
    Yeah, I did read about dpkg --clear-selections, too, but I definitely haven't run that. And I'll not run that after reading what it does. I did also find that deinstall is historically used to signal dpkg by dselect that a package should be removed. However, I just checked and I don't even have dselect installed so that shouldn't be setting incorrect flags. Very interesting problem indeed. My current guess would be that VirtualBox package has executed some wrong commands because both these systems have VirtualBox installed and this problem seems to be pretty rare in general. – Mikko Rantalainen Jul 17 '21 at 14:58
  • I also checked journalctl and it doesn't mention the problematic package during the last 1.5 years I've logs available. The system was installed about 11 months earlier so the error must have happened at that time or whatever causes this doesn't not log to journalctl at all. – Mikko Rantalainen Jul 17 '21 at 15:16

1 Answers1

2

disclaimer: i'm not a pro when it comes to distributions, so these are just my guesses by putting 1 and 1 multiple times together.

prologue

on an older Ubuntu machine i have one package with status ri, which is libllvm5.0 (and a bunch of other normal ii-packages like libllvm4.0 and libllvm6.0). the packages <= libllvm5.0 are marked as manually installed but libllvm6.0 is marked as automatically installed.
so my guess would be, that it was a dependency and got obsolete ether by upgrading or removing the dependent package.

explanation

going through your arguments/conditions one by one:

  • i only use --no-install-recommends:
    well, needed dependencies are installed nevertheless, else the program wouldn't work.
  • autoremove does nothing to these packages:
    well, kind of... i'm pretty sure all the ri-packages left alone by autoremove are marked as manually installed, although you have never installed it "separately". this is because after an initial setup a very few (if any?) packages are marked as automatically installed due to the fact that it isn't really possible to determine what packages you would have installed intentionally because this would vary from user to user. (so... a kind of "you have manually installed your OS".)
  • could sudo apt dist-upgrade cause this?:
    no and yes... sudo apt dist-upgrade on itself does not cause this, but with upgrading the whole system it is much more likely, that a bunch of (initially installed) packages will get obsolete.

to wrap up THE REASON: my guess would be that that these packages were installed by the initial setup, therefore marked as manually installed and then got obsolete by upgrading some packages or the whole distribution. and because they are marked as manually installed, they aren't touched by autoremove.

DJCrashdummy
  • 1,911
  • This sounds reasonable explanation. All the packages having status ri also have status Automatically installed: no when queried with aptitude show packagename. However, I'd expect all manually installed packages to always stay in ii status instead of getting marked for removal with ri status. – Mikko Rantalainen Jul 21 '21 at 17:54
  • @MikkoRantalainen: why do you expect this? or differently phrased: why should the package management be dumbed down? || the r just shows the "desired" status on behalf of dpkg, which only indicates, that there is no more package via dpkg installed, which depends on the package in question. - as the "manually installed" flag overrides these suggestions, because no package management can guess if sideloaded programs or some of your scripts still depend on this package, it won't do anything to this package. – DJCrashdummy Mar 28 '24 at 09:59
  • so the result is: if a package was installed as a dependency resp. is marked as "automatically installed", it also gets automatically uninstalled (via autoremove and depending on your setting for "recommendations" and "suggestions") as soon as no other package depends on it. - is a package marked as "manually installed", the r is just a suggestion from dpkg considering its packages, but you have to decide ("manually" again), what to do with it. so if you do nothing, the system stays as it is to not break anything. – DJCrashdummy Mar 28 '24 at 10:04
  • and if you know what you are doing, and you installed the package on purpose because you needed it for a script or similar but this is no longer the case, the r indicates that you can safely remove it (not considering other dependencies outside of dpkg)... and if it shows ii you can still simply mark this package as "automatically installed" and the package manager takes care of the rest... no need to be bothered with dependencies or monitor this package regularly. – DJCrashdummy Mar 28 '24 at 10:11
  • As I explained in the question, the packages with ri status did not get removed with apt dist-upgrade nor apt autoremove. What's the purpose of the r if it doesn't even affect those commands? – Mikko Rantalainen Mar 28 '24 at 14:41
  • @MikkoRantalainen: why should they get removed with any of these commands, since you have also confirmed they have the status "manually installed"? it would still break something else outside of dpkg depending on these packages. - as long as they are marked as "manually installed", they won't be automatically unistalled. || the r indicates that no other package managed via dpkg depends on it, and thus dpkg suggests to remove it. if it is marked as "automatically installed", this suggestion is followed, if not then not. – DJCrashdummy Mar 28 '24 at 15:14
  • I have packets that are marked as automatically installed and have ri status. Is it safe to assume that the reason those are not uninstalled by dist-upgrade or autoremove is some other package has the package as Recommends or Suggests? That would then prevent the system from automatically removing those packages even if nothing depends on them? – Mikko Rantalainen Mar 28 '24 at 16:01
  • 1
    @MikkoRantalainen: at first i would have a look at the settings: apt-config dump | grep -E -i -e 'APT::(Install|AutoRemove).*' and even apt-config dump | grep -E -i -e 'APT::Never.*' could be interesting in some cases. but i guess https://unix.stackexchange.com/a/544878/93768 should answer your question. – DJCrashdummy Mar 30 '24 at 06:47
  • Thanks! So r in ri means that the package could be uninstalled because nothing is depending on it but apt will not uninstall it if it's Recommended by some package that's still installed for any reason (included chain of Recommended packages from one installed package). – Mikko Rantalainen Mar 31 '24 at 21:39