Re: [PLUG] Kernel autoremove works on Debian & Mint, not Ubuntu

[JP Vossen <jp@jpsdomain.org>]

>
https://askubuntu.com/questions/563483/why-doesnt-apt-get-autoremove-remove-my-old-kernels

Nope, that's not it.  I already found that one, and many similar links,
and that's how I found the general mechanism.  But as I said below
'/etc/kernel/postinst.d/apt-auto-removal' comes in 2 flavors, Debian and
UbMintu but in all cases generates a correct
'/etc/apt/apt.conf.d/01autoremove-kernels'.  It's also important to note
that '/etc/apt/apt.conf.d/01autoremove' is identical across all 3 distros!

I know who is doing it (Canonical/Ubuntu), and I know why they are doing
it, though I think it's totally wrong and misguided, since it works just
fine for Debian and Mint.  What I want to know is HOW Ubuntu is
overriding Debian, and/or how Mint is overriding Ubuntu's override.

Thanks for thinking about this though!

The other interesting note to Keith's point is that most of the "how do
I clean it up" stuff I've ever seen talks about manually running
something like `apt-get remove linux-image-3.13.0-4{3,4,5}-generic
linux-image-3.13.0-4{3,4,5}-generic`.  The "autoremove" advice is rare.

And as for space, I have some old machines that are limited, and/or I
have dedicated boot partitions that date back to before you could boot
certain LVM and/or mdadm configs (I forget the details).

I just run `ansible all -a 'bash -c "ls -l /boot/vmlinuz*"'` or `ansible
all -a 'apt-get autoremove --purge --dry-run'` and eyeball the results
and I've got one machine with 12 old kernels! :-(

But again, it's JUST Ubuntu and immediate family (Mythbuntu, Xubuntu)!
Debian and Mint Just Work, even though Ubuntu is built on Debian and
Mint is build on Ubuntu.


On 11/20/2015 11:00 AM, Rich Mingin (PLUG) wrote:
> While I am loathe to simply throw a link at a question, it looks like
> this was a decision made by Ubuntu (doubtlessly to protect users from
> themselves), and it's being affected by several configs. There's a lot
> of good and relevant info in the linked thread.
> 
> https://askubuntu.com/questions/563483/why-doesnt-apt-get-autoremove-remove-my-old-kernels



> On Fri, Nov 20, 2015 at 10:54 AM, Keith C. Perry
> <kperry@daotechnologies.com <mailto:kperry@daotechnologies.com>> wrote:
> 
>     This is a question I've always had too.  Granted grub now hides all
>     the older kernels but I've noticed this in Kubuntu was well.  Its
>     only through the release upgrade process that they seem to get purged.
> 
>     I never thought about the space concern- that's a good point so
>     thank you to pointing out the manual method to clean up but I would
>     also like to know why there isn't a more regular clean up process.
> 
>     Paging Dr. Fisher... Dr. Jim Fisher please come to room 103 for a
>     consult  :D


>     ----- Original Message -----
>     From: "JP Vossen" <jp@jpsdomain.org <mailto:jp@jpsdomain.org>>
>     To: "Philadelphia Linux User's Group Discussion List"
>     <plug@lists.phillylinux.org <mailto:plug@lists.phillylinux.org>>
>     Sent: Thursday, November 19, 2015 11:45:11 PM
>     Subject: [PLUG] Kernel autoremove works on Debian & Mint, not Ubuntu
> 
>     I've noticed that my Debian and Linux Mint 17 (based on Ubuntu 14.04)
>     autoremove all but the last 3 kernels, but my more "pure" Ubuntu
>     10.04/Mythbuntu 14.04 do not.  That's annoying since 2 of those machines
>     are old with small disks and they run out sometimes.
> 
>     tl;dr: I know how to hack around this but can't figure out WHY it's
>     happening, any clues?
> 
>     DETAILS:
>     Note I manually use `aptitude` on all of the nodes but these days do
>     most updates via Ansible(1.9.4)::Apt which can use either `apt-get` or
>     `aptitude` but which should be using `aptitude` since I'm calling it
>     like "apt: upgrade=full". [1]
> 
>     I can solve the problem by just running `apt-get autoremove --purge
>     --yes` but it's REALLY bugging me and I want to understand WHY this is
>     happening and not just hack around it.
> 
>     I thought the culprit was Ubuntu's '/etc/apt/apt.conf.d/05aptitude' but
>     after removing that file I still can't get `aptitude` to notice the
>     files it should automatically remove.  And out of 14 hosts, the 4
>     Ubuntu/Mythbuntu are a problem and only 3 had that file.  I also can't
>     figure out where that file is coming from, since the "aptitude" package
>     owns the file but the SAME package is on both:
> 
>     Ubuntu:
>     $ dpkg-query --search /etc/apt/apt.conf.d/05aptitude
>     aptitude: /etc/apt/apt.conf.d/05aptitude
> 
>     $ apt-cache policy aptitude
>     aptitude:
>       Installed: 0.6.8.2-1ubuntu4
>       Candidate: 0.6.8.2-1ubuntu4
>       Version table:
>      *** 0.6.8.2-1ubuntu4 0
>             500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64
>     Packages
>             100 /var/lib/dpkg/status
> 
>     $ apt-cache show aptitude | grep '^SHA256'
>     SHA256: 776d8f2314f5e1edef7fa06d5cbc1184a8a11d90b9fb35caa626032607a525bd
> 
>     Mint:
>     $ dpkg-query --search /etc/apt/apt.conf.d/05aptitude
>     dpkg-query: no path found matching pattern
>     /etc/apt/apt.conf.d/05aptitude
> 
>     $ apt-cache policy aptitude
>     aptitude:
>       Installed: 0.6.8.2-1ubuntu4
>       Candidate: 0.6.8.2-1ubuntu4
>       Version table:
>      *** 0.6.8.2-1ubuntu4 0
>             500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
>             100 /var/lib/dpkg/status
> 
>     $ apt-cache show aptitude | grep '^SHA256'
>     SHA256: 776d8f2314f5e1edef7fa06d5cbc1184a8a11d90b9fb35caa626032607a525bd
> 
>     So how can one package only sometimes install a file?  Now, I know Mint
>     does some ugly hacks (like re-writing /etc/motd which causes lots of
>     "file locally modified" errors during updates), but I can't find one for
>     this:
>     # grep -Ri '05aptitude' /etc/linuxmint/* /usr/lib/linuxmint/*
> 
> 
>     Next, '/etc/kernel/postinst.d/apt-auto-removal' comes in 2 flavors,
>     Debian and UbMintu but in all cases generates a correct
>     '/etc/apt/apt.conf.d/01autoremove-kernels'.  There is a single 3
>     character difference between the files, but that does not seem to be the
>     problem.  Line 44 has:
>             Deb: image-[0-9]+\./
>             UbM: image-[0-9]/
> 
>     '/etc/apt/apt.conf.d/01autoremove' is identical across all 3 distros.
> 
>     But again, in all cases the generated
>     '/etc/apt/apt.conf.d/01autoremove-kernels' file is correct and keeps
>     only the last 2-3 kernels.  Yet old kernels not matching the file are
>     correctly removed on Debian and Mint but *not* on Ubuntu machines.
> 
>     Also, on an affected machine `apt-get` will trigger a warning about "The
>     following packages were automatically installed and are no longer
>     required" but `aptitude` will not.  Yet I don't have this problem on the
>     Debian and Mint boxes and I am using `aptitude` there too.
> 
>     I've diffed the entire '/etc/apt/' dirs from Mint and Ubuntu and none of
>     the trivial differences popped out at me.
> 
>     What the heck am I missing?
>     JP
> 
>     [1] Search for "aptitude" in
>     http://docs.ansible.com/ansible/apt_module.html

----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug