| Keith C. Perry on 20 Nov 2015 10:56:56 -0800 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] Kernel autoremove works on Debian & Mint, not Ubuntu |
Ok on your systems.
As for me, once I moved to new hardware my Slackware partition stopped booting. Not sure why and I haven't had time to dig into it (CPU errors while booting which doesn't make sense because the CPU optimizations are way old but I'll just dumb it down and recompile at some point- it should not affect grub configs in my opinion).
Thanks for the suggestion.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.
Owner, DAO Technologies LLC
(O) +1.215.525.4165 x2033
(M) +1.215.432.5167
www.daotechnologies.com
----- Original Message -----
From: "JP Vossen" <jp@jpsdomain.org>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Friday, November 20, 2015 12:50:35 PM
Subject: Re: [PLUG] Kernel autoremove works on Debian & Mint, not Ubuntu
Nope, mine are all single OS installs, I put other stuff in VMs.
The list below looks OK to me, so I assume you mean that some of those
kernels should not be removed because Slackware wants them? You may be
able to fiddle with your Kubuntu
'/etc/kernel/postinst.d/apt-auto-removal' file to add those to the
'/etc/apt/apt.conf.d/01autoremove-kernels' file, or edit that latter
file manually (but it will get nuked and re-created).
On 11/20/2015 12:31 PM, Keith C. Perry wrote:
> Ok so I just ran "apt-get autoremove --purge" and got this...
>
> ~ ~ ~
>
> apt-get autoremove --purge
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be REMOVED:
> linux-headers-3.13.0-29* linux-headers-3.13.0-29-generic*
> linux-headers-3.13.0-37* linux-headers-3.13.0-37-generic*
> linux-headers-3.13.0-39* linux-headers-3.13.0-39-generic*
> linux-headers-3.13.0-45* linux-headers-3.13.0-45-generic*
> linux-headers-3.13.0-53* linux-headers-3.13.0-53-generic*
> linux-headers-3.13.0-57* linux-headers-3.13.0-57-generic*
> linux-headers-3.13.0-61* linux-headers-3.13.0-61-generic*
> linux-headers-3.13.0-65* linux-headers-3.13.0-65-generic*
> linux-headers-3.13.0-66* linux-headers-3.13.0-66-generic*
> linux-image-3.13.0-29-generic* linux-image-3.13.0-37-generic*
> linux-image-3.13.0-39-generic* linux-image-3.13.0-45-generic*
> linux-image-3.13.0-53-generic* linux-image-3.13.0-57-generic*
> linux-image-3.13.0-61-generic* linux-image-3.13.0-65-generic*
> linux-image-3.13.0-66-generic* linux-image-extra-3.13.0-29-generic*
> linux-image-extra-3.13.0-37-generic* linux-image-extra-3.13.0-39-generic*
> linux-image-extra-3.13.0-45-generic* linux-image-extra-3.13.0-53-generic*
> linux-image-extra-3.13.0-57-generic* linux-image-extra-3.13.0-61-generic*
> linux-image-extra-3.13.0-65-generic* linux-image-extra-3.13.0-66-generic*
> 0 upgraded, 0 newly installed, 36 to remove and 2 not upgraded.
> After this operation, 2,438 MB disk space will be freed.
> Do you want to continue? [Y/n]
>
> ~ ~ ~
>
> So apparently Kubuntu knows that there is something to be purged but my Slackware partition is causing a problem with grub rewriting the grub config file so it actually doesn't effectively purge all the old kernels for me.
>
> So out of curiousity JP, are there any other non-Ubuntu partitions on that Ubuntu system?
>
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> Keith C. Perry, MS E.E.
> Owner, DAO Technologies LLC
> (O) +1.215.525.4165 x2033
> (M) +1.215.432.5167
> www.daotechnologies.com
>
> ----- Original Message -----
> From: "JP Vossen" <jp@jpsdomain.org>
> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
> Sent: Friday, November 20, 2015 12:16:15 PM
> Subject: Re: [PLUG] Kernel autoremove works on Debian & Mint, not Ubuntu
>
>>
> 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
___________________________________________________________________________
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