Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236804 > unrolled thread

removing modules

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  removing modules mick crane <mick.crane@gmail.com> - 2021-07-03 18:10 +0200
    Re: removing modules Reco <recoverym4n@enotuniq.net> - 2021-07-03 18:20 +0200
    Re: removing modules The Wanderer <wanderer@fastmail.fm> - 2021-07-03 18:30 +0200
      Re: removing modules The Wanderer <wanderer@fastmail.fm> - 2021-07-03 19:10 +0200
        Re: removing modules The Wanderer <wanderer@fastmail.fm> - 2021-07-03 19:40 +0200
        Re: removing modules The Wanderer <wanderer@fastmail.fm> - 2021-07-03 19:40 +0200
      Re: removing modules IL Ka <kazakevichilya@gmail.com> - 2021-07-03 19:10 +0200
        Re: removing modules Hans <hans.ullrich@loop.de> - 2021-07-03 20:10 +0200
          Re: removing modules Sven Hartge <sven@svenhartge.de> - 2021-07-03 20:50 +0200
      Re: removing modules Reco <recoverym4n@enotuniq.net> - 2021-07-03 19:10 +0200
      Re: removing modules Greg Wooledge <greg@wooledge.org> - 2021-07-03 19:20 +0200
        Re: removing modules Greg Wooledge <greg@wooledge.org> - 2021-07-03 20:10 +0200
          Re: removing modules Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-03 20:30 +0200
            Re: removing modules Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-03 22:40 +0200
            Re: removing modules David Wright <deblis@lionunicorn.co.uk> - 2021-07-04 17:30 +0200
        Re: removing modules Brian <ad44@cityscape.co.uk> - 2021-07-03 21:10 +0200
          Re: removing modules Tom Dial <tddial@comcast.net> - 2021-07-04 05:10 +0200
            Re: removing modules Brian <ad44@cityscape.co.uk> - 2021-07-04 11:10 +0200
              Re: removing modules Tixy <tixy@yxit.co.uk> - 2021-07-04 14:50 +0200
                Re: removing modules Brian <ad44@cityscape.co.uk> - 2021-07-04 20:50 +0200
                  Re: removing modules Brad Rogers <brad@fineby.me.uk> - 2021-07-04 21:20 +0200
                    Re: removing modules Brian <ad44@cityscape.co.uk> - 2021-07-04 22:20 +0200
                      Re: removing modules David Wright <deblis@lionunicorn.co.uk> - 2021-07-05 07:00 +0200
                        Re: removing modules Brian <ad44@cityscape.co.uk> - 2021-07-05 12:10 +0200
      Re: removing modules David Wright <deblis@lionunicorn.co.uk> - 2021-07-03 19:40 +0200
    Re: removing modules IL Ka <kazakevichilya@gmail.com> - 2021-07-03 18:30 +0200

Page 1 of 2  [1] 2  Next page →

#236804 — removing modules

hello,
If I type "lsmod" there is a big list of modules with many followed by a 
"0"
which I guess means they are not needed in the kernel ?
Does lsmod know about all installed software and if a module is needed 
or does software have to be run first ?
If I don't need them can somebody remind me how I can remove modules ?
cheers
mick

-- 
Key ID    4BFEBB31

[toc] | [next] | [standalone]

#236805

	Hi.

On Sat, Jul 03, 2021 at 05:06:10PM +0100, mick crane wrote:
> If I type "lsmod" there is a big list of modules with many followed by a "0" which I guess means they are not needed in the kernel ?

Third column that lsmod shows is a kernel module reference count.
It can be increased by a userspace process which uses the module, by a
mounted filesystem or by another module.
In the last case "Used by" contains the name of such module(s).

Note that configured network interfaces do not increase module's
reference count, so unloading those won't be the best of ideas.

If the module reference count is zero, then the module can be unloaded
from the current kernel.


> Does lsmod know about all installed software and if a module is needed or does software have to be run first ?

Can you repeat it, but in plain English please?


> If I don't need them can somebody remind me how I can remove modules ?

/sbin/modprobe -r <module_to_remove>

Reco

[toc] | [prev] | [next] | [standalone]

#236806

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-03 at 12:06, mick crane wrote:

> hello,
> If I type "lsmod" there is a big list of modules with many followed by a 
> "0"
> which I guess means they are not needed in the kernel ?

That depends what you mean by "needed".

As I understand matters, what that number being nonzero means is that
there's something else the kernel knows about (usually another module)
which won't work if this module isn't loaded. In order to unload this
module, you'll want to unload the other one first.

If the module is zero, that means that the kernel doesn't know of
anything other than that module which won't work unless the module is
present.

That doesn't mean that the module itself isn't needed, however. There
might be some functionality which you need which is provided directly by
that module, rather than by something which the kernel knows about and
considers to be "something else", but which won't work if the module
isn't loaded.

For example, if the driver for your network card is contained in a
module, then even if no other modules depend on that one, unloading the
module would mean your network card would stop functioning. If you need
your network to be functioning, that would mean that you still need the
module, even though there aren't any other modules (etc.) which depends
on it.

> Does lsmod know about all installed software and if a module is
> needed or does software have to be run first ?

As Reco suggested, you'll have to clarify this. Most of the time,
software does not require loading modules; it's most often hardware that
requires that.

> If I don't need them can somebody remind me how I can remove modules
> ?

The command to run is 'modprobe -r MODULE_NAME'.

You can also do it with 'rmmod MODULE_NAME', but that's not usually the
best way; IIRC, modprobe includes smarts which rmmod doesn't.

Both of those commands need to be run as root in order to work.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#236808

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-03 at 12:50, mick crane wrote:

> I did think that modules are for the kernel to interact with
> hardware. There is for example "dell_smm_hwmon" followed "0" which
> you'd think was to be used by software for monitoring the PC
> hardware.
> 
> I never used anything like that and wondered if there was some
> software that was installed that needed that module but I never used
> so it is "0" but if I used it it would change to "1".

No - the "0" means that there is nothing else which the kernel currently
knows A: is running and B: would fail if that module were not loaded.

The most likely reason for it to be installed is because you have
hardware which is capable of being managed by that module, and won't
work without that module. If you don't need to use the hardware, you
don't need the module and can probably safely remove it - but it's hard
to know which hardware components the various software you're running
may or may not be making use of.

> I looked because "apt upgrade" failed to install things in /boot
> because no room left. I deleted the oldest kernel stuff of the 3
> there and "apt upgrade" worked.

I hope you removed them by uninstalling their kernel packages, not by
just deleting the files from under /boot directly.

> I was thinking then to remove the unwanted modules to make the
> kernels smaller.

Kernel modules aren't actually stored inside the kernel on-disk. They're
normally found in a kernel-specific subdirectory underneath
/lib/modules/; the subdirectory name is the string which the kernel in
question would print if you ran the command 'uname -r'.

That said, if you have an initrd or initramfs stored under /boot, some
of the modules will probably be included in that. This isn't strictly
part of the kernel, but it does take up space on /boot, so it'd be
relevant to your considerations.

> There is for example a few filesystem modules like msdos which would
> be needed if I wanted to mount an msdos filesystem. Seem to remember
> "insmod" a module if and when needed.

Typically, for modules like that, they will be loaded on demand. They
don't generally get loaded during the boot process unless one of the
filesystems which the boot process needs is of that type, so they will
not always be included in the initrd / initramfs; as a result, leaving
them out will not necessarily reduce the space those files consume.

> If remove modules from kernel are the gone or are they still on disk
> and could be put back ?

If you remove them by 'modprobe -r' or 'rmmod', you mean? Yes - all that
does is tell the kernel to unload the module; it's loaded on demand from
the disk (by 'modprobe', 'insmod', or similar), from that location
underneath /lib/modules/, every time you boot and do something that
needs it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#236812

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-03 at 13:28, mick crane wrote:

> On 2021-07-03 18:03, The Wanderer wrote:
> 
>>> I looked because "apt upgrade" failed to install things in /boot 
>>> because no room left. I deleted the oldest kernel stuff of the 3 
>>> there and "apt upgrade" worked.
>> 
>> I hope you removed them by uninstalling their kernel packages, not
>> by just deleting the files from under /boot directly.
> 
> <cough> what happens if I might remove them by <cough> deleting them
> ?

If the files under /boot from a kernel package has been deleted, but
that package is still marked as installed, nothing bad should happen as
long as you don't try to do anything which would have used those files.

It's just that there's an inconsistency between what the package manager
thinks is present, and what's actually installed. Depending on how
things are implemented, the package manager might trigger doing
something with those files the next time you install or upgrade a
kernel, or it might not; I don't remember enough specific details just
at the moment to be sure, although I think you're probably safe in that
regard.

The good news is that A: as long as you know which files were deleted,
it should be fairly straightforward to figure out which packages they
came from, and

B: as long as you know which packages the deleted files came from, it
should be fine to remove the packages after the fact, thereby bringing
things back into sync.

The only issue should come about if somehow the removal scripts for the
package notice the absence of the files and can't handle it, and that
doesn't seem likely to me.

> I don't see any option from grub for booting different kernels.

Depending on what GRUB you have and how it's configured (and possibly on
exactly what files you had before the deletion), that might be normal.
For some while now, all GRUB on my own machines has been showing me is a
"boot the default kernel with the default arguments" option and a second
option to view more options; the latter menu, when I bother to check it,
usually shows at least one other kernel, as well as e.g. the
single-user-mode boot option for the default kernel.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#236813

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-03 at 13:28, mick crane wrote:

> On 2021-07-03 18:03, The Wanderer wrote:
> 
>>> I looked because "apt upgrade" failed to install things in /boot 
>>> because no room left. I deleted the oldest kernel stuff of the 3 
>>> there and "apt upgrade" worked.
>> 
>> I hope you removed them by uninstalling their kernel packages, not
>> by just deleting the files from under /boot directly.
> 
> <cough> what happens if I might remove them by <cough> deleting them
> ?

If the files under /boot from a kernel package has been deleted, but
that package is still marked as installed, nothing bad should happen as
long as you don't try to do anything which would have used those files.

It's just that there's an inconsistency between what the package manager
thinks is present, and what's actually installed. Depending on how
things are implemented, the package manager might trigger doing
something with those files the next time you install or upgrade a
kernel, or it might not; I don't remember enough specific details just
at the moment to be sure, although I think you're probably safe in that
regard.

The good news is that A: as long as you know which files were deleted,
it should be fairly straightforward to figure out which packages they
came from, and

B: as long as you know which packages the deleted files came from, it
should be fine to remove the packages after the fact, thereby bringing
things back into sync.

The only issue should come about if somehow the removal scripts for the
package notice the absence of the files and can't handle it, and that
doesn't seem likely to me.

> I don't see any option from grub for booting different kernels.

Depending on what GRUB you have and how it's configured (and possibly on
exactly what files you had before the deletion), that might be normal.
For some while now, all GRUB on my own machines has been showing me is a
"boot the default kernel with the default arguments" option and a second
option to view more options; the latter menu, when I bother to check it,
usually shows at least one other kernel, as well as e.g. the
single-user-mode boot option for the default kernel.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#236809

[Multipart message — attachments visible in raw view] — view raw

>
>
> There is for example "dell_smm_hwmon" followed "0" which you'd think was
> to be used by software for monitoring the PC hardware.
>

You have this device (SMM BIOS), so ``udev`` loaded this module.

It creates `` /sys/class/hwmon/hwmon..`` for hardware monitoring.
Remove this module, and this file will disappear.

Do you need this file? We do not know, it is up to you to decide if you
want to monitor the fan and temperature of your laptop or not
https://www.kernel.org/doc/html/latest/hwmon/dell-smm-hwmon.html


I was thinking then to remove the unwanted modules to make the kernels
> smaller.
>
I don't think it will make a real difference unless you have 16MB of RAM




> There is for example a few filesystem modules like msdos which would be
> needed if I wanted to mount an msdos filesystem.
>
Yes.

Almost any code that runs in kernel module may be installed as module:
there are netfilter modules, hardware drivers, bpf filter etc


> Seem to remember "insmod" a module if and when needed.
>
Use ``modprobe``: it loads module dependencies


>
> If remove modules from kernel are the gone or are they still on disk and
> could be put back ?
>
They are in
/lib/modules/$(uname -r)

"remove" module means unload it from the memory, not remove it from the disk



>

[toc] | [prev] | [next] | [standalone]

#236816

Am Samstag, 3. Juli 2021, 19:01:02 CEST schrieb IL Ka:

Hi all,

> I was thinking then to remove the unwanted modules to make the kernels
> 
> > smaller.
> 
Some years ago I tested a few things.
I built a monolithic kernel with all the modules statically built in, as I 
knew all modules I needed. 

Everything else, I did not need, I removed from the kernel. So I got a optimal 
kernel exactly for my machine.

Then I took the booting time.

After this I made a minimalistic kernel (nearly a microkernel) with only just 
the needed modules built in and left all other modules I needed as loadable 
modules.

Then I took the booting time.

At last I took the debian standard kernel and built it without any changes for 
my architecture.

Then I took the booting time.

What do you think? No, you are wrong, the difference among those three kernels 
in the booting time was not big, just maybe 1 to 3 seconds.

However, building an own kernel might improve security, i.e. on my servers I 
removed the usbmodule and cdrom stuff, so that no one could easy connect evil 
hardware to the servers (we sometimes got visitors in the data processing 
center)

Just my 2 cents...

Best 

Hans

 

[toc] | [prev] | [next] | [standalone]

#236818

Hans <hans.ullrich@loop.de> wrote:

> However, building an own kernel might improve security, i.e. on my
> servers I removed the usbmodule and cdrom stuff, so that no one could
> easy connect evil hardware to the servers (we sometimes got visitors
> in the data processing center)

Or you could just blacklist those modules to prevent them from being
auto-loaded. Serves the same purpose without needing to manually build
update Kernels.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#236810

On Sat, Jul 03, 2021 at 05:50:44PM +0100, mick crane wrote:
> I looked because "apt upgrade" failed to install things in /boot
> because no room left. I deleted the oldest kernel stuff of the 3 there
> and "apt upgrade" worked.

Kernel is here:

$ du -sxh /boot/vmlinuz-5.10.0-0.bpo.7-amd64 
6.5M    /boot/vmlinuz-5.10.0-0.bpo.7-amd64

Modules are here:

$ du -sxh /lib/modules/5.10.0-0.bpo.7-amd64/
290M    /lib/modules/5.10.0-0.bpo.7-amd64/

You must mean initrd, which contains selected kernel modules and is used
in the boot process:

$ du -sxh /boot/initrd.img-5.10.0-0.bpo.7-amd64 
36M     /boot/initrd.img-5.10.0-0.bpo.7-amd64


> I was thinking then to remove the unwanted modules to make the kernels smaller.

It does not work like this, no amount of modprobing or removing *ko
files would make an installed kernel smaller.
You could build your own kernel, of course, then things would be
different.


> If remove modules from kernel are the gone or are they still on disk and could be put back ?

Modprobe, insmod and rmmod merely change the state of the running
kernel (i.e. - in-memory).

What you probably want described at initramfs.conf(5), MODULES section.

Reco

[toc] | [prev] | [next] | [standalone]

#236811

On Sat, Jul 03, 2021 at 05:50:44PM +0100, mick crane wrote:
> I did think that modules are for the kernel to interact with hardware.
> There is for example "dell_smm_hwmon" followed "0" which you'd think was to
> be used by software for monitoring the PC hardware.

Use modinfo(8) to learn what a module does, or at least a very brief
description of it.

In this case:

unicorn:~$ modinfo dell_smm_hwmon
filename:       /lib/modules/5.10.0-7-amd64/kernel/drivers/hwmon/dell-smm-hwmon.ko
alias:          i8k
license:        GPL
description:    Dell laptop SMM BIOS hwmon driver
[...]

I know, it's not a lot.

> I looked because "apt upgrade" failed to install things in /boot because no
> room left. I deleted the oldest kernel stuff of the 3 there and "apt
> upgrade" worked.
> I was thinking then to remove the unwanted modules to make the kernels
> smaller.

Modules are sitting on disk waiting to be loaded into memory if they're
needed.

lsmod shows the ones that are currently loaded into memory.

Removing one from memory with rmmod(8) or an equivalent will not reduce
the amount of disk space they take up.  All it will do is free a tiny
bit of RAM, and sacrifice the functionality being provided by the module.

If disk space is a serious issue for you, rmmod(8) will not help.

[toc] | [prev] | [next] | [standalone]

#236815

On Sat, Jul 03, 2021 at 06:49:35PM +0100, mick crane wrote:
> root@pumpkin:/boot# df -h /boot
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sdb1       236M  159M   65M  71% /boot

This is the real issue.  This file system is simply too small if you
plan to keep more than 2 kernels at a time.

> root@pumpkin:/boot# ls -la
> total 148944
> drwxr-xr-x  4 root root     1024 Jul  3 16:53 .
> drwxr-xr-x 20 root root     4096 Jul  3 16:45 ..
> -rw-r--r--  1 root root   236065 Apr  9 19:17 config-5.10.0-6-amd64
> -rw-r--r--  1 root root   236188 May 28 09:31 config-5.10.0-7-amd64
> drwxr-xr-x  5 root root     1024 Jul  3 16:45 grub
> -rw-r--r--  1 root root 68868137 Jul  1 16:17 initrd.img-5.10.0-6-amd64
> -rw-r--r--  1 root root 68909875 Jul  3 16:53 initrd.img-5.10.0-7-amd64
> drwx------  2 root root    12288 Nov 21  2020 lost+found
> -rw-r--r--  1 root root       83 Apr  9 19:17 System.map-5.10.0-6-amd64
> -rw-r--r--  1 root root       83 May 28 09:31 System.map-5.10.0-7-amd64
> -rw-r--r--  1 root root  6824192 Apr  9 19:17 vmlinuz-5.10.0-6-amd64
> -rw-r--r--  1 root root  6818304 May 28 09:31 vmlinuz-5.10.0-7-amd64

As long as you stick to two kernels, you should be OK for a while, at
least until kernel packages increase dramatically in size, as they tend
to do over time.

One thing I'll note is that your initrd* files are twice as big as mine.

-rw-r--r-- 1 root root 30924690 Jan 29 17:34 initrd.img-4.19.0-13-amd64
-rw-r--r-- 1 root root 33151811 May 13 07:19 initrd.img-5.10.0-6-amd64
-rw-r--r-- 1 root root 33165977 Jun 28 07:08 initrd.img-5.10.0-7-amd64

Maybe someone who understands this part of Debian can help you figure
out why your initrd* files are so big, and what you should do about
it.  (Is it an nvidia thing, I wonder?  I have motherboard Intel graphics.)

Apart from that, if you're not able to increase the size of your /boot
file system (tricky at best), my suggestion would be to remove your
oldest kernel by hand any time you're about to install a new kernel
(one with a new ABI number, like -8-amd64 -9-amd64 and so on).  Freeing
up that space in advance should prevent problems.

[toc] | [prev] | [next] | [standalone]

#236817

Greg Wooledge [2021-07-03 14:03:44] wrote:
> On Sat, Jul 03, 2021 at 06:49:35PM +0100, mick crane wrote:
>> root@pumpkin:/boot# df -h /boot
>> Filesystem      Size  Used Avail Use% Mounted on
>> /dev/sdb1       236M  159M   65M  71% /boot
> This is the real issue.  This file system is simply too small if you
> plan to keep more than 2 kernels at a time.

Not at all.  Just adjust the /etc/initramfs-tools/initramfs.conf with

    MODULES=dep
    COMPRESS=lzma

and you'll have room for many more kernels.

> One thing I'll note is that your initrd* files are twice as big as mine.
>
> -rw-r--r-- 1 root root 30924690 Jan 29 17:34 initrd.img-4.19.0-13-amd64
> -rw-r--r-- 1 root root 33151811 May 13 07:19 initrd.img-5.10.0-6-amd64
> -rw-r--r-- 1 root root 33165977 Jun 28 07:08 initrd.img-5.10.0-7-amd64

Indeed, his initrd.imgs are unusually large.  Not sure what's going on
with them, but the above two changes should shave off at the very least
20MB from each one of his initrd.img.

The only thing with `MODULES=dep` is that it runs a slightly higher risk
of ending up with an unbootable system after a hardware or
filesystem/LVM/MD/partition change.  Just make sure you have some way to
do a "rescue boot" in those cases (typically via a USB flash key with some
minimal GNU/Linux system on it), but this comes in handy in many other
circumstances so I recommend you have that at hand in any case.


        Stefan

[toc] | [prev] | [next] | [standalone]

#236821

> The only thing with `MODULES=dep` is that it runs a slightly higher risk
> of ending up with an unbootable system after a hardware or
> filesystem/LVM/MD/partition change.  Just make sure you have some way to
> do a "rescue boot" in those cases (typically via a USB flash key with some
> minimal GNU/Linux system on it), but this comes in handy in many other
> circumstances so I recommend you have that at hand in any case.

BTW, you can try:

    lsinitramfs -l /boot/initrd.img-<FOO>  | sort -n +4

to see the parts of the initrd that are likely to take most of
the space.


        Stefan

[toc] | [prev] | [next] | [standalone]

#236856

On Sat 03 Jul 2021 at 14:20:28 (-0400), Stefan Monnier wrote:
> The only thing with `MODULES=dep` is that it runs a slightly higher risk
> of ending up with an unbootable system after a hardware or
> filesystem/LVM/MD/partition change.

Alternatively, use a little forethought and rebuild initrd with
MODULES=most /before/ making such changes.

> Just make sure you have some way to
> do a "rescue boot" in those cases (typically via a USB flash key with some
> minimal GNU/Linux system on it), but this comes in handy in many other
> circumstances so I recommend you have that at hand in any case.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#236820

On Sat 03 Jul 2021 at 18:49:35 +0100, mick crane wrote:

[...]

> Can I not *just* move the older ones out of the way so upgrade doesn't run
> out of space ?

Why bother?

  apt purge linux...

Why do you need two kernels anyway?

Next time - don't have a separate boot partition. You will be happier.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#236829

On 7/3/21 13:04, Brian wrote:
> On Sat 03 Jul 2021 at 18:49:35 +0100, mick crane wrote:
> 
> [...]
> 
>> Can I not *just* move the older ones out of the way so upgrade doesn't run
>> out of space ?
> 
> Why bother?
> 
>   apt purge linux...
> 
> Why do you need two kernels anyway?

I rather having two kernels (but scarcely ever more) to ensure there is
a known safe fallback in case of problems after installation of a new
kernel.
> 
> Next time - don't have a separate boot partition. You will be happier.

And a separate boot partition because most of my systems are laptops
with everything except /boot on encrypted media.

Regards,
Tom Dial
> 

[toc] | [prev] | [next] | [standalone]

#236843

On Sat 03 Jul 2021 at 20:49:01 -0600, Tom Dial wrote:

> 
> 
> On 7/3/21 13:04, Brian wrote:
> > On Sat 03 Jul 2021 at 18:49:35 +0100, mick crane wrote:
> > 
> > [...]
> > 
> >> Can I not *just* move the older ones out of the way so upgrade doesn't run
> >> out of space ?
> > 
> > Why bother?
> > 
> >   apt purge linux...
> > 
> > Why do you need two kernels anyway?
> 
> I rather having two kernels (but scarcely ever more) to ensure there is
> a known safe fallback in case of problems after installation of a new
> kernel.

I see the point of that in the immediate aftermath of getting a new
kernel, but as time goes on there is surely less need for it?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#236852

On Sun, 2021-07-04 at 10:08 +0100, Brian wrote:
> On Sat 03 Jul 2021 at 20:49:01 -0600, Tom Dial wrote:
> 
> > 
> > 
> > On 7/3/21 13:04, Brian wrote:
> > > On Sat 03 Jul 2021 at 18:49:35 +0100, mick crane wrote:
> > > 
> > > [...]
> > > 
> > > > Can I not *just* move the older ones out of the way so upgrade doesn't run
> > > > out of space ?
> > > 
> > > Why bother?
> > > 
> > >   apt purge linux...
> > > 
> > > Why do you need two kernels anyway?
> > 
> > I rather having two kernels (but scarcely ever more) to ensure there is
> > a known safe fallback in case of problems after installation of a new
> > kernel.
> 
> I see the point of that in the immediate aftermath of getting a new
> kernel, but as time goes on there is surely less need for it?
> 

There is need, because if there's no binary compatibility change,
Debian kernel updates keep the same version number and overwrite the
existing one. So if that new kernel has a bug on your system and won't
boot, then you're a bit stuffed. This has happened to me in the past.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#236865

On Sun 04 Jul 2021 at 13:45:00 +0100, Tixy wrote:

> On Sun, 2021-07-04 at 10:08 +0100, Brian wrote:
> > On Sat 03 Jul 2021 at 20:49:01 -0600, Tom Dial wrote:
> > 
> > > 
> > > 
> > > On 7/3/21 13:04, Brian wrote:
> > > > On Sat 03 Jul 2021 at 18:49:35 +0100, mick crane wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > Can I not *just* move the older ones out of the way so upgrade doesn't run
> > > > > out of space ?
> > > > 
> > > > Why bother?
> > > > 
> > > >   apt purge linux...
> > > > 
> > > > Why do you need two kernels anyway?
> > > 
> > > I rather having two kernels (but scarcely ever more) to ensure there is
> > > a known safe fallback in case of problems after installation of a new
> > > kernel.
> > 
> > I see the point of that in the immediate aftermath of getting a new
> > kernel, but as time goes on there is surely less need for it?
> > 
> 
> There is need, because if there's no binary compatibility change,
> Debian kernel updates keep the same version number and overwrite the
> existing one. So if that new kernel has a bug on your system and won't
> boot, then you're a bit stuffed. This has happened to me in the past.

I did specify "as time goes on". Suppose one boots successfully a 100
times with the new kernel. What need is there for a second kernel on
the system?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web