6 Aug
2021
6 Aug
'21
9:24 p.m.
. . . 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/
6 Aug
6 Aug
10:05 p.m.
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
10:59 p.m.
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/
7 Aug
7 Aug
7:40 p.m.
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.
8 p.m.
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/
8:08 p.m.
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
--
Marvin L Jones | Marvin | W3DHJ | linux
Pueblo, Colorado | @ | Jonesy | FreeBSD __
38.238N 104.547W | jonz.net | DM78rf | SK
10:39 p.m.
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
10:51 p.m.
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/
8 Aug
8 Aug
7:40 a.m.
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
7 Aug
7 Aug
8:12 p.m.
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.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
8:58 p.m.
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/
8 Aug
8 Aug
11:32 a.m.
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.
7 Aug
7 Aug
8:17 p.m.
Anno domini 2021 Sat, 7 Aug 14:40:36 -0500
Michael scripsit:
On Friday 06 August 2021 05:59:09 pm dep wrote:
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
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.
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
8 Aug
8 Aug
3:55 p.m.
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.
4:02 p.m.
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/
5:50 p.m.
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
998
days inactive
1000
days old
15 comments
8 participants
participants (8)
-
deloptes -
dep -
Dr. Nikolaus Klepp -
Felix Miata -
Marvin Jones -
Michael -
phiebie＠drei.at -
Thierry de Coulon