. . . I have in my /boot directory four kernels -- the running one (5.4.0-80) -- and some rather hoary ones: 4.4.0-124, 3.13.0-147, and 3.13.0-126. i do not currently have nor do I imagine ever having need for the last three. Thought I'd get rid of 'em, but they do not show up in Ubuntu Cleaner or anything else capable of sending them to the bit bucket.
So. Anybody know any reason I'd want to keep them and, absent such a reason, anybody know a quick and complete way of deleting them? Used to be they'd always at least show up in Synaptic, but not this time. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Friday 06 August 2021 04:24:25 pm dep wrote:
. . . I have in my /boot directory four kernels -- the running one (5.4.0-80) -- and some rather hoary ones: 4.4.0-124, 3.13.0-147, and 3.13.0-126. i do not currently have nor do I imagine ever having need for the last three. Thought I'd get rid of 'em, but they do not show up in Ubuntu Cleaner or anything else capable of sending them to the bit bucket.
So. Anybody know any reason I'd want to keep them and, absent such a reason, anybody know a quick and complete way of deleting them? Used to be they'd always at least show up in Synaptic, but not this time.
No real reason to keep really old boot images, the last working one definitely keep though. Do a full tarball of /boot and then try this:
# ls -al --color=always /boot # Will show if you have screwy stragglers not shown in next step. # dpkg -l 'linux-image-*' | grep '^ii'
!Note: Do NOT remove anything identified as "meta-package!" from dpkg -l !
# sudo apt-get purge linux-image-3.13.0-147-amd64 # < verify name is correct! # sudo apt-get purge ... # sudo dpkg --configure -a
Then probably best to do a: # sudo apt-get update # sudo apt-get dist-upgrade
If you've never done this before, for your piece of mind, maybe wait for Slávek to verify? (or just do an internet search...)
HTH, Michael
said Michael:
| No real reason to keep really old boot images, the last working one | definitely keep though. Do a full tarball of /boot and then try this: | | # ls -al --color=always /boot # Will show if you have screwy stragglers | not shown in next step.
ls -al --color=always /boot total 202732 drwxr-xr-x 5 root root 20480 Aug 6 17:15 . drwxr-xr-x 28 root root 4096 Aug 6 14:22 .. -rw-r--r-- 1 root root 1166936 Jul 20 2017 abi-3.13.0-126-generic -rw-r--r-- 1 root root 1168650 May 2 2018 abi-3.13.0-147-generic -rw-r--r-- 1 root root 1251054 May 2 2018 abi-4.4.0-124-generic -rw-r--r-- 1 root root 166050 Jul 20 2017 config-3.13.0-126-generic -rw-r--r-- 1 root root 166136 May 2 2018 config-3.13.0-147-generic -rw-r--r-- 1 root root 190654 May 2 2018 config-4.4.0-124-generic -rw-r--r-- 1 root root 237851 Jul 9 11:49 config-5.4.0-80-generic drwxr-xr-x 19 root root 4096 Dec 31 1969 efi drwxr-xr-x 3 root root 4096 May 15 2018 extlinux drwxr-xr-x 7 root root 12288 Aug 6 17:37 grub lrwxrwxrwx 1 root root 27 Jul 21 10:41 initrd.img -> initrd.img-5.4.0-80-generic -rw-r--r-- 1 root root 20438488 Jun 30 13:02 initrd.img-3.13.0-126-generic -rw-r--r-- 1 root root 20438510 Jun 30 13:02 initrd.img-3.13.0-147-generic -rw-r--r-- 1 root root 20470196 Jun 30 13:02 initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root 95055861 Jul 23 06:45 initrd.img-5.4.0-80-generic lrwxrwxrwx 1 root root 28 Aug 6 17:15 initrd.img.old -> initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root 182704 Aug 18 2020 memtest86+.bin -rw-r--r-- 1 root root 184380 Aug 18 2020 memtest86+.elf -rw-r--r-- 1 root root 184884 Aug 18 2020 memtest86+_multiboot.bin -rw-r--r-- 1 root root 691 May 2 2018 retpoline-3.13.0-147-generic -rw-r--r-- 1 root root 255 May 2 2018 retpoline-4.4.0-124-generic -rw------- 1 root root 3400307 Jul 20 2017 System.map-3.13.0-126-generic -rw------- 1 root root 3413068 May 2 2018 System.map-3.13.0-147-generic -rw------- 1 root root 3898100 May 2 2018 System.map-4.4.0-124-generic -rw------- 1 root root 4751959 Jul 9 11:49 System.map-5.4.0-80-generic lrwxrwxrwx 1 root root 24 Jul 21 10:41 vmlinuz -> vmlinuz-5.4.0-80-generic -rw------- 1 root root 5851792 Jul 20 2017 vmlinuz-3.13.0-126-generic -rw------- 1 root root 5887024 May 2 2018 vmlinuz-3.13.0-147-generic -rw------- 1 root root 7143952 May 2 2018 vmlinuz-4.4.0-124-generic -rw------- 1 root root 11768064 Jul 9 12:09 vmlinuz-5.4.0-80-generic lrwxrwxrwx 1 root root 25 Aug 6 17:15 vmlinuz.old -> vmlinuz-4.4.0-124-generic
| # dpkg -l 'linux-image-*' | grep '^ii'
dpkg -l 'linux-image-*' | grep '^ii' ii linux-image-5.4.0-80-generic 5.4.0-80.90 amd64 Signed kernel image generic ii linux-image-generic 5.4.0.80.84 amd64 Generic Linux kernel image
See the problem? Three versions that the package manager doesn't see.
Internet serches render nothing I haven't tried. dpkg shows only the current kernel. The other three are there, and based on their numbering I have to assume that they came in as .deb packages. How they dropped off the radar I do not know, but given their age they have been around for awhile. Since Ubuntu 14.04, I think. No idea why they're timestamped as they are -- I don't remember doing anything to them in 2017 and 2018. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Friday 06 August 2021 05:59:09 pm dep wrote:
said Michael: | No real reason to keep really old boot images, the last working one | definitely keep though. Do a full tarball of /boot and then try this: | | # ls -al --color=always /boot # Will show if you have screwy stragglers | not shown in next step.
ls -al --color=always /boot total 202732 drwxr-xr-x 5 root root 20480 Aug 6 17:15 . drwxr-xr-x 28 root root 4096 Aug 6 14:22 .. -rw-r--r-- 1 root root 1166936 Jul 20 2017 abi-3.13.0-126-generic -rw-r--r-- 1 root root 1168650 May 2 2018 abi-3.13.0-147-generic -rw-r--r-- 1 root root 1251054 May 2 2018 abi-4.4.0-124-generic -rw-r--r-- 1 root root 166050 Jul 20 2017 config-3.13.0-126-generic -rw-r--r-- 1 root root 166136 May 2 2018 config-3.13.0-147-generic -rw-r--r-- 1 root root 190654 May 2 2018 config-4.4.0-124-generic -rw-r--r-- 1 root root 237851 Jul 9 11:49 config-5.4.0-80-generic drwxr-xr-x 19 root root 4096 Dec 31 1969 efi drwxr-xr-x 3 root root 4096 May 15 2018 extlinux drwxr-xr-x 7 root root 12288 Aug 6 17:37 grub lrwxrwxrwx 1 root root 27 Jul 21 10:41 initrd.img -> initrd.img-5.4.0-80-generic -rw-r--r-- 1 root root 20438488 Jun 30 13:02 initrd.img-3.13.0-126-generic -rw-r--r-- 1 root root 20438510 Jun 30 13:02 initrd.img-3.13.0-147-generic -rw-r--r-- 1 root root 20470196 Jun 30 13:02 initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root 95055861 Jul 23 06:45 initrd.img-5.4.0-80-generic lrwxrwxrwx 1 root root 28 Aug 6 17:15 initrd.img.old -> initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root 182704 Aug 18 2020 memtest86+.bin -rw-r--r-- 1 root root 184380 Aug 18 2020 memtest86+.elf -rw-r--r-- 1 root root 184884 Aug 18 2020 memtest86+_multiboot.bin -rw-r--r-- 1 root root 691 May 2 2018 retpoline-3.13.0-147-generic -rw-r--r-- 1 root root 255 May 2 2018 retpoline-4.4.0-124-generic -rw------- 1 root root 3400307 Jul 20 2017 System.map-3.13.0-126-generic -rw------- 1 root root 3413068 May 2 2018 System.map-3.13.0-147-generic -rw------- 1 root root 3898100 May 2 2018 System.map-4.4.0-124-generic -rw------- 1 root root 4751959 Jul 9 11:49 System.map-5.4.0-80-generic lrwxrwxrwx 1 root root 24 Jul 21 10:41 vmlinuz -> vmlinuz-5.4.0-80-generic -rw------- 1 root root 5851792 Jul 20 2017 vmlinuz-3.13.0-126-generic -rw------- 1 root root 5887024 May 2 2018 vmlinuz-3.13.0-147-generic -rw------- 1 root root 7143952 May 2 2018 vmlinuz-4.4.0-124-generic -rw------- 1 root root 11768064 Jul 9 12:09 vmlinuz-5.4.0-80-generic lrwxrwxrwx 1 root root 25 Aug 6 17:15 vmlinuz.old -> vmlinuz-4.4.0-124-generic
| # dpkg -l 'linux-image-*' | grep '^ii'
dpkg -l 'linux-image-*' | grep '^ii' ii linux-image-5.4.0-80-generic 5.4.0-80.90 amd64 Signed kernel image generic ii linux-image-generic 5.4.0.80.84 amd64 Generic Linux kernel image
See the problem? Three versions that the package manager doesn't see.
Internet serches render nothing I haven't tried. dpkg shows only the current kernel. The other three are there, and based on their numbering I have to assume that they came in as .deb packages. How they dropped off the radar I do not know
Okay, time for Slávek, or someone else with deeper knowledge to chime in. It might be as simple as just deleting the files, but IDK :(
Did you run the dpkg --configure -a ? There's a small possibility it'll re-attach the older cruft so you can remove it through the traditional apt-get purge. Again IDK if that’ll work, and I wouldn’t myself* try it until Slávek gives the go ahead...
Best, Michael
* Well if it was a test box or something sure, but not my main daily driver.
said Michael: | On Friday 06 August 2021 05:59:09 pm dep wrote: | > said Michael: | > | No real reason to keep really old boot images, the last working one | > | definitely keep though. Do a full tarball of /boot and then try | > | this: | > | | > | # ls -al --color=always /boot # Will show if you have screwy | > | stragglers not shown in next step. | > | > ls -al --color=always /boot | > total 202732 | > drwxr-xr-x 5 root root 20480 Aug 6 17:15 . | > drwxr-xr-x 28 root root 4096 Aug 6 14:22 .. | > -rw-r--r-- 1 root root 1166936 Jul 20 2017 abi-3.13.0-126-generic | > -rw-r--r-- 1 root root 1168650 May 2 2018 abi-3.13.0-147-generic | > -rw-r--r-- 1 root root 1251054 May 2 2018 abi-4.4.0-124-generic | > -rw-r--r-- 1 root root 166050 Jul 20 2017 | > config-3.13.0-126-generic -rw-r--r-- 1 root root 166136 May 2 | > 2018 config-3.13.0-147-generic -rw-r--r-- 1 root root 190654 May 2 | > 2018 config-4.4.0-124-generic -rw-r--r-- 1 root root 237851 Jul 9 | > 11:49 config-5.4.0-80-generic drwxr-xr-x 19 root root 4096 Dec 31 | > 1969 efi | > drwxr-xr-x 3 root root 4096 May 15 2018 extlinux | > drwxr-xr-x 7 root root 12288 Aug 6 17:37 grub | > lrwxrwxrwx 1 root root 27 Jul 21 10:41 initrd.img -> | > initrd.img-5.4.0-80-generic | > -rw-r--r-- 1 root root 20438488 Jun 30 13:02 | > initrd.img-3.13.0-126-generic -rw-r--r-- 1 root root 20438510 Jun 30 | > 13:02 initrd.img-3.13.0-147-generic -rw-r--r-- 1 root root 20470196 | > Jun 30 13:02 initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root | > 95055861 Jul 23 06:45 initrd.img-5.4.0-80-generic lrwxrwxrwx 1 root | > root 28 Aug 6 17:15 initrd.img.old -> | > initrd.img-4.4.0-124-generic | > -rw-r--r-- 1 root root 182704 Aug 18 2020 memtest86+.bin | > -rw-r--r-- 1 root root 184380 Aug 18 2020 memtest86+.elf | > -rw-r--r-- 1 root root 184884 Aug 18 2020 memtest86+_multiboot.bin | > -rw-r--r-- 1 root root 691 May 2 2018 | > retpoline-3.13.0-147-generic -rw-r--r-- 1 root root 255 May 2 | > 2018 retpoline-4.4.0-124-generic -rw------- 1 root root 3400307 Jul | > 20 2017 System.map-3.13.0-126-generic -rw------- 1 root root | > 3413068 May 2 2018 System.map-3.13.0-147-generic -rw------- 1 root | > root 3898100 May 2 2018 System.map-4.4.0-124-generic -rw------- 1 | > root root 4751959 Jul 9 11:49 System.map-5.4.0-80-generic lrwxrwxrwx | > 1 root root 24 Jul 21 10:41 vmlinuz -> | > vmlinuz-5.4.0-80-generic | > -rw------- 1 root root 5851792 Jul 20 2017 | > vmlinuz-3.13.0-126-generic -rw------- 1 root root 5887024 May 2 | > 2018 vmlinuz-3.13.0-147-generic -rw------- 1 root root 7143952 May | > 2 2018 vmlinuz-4.4.0-124-generic -rw------- 1 root root 11768064 Jul | > 9 12:09 vmlinuz-5.4.0-80-generic lrwxrwxrwx 1 root root 25 Aug | > 6 17:15 vmlinuz.old -> | > vmlinuz-4.4.0-124-generic | > | > | # dpkg -l 'linux-image-*' | grep '^ii' | > | > dpkg -l 'linux-image-*' | grep '^ii' | > ii linux-image-5.4.0-80-generic 5.4.0-80.90 amd64 | > Signed kernel image generic | > ii linux-image-generic 5.4.0.80.84 amd64 | > Generic Linux kernel image | > | > See the problem? Three versions that the package manager doesn't see. | > | > Internet serches render nothing I haven't tried. dpkg shows only the | > current kernel. The other three are there, and based on their | > numbering I have to assume that they came in as .deb packages. How | > they dropped off the radar I do not know | | Okay, time for Slávek, or someone else with deeper knowledge to chime | in. It might be as simple as just deleting the files, but IDK :( | | Did you run the dpkg --configure -a ? There's a small possibility it'll | re-attach the older cruft so you can remove it through the traditional | apt-get purge. Again IDK if that’ll work, and I wouldn’t myself* try it | until Slávek gives the go ahead...
One of the best things about this list is that it's not heavily populated by people who tell you to do things they know nothing about.
There comes a time when one contemplating a drink finally remembers the hangover, and decides not to. (I suppose.) In the same fashion, I've resisted the temptation to just delete 'em and see what happens, because for once I remember those many times of wondering for a day or two if I'm ever going to get the damned thing to work again. (And I figure I'm gonna need all the luck I can get, in switching the boot drive to the SSD next week.) So we're in agreement on that. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Sat, 7 Aug 2021, dep wrote:
said Michael: | On Friday 06 August 2021 05:59:09 pm dep wrote: | > said Michael: | > | No real reason to keep really old boot images, the last working one | > | definitely keep though. Do a full tarball of /boot and then try | > | this: | > | | > | # ls -al --color=always /boot # Will show if you have screwy | > | stragglers not shown in next step. | > | > ls -al --color=always /boot | > total 202732 | > drwxr-xr-x 5 root root 20480 Aug 6 17:15 . | > drwxr-xr-x 28 root root 4096 Aug 6 14:22 .. | > -rw-r--r-- 1 root root 1166936 Jul 20 2017 abi-3.13.0-126-generic | > -rw-r--r-- 1 root root 1168650 May 2 2018 abi-3.13.0-147-generic | > -rw-r--r-- 1 root root 1251054 May 2 2018 abi-4.4.0-124-generic | > -rw-r--r-- 1 root root 166050 Jul 20 2017 | > config-3.13.0-126-generic -rw-r--r-- 1 root root 166136 May 2 | > 2018 config-3.13.0-147-generic -rw-r--r-- 1 root root 190654 May 2 | > 2018 config-4.4.0-124-generic -rw-r--r-- 1 root root 237851 Jul 9 | > 11:49 config-5.4.0-80-generic drwxr-xr-x 19 root root 4096 Dec 31 | > 1969 efi | > drwxr-xr-x 3 root root 4096 May 15 2018 extlinux | > drwxr-xr-x 7 root root 12288 Aug 6 17:37 grub | > lrwxrwxrwx 1 root root 27 Jul 21 10:41 initrd.img -> | > initrd.img-5.4.0-80-generic | > -rw-r--r-- 1 root root 20438488 Jun 30 13:02 | > initrd.img-3.13.0-126-generic -rw-r--r-- 1 root root 20438510 Jun 30 | > 13:02 initrd.img-3.13.0-147-generic -rw-r--r-- 1 root root 20470196 | > Jun 30 13:02 initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root | > 95055861 Jul 23 06:45 initrd.img-5.4.0-80-generic lrwxrwxrwx 1 root | > root 28 Aug 6 17:15 initrd.img.old -> | > initrd.img-4.4.0-124-generic | > -rw-r--r-- 1 root root 182704 Aug 18 2020 memtest86+.bin | > -rw-r--r-- 1 root root 184380 Aug 18 2020 memtest86+.elf | > -rw-r--r-- 1 root root 184884 Aug 18 2020 memtest86+_multiboot.bin | > -rw-r--r-- 1 root root 691 May 2 2018 | > retpoline-3.13.0-147-generic -rw-r--r-- 1 root root 255 May 2 | > 2018 retpoline-4.4.0-124-generic -rw------- 1 root root 3400307 Jul | > 20 2017 System.map-3.13.0-126-generic -rw------- 1 root root | > 3413068 May 2 2018 System.map-3.13.0-147-generic -rw------- 1 root | > root 3898100 May 2 2018 System.map-4.4.0-124-generic -rw------- 1 | > root root 4751959 Jul 9 11:49 System.map-5.4.0-80-generic lrwxrwxrwx | > 1 root root 24 Jul 21 10:41 vmlinuz -> | > vmlinuz-5.4.0-80-generic | > -rw------- 1 root root 5851792 Jul 20 2017 | > vmlinuz-3.13.0-126-generic -rw------- 1 root root 5887024 May 2 | > 2018 vmlinuz-3.13.0-147-generic -rw------- 1 root root 7143952 May | > 2 2018 vmlinuz-4.4.0-124-generic -rw------- 1 root root 11768064 Jul | > 9 12:09 vmlinuz-5.4.0-80-generic lrwxrwxrwx 1 root root 25 Aug | > 6 17:15 vmlinuz.old -> | > vmlinuz-4.4.0-124-generic | > | > | # dpkg -l 'linux-image-*' | grep '^ii' | > | > dpkg -l 'linux-image-*' | grep '^ii' | > ii linux-image-5.4.0-80-generic 5.4.0-80.90 amd64 | > Signed kernel image generic | > ii linux-image-generic 5.4.0.80.84 amd64 | > Generic Linux kernel image | > | > See the problem? Three versions that the package manager doesn't see. | > | > Internet serches render nothing I haven't tried. dpkg shows only the | > current kernel. The other three are there, and based on their | > numbering I have to assume that they came in as .deb packages. How | > they dropped off the radar I do not know | | Okay, time for Slávek, or someone else with deeper knowledge to chime | in. It might be as simple as just deleting the files, but IDK :( | | Did you run the dpkg --configure -a ? There's a small possibility it'll | re-attach the older cruft so you can remove it through the traditional | apt-get purge. Again IDK if that’ll work, and I wouldn’t myself* try it | until Slávek gives the go ahead...
One of the best things about this list is that it's not heavily populated by people who tell you to do things they know nothing about.
There comes a time when one contemplating a drink finally remembers the hangover, and decides not to. (I suppose.) In the same fashion, I've resisted the temptation to just delete 'em and see what happens, because for once I remember those many times of wondering for a day or two if I'm ever going to get the damned thing to work again. (And I figure I'm gonna need all the luck I can get, in switching the boot drive to the SSD next week.) So we're in agreement on that.
Don't just delete them -- at least not yet. RENAME them. E.g.; mv vmlinuz-3.13.0-126-generic vmlinuz-3.13.0-126-generic-DELETE Then see how it goes for a few days.
My think? I think it is detritus left over from O/S upgrades over older versions of your O/S.
Jonesy
On Saturday 07 August 2021 03:00:48 pm dep wrote:
I figure I'm gonna need all the luck I can get, in switching the boot drive to the SSD next week.
S’Okay! That made this whole thing easy.
Modify as needed for your OS and particular hardware setup:
- Tarball /home (old-home) - Partition & format SSD * - Unpack (old-home) onto SSD - Install a clean OS to the SSD, checking preserving /home
* or do a throw-away OS install just to get partitions & formats
Here’s an expanded checklist for MX-Linux with encryption:
https://forum.mxlinux.org/viewtopic.php?p=588697#p588697
# # #
Hmm, if your OS does not have a preserve /home feature, it becomes a bit harder:
- During OS install do NOT create you as a user, create a dummy user. - After OS install Unpack (old-home) onto SSD. - Then create you as a user. (Which should fix all the perms and needed config files in old-home)
HTH, Best, Michael
PS: A 5 to 6 GB external HD is $100-$115 US at the moment if you just need space to dump transfer tarballs, etc.: https://pcpartpicker.com/products/external-hard-drive/#sort=ppgb&page=1
said Michael:
| On Saturday 07 August 2021 03:00:48 pm dep wrote: | > I figure I'm gonna need all the luck I can get, | > in switching the boot drive to the SSD next week. | | S’Okay! That made this whole thing easy. | | Modify as needed for your OS and particular hardware setup: | | - Tarball /home (old-home) | - Partition & format SSD * | - Unpack (old-home) onto SSD | - Install a clean OS to the SSD, checking preserving /home
That would for me be burning down the house and rebuilding it to get rid of some dust because there's no vacuum cleaner available.
I'll dd the /boot partition onto the new SSD, which I'm told will preserve the UUID, and I'll label it Boot for fstab purposes, change the UUID for the old boot partition, add the SSD -- I'll dd over USB -- figure the niceties of running update-grub (though with the same UUID as the previous boot partition it oughta boot fine anyway, right?) and keep everything else where it is. I've *always* put ~/ on its own partition and now it will be on its own drive. So no need to tarball several terabytes of data.
Anybody see where this might not work? The only place I see a possible problem is in when I update grub, the timing of which is always pretty ticklish with a new drive. If there's advice available on that, I'd be glad to hear it. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Sunday 08 August 2021 00.51:00 dep wrote:
Anybody see where this might not work? The only place I see a possible problem is in when I update grub, the timing of which is always pretty ticklish with a new drive. If there's advice available on that, I'd be glad to hear it. -- dep
What are the respective sizes?
I switched from a one HDD scheme (2GB) to a 1 SSD (256GB) and one HDD (same as before), then with a machine change to 1 NVMe (128GB), 2 SSD (256 & 32 GB) and one HDD, then recently replaced the HDD with a 1GB SSD.
I've been moving the partitions with Image for Linux, changing their sizes when necessary with gparted, and reinstalling GRUB (booting with a SuperGrub disk). All the time the original disk was safe, so there was no real risk.
In case you wonder why the 32GB SSD, I had it from an old machine and put cache on it.
If the SSD was same size as the HD, you could just image the original disk.
As to the UUIDs, if they are not preserved, just write the new ones in fstab.
By the way, I always install my systems with a 50GB root and a 15GB /home. I have this on the NVMe (with some important data on the third partition). I got two of these NVMe, the second one in a USB enclosure. Backup is done with IFL in less than 15 minutes, and in case of disaster I just swap the NVMe.
All other data are on other partitions and backups are managed "by hand".
Thierry
Michael composed on 2021-08-07 14:40 (UTC-0500):
Okay, time for Slávek, or someone else with deeper knowledge to chime in. It might be as simple as just deleting the files, but IDK :(
If dpkg doesn't find them in its database, and they're not part of the currently installed distro, the only things removing them manually can do are free up disk space and remove them from directory listings.
said Felix Miata:
| If dpkg doesn't find them in its database, and they're not part of the | currently installed distro, the only things removing them manually can | do are free up disk space and remove them from directory listings.
I'm less worried about deleting the kernels themselves and associated stuff in /boot as I am the other crap that came along with them. Looking just now, I see linux-headers extending back to 2.6.31-21, for instance. stuff
10 years old. Trying to think of other stuff kernels bring in with them,
not so much out of fear it'll do any harm but because it's messy and takes up space.
I wish there were a utility -- I understand why there can't really be one -- that would go over a system and identify everything that is no use to anyone anymore and never will be.
I think if I looked carefully in ~/ I could find some backed-up config files from KDE-2.x. But invariably when I go on a cleaning rampage I end up deleting one thing more than I should have . . . -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
Hi dep,
I wish there were a utility -- I understand why there can't really be one -- that would go over a system and identify everything that is no use to anyone anymore and never will be.
Deborphan is a good start. Will clear packages-leftovers from older deleted packages. But still a lot of "garbage" will be left and as you tolerated that to be installed, you must clean it up yourself.
Regards.
Anno domini 2021 Sat, 7 Aug 14:40:36 -0500 Michael scripsit:
On Friday 06 August 2021 05:59:09 pm dep wrote:
said Michael: | No real reason to keep really old boot images, the last working one | definitely keep though. Do a full tarball of /boot and then try this: | | # ls -al --color=always /boot # Will show if you have screwy stragglers | not shown in next step.
ls -al --color=always /boot total 202732 drwxr-xr-x 5 root root 20480 Aug 6 17:15 . drwxr-xr-x 28 root root 4096 Aug 6 14:22 .. -rw-r--r-- 1 root root 1166936 Jul 20 2017 abi-3.13.0-126-generic -rw-r--r-- 1 root root 1168650 May 2 2018 abi-3.13.0-147-generic -rw-r--r-- 1 root root 1251054 May 2 2018 abi-4.4.0-124-generic -rw-r--r-- 1 root root 166050 Jul 20 2017 config-3.13.0-126-generic -rw-r--r-- 1 root root 166136 May 2 2018 config-3.13.0-147-generic -rw-r--r-- 1 root root 190654 May 2 2018 config-4.4.0-124-generic -rw-r--r-- 1 root root 237851 Jul 9 11:49 config-5.4.0-80-generic drwxr-xr-x 19 root root 4096 Dec 31 1969 efi drwxr-xr-x 3 root root 4096 May 15 2018 extlinux drwxr-xr-x 7 root root 12288 Aug 6 17:37 grub lrwxrwxrwx 1 root root 27 Jul 21 10:41 initrd.img -> initrd.img-5.4.0-80-generic -rw-r--r-- 1 root root 20438488 Jun 30 13:02 initrd.img-3.13.0-126-generic -rw-r--r-- 1 root root 20438510 Jun 30 13:02 initrd.img-3.13.0-147-generic -rw-r--r-- 1 root root 20470196 Jun 30 13:02 initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root 95055861 Jul 23 06:45 initrd.img-5.4.0-80-generic lrwxrwxrwx 1 root root 28 Aug 6 17:15 initrd.img.old -> initrd.img-4.4.0-124-generic -rw-r--r-- 1 root root 182704 Aug 18 2020 memtest86+.bin -rw-r--r-- 1 root root 184380 Aug 18 2020 memtest86+.elf -rw-r--r-- 1 root root 184884 Aug 18 2020 memtest86+_multiboot.bin -rw-r--r-- 1 root root 691 May 2 2018 retpoline-3.13.0-147-generic -rw-r--r-- 1 root root 255 May 2 2018 retpoline-4.4.0-124-generic -rw------- 1 root root 3400307 Jul 20 2017 System.map-3.13.0-126-generic -rw------- 1 root root 3413068 May 2 2018 System.map-3.13.0-147-generic -rw------- 1 root root 3898100 May 2 2018 System.map-4.4.0-124-generic -rw------- 1 root root 4751959 Jul 9 11:49 System.map-5.4.0-80-generic lrwxrwxrwx 1 root root 24 Jul 21 10:41 vmlinuz -> vmlinuz-5.4.0-80-generic -rw------- 1 root root 5851792 Jul 20 2017 vmlinuz-3.13.0-126-generic -rw------- 1 root root 5887024 May 2 2018 vmlinuz-3.13.0-147-generic -rw------- 1 root root 7143952 May 2 2018 vmlinuz-4.4.0-124-generic -rw------- 1 root root 11768064 Jul 9 12:09 vmlinuz-5.4.0-80-generic lrwxrwxrwx 1 root root 25 Aug 6 17:15 vmlinuz.old -> vmlinuz-4.4.0-124-generic
| # dpkg -l 'linux-image-*' | grep '^ii'
dpkg -l 'linux-image-*' | grep '^ii' ii linux-image-5.4.0-80-generic 5.4.0-80.90 amd64 Signed kernel image generic ii linux-image-generic 5.4.0.80.84 amd64 Generic Linux kernel image
See the problem? Three versions that the package manager doesn't see.
Internet serches render nothing I haven't tried. dpkg shows only the current kernel. The other three are there, and based on their numbering I have to assume that they came in as .deb packages. How they dropped off the radar I do not know
Okay, time for Slávek, or someone else with deeper knowledge to chime in. It might be as simple as just deleting the files, but IDK :(
Did you run the dpkg --configure -a ? There's a small possibility it'll re-attach the older cruft so you can remove it through the traditional apt-get purge. Again IDK if that’ll work, and I wouldn’t myself* try it until Slávek gives the go ahead...
Best, Michael
On the running system do:
$ uname -a
Most likely it's kernel 5.4.0-80-generic you are running. Check, if there are at least packages for the antique kernels:
$ dpkg -l|grep linux-image
If yes, purge them:
# aptitude purge linux-image-3.13.0...<wahtever>
If there aren't any, just delete the files and run:
# update-grub
reboot, everytrhing wil be fine :) Nik
- Well if it was a test box or something sure, but not my main daily driver.
tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
dep wrote:
. . . I have in my /boot directory four kernels -- the running one (5.4.0-80) -- and some rather hoary ones: 4.4.0-124, 3.13.0-147, and 3.13.0-126. i do not currently have nor do I imagine ever having need for the last three. Thought I'd get rid of 'em, but they do not show up in Ubuntu Cleaner or anything else capable of sending them to the bit bucket.
So. Anybody know any reason I'd want to keep them and, absent such a reason, anybody know a quick and complete way of deleting them? Used to be they'd always at least show up in Synaptic, but not this time.
This is strange that you have those in /boot and no package in the list. Are you sure that when you execute dpkg -l | grep 4.4.0-124 (or 3.13.0-147) nothing pops up?
if so deleting manually is easy. Remove everything /boot/*4.4.0-124* (or 3.13.0-147) and from /lib/modules/*4.4.0-124*
Execute update-grub and it is done.
said deloptes:
| This is strange that you have those in /boot and no package in the list. | Are you sure that when you execute dpkg -l | grep 4.4.0-124 (or | 3.13.0-147) nothing pops up?
Yes, it is strange and yes, nothing pops up. As noted later, I have some but not all kernal sources going back more than a decade sitting in /usr/src, too. I'm just trying to imagine any conceivable reason I'd want them around. I don't think I have any hardware that's so deprecated that it would ever require resort to those things, nor any applications that recompile themselves and might need them. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
dep wrote:
Yes, it is strange and yes, nothing pops up. As noted later, I have some but not all kernal sources going back more than a decade sitting in /usr/src, too. I'm just trying to imagine any conceivable reason I'd want them around. I don't think I have any hardware that's so deprecated that it would ever require resort to those things, nor any applications that recompile themselves and might need them.
they would not likely look for anything under /usr/src. However your question was not about /usr/src, but about /boot (and I assume /lib/modules)
Time ago before I started building with make deb-pkg ... or better bindeb-pkg I had to manually clean too. Now using make bindeb-pkg (may be with -j option) produces debs which are managed by apt like each other package.
There is also very rear probability you would need old kernel, but it is up to you to decide what to do with those
-
deloptes -
dep -
Dr. Nikolaus Klepp -
Felix Miata -
Marvin Jones -
Michael -
phiebie＠drei.at -
Thierry de Coulon