Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
removing modules
66 views
Skip to first unread message
mick crane
Jul 3, 2021, 12:10:04 PM7/3/21
to
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
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
Reco
Jul 3, 2021, 12:20:04 PM7/3/21
to
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
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 ?
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 ?
> If I don't need them can somebody remind me how I can remove modules ?
Reco
The Wanderer
Jul 3, 2021, 12:30:04 PM7/3/21
to
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".
> 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 ?
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 ?
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
> ?
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
IL Ka
Jul 3, 2021, 12:30:04 PM7/3/21
to
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 means no module depends on it.
But it doesn't mean this particular module isn't required.
Does lsmod know about all installed software and if a module is needed
or does software have to be run first ?
lsmod doesn't care about software.
It only reports modules and their dependencies.
If I don't need them can somebody remind me how I can remove modules ?
rmmod(8), but in most cases you shouldn't remove modules.
Many modules are loaded by ``udev`` to support your hardware, so be sure not to unload your NIC driver by accident)
Reco
Jul 3, 2021, 1:10:05 PM7/3/21
to
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
> 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
The Wanderer
Jul 3, 2021, 1:10:05 PM7/3/21
to
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.
> 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.
just deleting the files from under /boot directly.
> I was thinking then to remove the unwanted modules to make the
> kernels smaller.
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 ?
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.
IL Ka
Jul 3, 2021, 1:10:05 PM7/3/21
to
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
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
Greg Wooledge
Jul 3, 2021, 1:20:04 PM7/3/21
to
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.
> 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
> be used by software for monitoring the PC hardware.
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
> smaller.
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.
The Wanderer
Jul 3, 2021, 1:40:05 PM7/3/21
to
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.
> 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.
>
> ?
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.
David Wright
Jul 3, 2021, 1:40:05 PM7/3/21
to
On Sat 03 Jul 2021 at 17:50:44 (+0100), mick crane wrote:
$ ls -GlG /boot/
total 109828
-rw-r--r-- 1 root 3421023 Mar 19 09:29 System.map-4.19.0-16-amd64
-rw-r--r-- 1 root 3421235 Jun 21 03:46 System.map-4.19.0-17-amd64
-rw-r--r-- 1 root 206242 Mar 19 09:29 config-4.19.0-16-amd64
-rw-r--r-- 1 root 206214 Jun 21 03:46 config-4.19.0-17-amd64
drwx------ 3 root 4096 Dec 31 1969 efi
drwxr-xr-x 5 root 4096 Jun 23 13:47 grub
-rw-r--r-- 1 root 31149360 Mar 27 13:03 initrd.img-4.19.0-16-amd64
-rw-r--r-- 1 root 32309222 Jun 26 18:28 initrd.img-4.19.0-17-amd64
-rw-r--r-- 1 root 31156713 Jun 23 13:47 initrd.img-4.19.0-17-amd64.bak
-rw-r--r-- 1 root 5287168 Mar 19 09:29 vmlinuz-4.19.0-16-amd64
-rw-r--r-- 1 root 5283072 Jun 21 03:46 vmlinuz-4.19.0-17-amd64
$
So it's obvious that you need to concentrate your attention on the
initrd files. You could remove any .bak file, and even not generate
any by setting
backup_initramfs=no
in /etc/initramfs-tools/update-initramfs.conf, but you could also
save space by not storing all the modules in your initrd files.
Do this by setting
MODULES=dep
in /etc/initramfs-tools/initramfs.conf
and rebuilding it with update-initramfs.
MODULES=dep will mean that if you change your booting method,
there's a chance it could fail. In which case, you'd first boot
with the old method and rebuild an initrd with MODULES=most.
When you make these changes, just check for any parameters set in
files in /etc/initramfs-tools/conf.d because they take priority.
Cheers,
David.
> 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.
> 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".
> 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".
> 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.
> 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.
> smaller.
> There is for example a few filesystem modules like msdos which would
> be needed if I wanted to mount an msdos filesystem.
> be needed if I wanted to mount an msdos filesystem.
> Seem to remember "insmod" a module if and when needed.
>
>
> If remove modules from kernel are the gone or are they still on disk
> and could be put back ?
OK, you're short of space in /boot. Here's mine.
> and could be put back ?
$ ls -GlG /boot/
total 109828
-rw-r--r-- 1 root 3421023 Mar 19 09:29 System.map-4.19.0-16-amd64
-rw-r--r-- 1 root 3421235 Jun 21 03:46 System.map-4.19.0-17-amd64
-rw-r--r-- 1 root 206242 Mar 19 09:29 config-4.19.0-16-amd64
-rw-r--r-- 1 root 206214 Jun 21 03:46 config-4.19.0-17-amd64
drwx------ 3 root 4096 Dec 31 1969 efi
drwxr-xr-x 5 root 4096 Jun 23 13:47 grub
-rw-r--r-- 1 root 31149360 Mar 27 13:03 initrd.img-4.19.0-16-amd64
-rw-r--r-- 1 root 32309222 Jun 26 18:28 initrd.img-4.19.0-17-amd64
-rw-r--r-- 1 root 31156713 Jun 23 13:47 initrd.img-4.19.0-17-amd64.bak
-rw-r--r-- 1 root 5287168 Mar 19 09:29 vmlinuz-4.19.0-16-amd64
-rw-r--r-- 1 root 5283072 Jun 21 03:46 vmlinuz-4.19.0-17-amd64
$
So it's obvious that you need to concentrate your attention on the
initrd files. You could remove any .bak file, and even not generate
any by setting
backup_initramfs=no
in /etc/initramfs-tools/update-initramfs.conf, but you could also
save space by not storing all the modules in your initrd files.
Do this by setting
MODULES=dep
in /etc/initramfs-tools/initramfs.conf
and rebuilding it with update-initramfs.
MODULES=dep will mean that if you change your booting method,
there's a chance it could fail. In which case, you'd first boot
with the old method and rebuild an initrd with MODULES=most.
When you make these changes, just check for any parameters set in
files in /etc/initramfs-tools/conf.d because they take priority.
Cheers,
David.
The Wanderer
Jul 3, 2021, 1:40:05 PM7/3/21
to
On 2021-07-03 at 13:28, mick crane wrote:
> On 2021-07-03 18:03, The Wanderer 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.
>
>>> 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.
>
Hans
Jul 3, 2021, 2:10:04 PM7/3/21
to
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
Hi all,
> I was thinking then to remove the unwanted modules to make the kernels
>
> > smaller.
>
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
Greg Wooledge
Jul 3, 2021, 2:10:04 PM7/3/21
to
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.
> 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.
Stefan Monnier
Jul 3, 2021, 2:30:04 PM7/3/21
to
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
> 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.
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
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
Sven Hartge
Jul 3, 2021, 2:50:04 PM7/3/21
to
Hans <hans.u...@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
> 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)
auto-loaded. Serves the same purpose without needing to manually build
update Kernels.
S°
--
Sigmentation fault. Core dumped.
Brian
Jul 3, 2021, 3:10:04 PM7/3/21
to
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.
[...]
> 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.
Stefan Monnier
Jul 3, 2021, 4:40:04 PM7/3/21
to
> 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:
> 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.
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
Tom Dial
Jul 3, 2021, 11:10:05 PM7/3/21
to
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?
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
> Next time - don't have a separate boot partition. You will be happier.
with everything except /boot on encrypted media.
Regards,
Tom Dial
>
Brian
Jul 4, 2021, 5:10:05 AM7/4/21
to
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
>
>
> 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.
kernel, but as time goes on there is surely less need for it?
--
Brian.
Tixy
Jul 4, 2021, 8:50:05 AM7/4/21
to
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
David Wright
Jul 4, 2021, 11:30:05 AM7/4/21
to
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
> 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.
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.
David.
Brian
Jul 4, 2021, 2:50:04 PM7/4/21
to
times with the new kernel. What need is there for a second kernel on
the system?
--
Brian.
Brad Rogers
Jul 4, 2021, 3:20:04 PM7/4/21
to
On Sun, 4 Jul 2021 19:42:26 +0100
Brian <ad...@cityscape.co.uk> wrote:
Hello Brian,
>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?
Clearly, you haven't understood what Tixy wrote.
--
Regards _
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Cocaine, heroin, I never use speed, I never put the needle in
Keep it Clean - The Vibrators
Brian <ad...@cityscape.co.uk> wrote:
Hello Brian,
>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?
--
Regards _
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Cocaine, heroin, I never use speed, I never put the needle in
Keep it Clean - The Vibrators
Brian
Jul 4, 2021, 4:20:05 PM7/4/21
to
On Sun 04 Jul 2021 at 20:16:25 +0100, Brad Rogers wrote:
> On Sun, 4 Jul 2021 19:42:26 +0100
> Brian <ad...@cityscape.co.uk> wrote:
>
> Hello Brian,
>
> >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?
>
> Clearly, you haven't understood what Tixy wrote.
Maybe I didn't. But your comment doesn't clarfify anything.
> On Sun, 4 Jul 2021 19:42:26 +0100
> Brian <ad...@cityscape.co.uk> wrote:
>
> Hello Brian,
>
> >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?
>
> Clearly, you haven't understood what Tixy wrote.
Care to add anything worthewhile?
--
Brian.
David Wright
Jul 5, 2021, 1:00:05 AM7/5/21
to
On Sun 04 Jul 2021 at 21:12:10 (+0100), Brian wrote:
> On Sun 04 Jul 2021 at 20:16:25 +0100, Brad Rogers wrote:
> On Sun 04 Jul 2021 at 20:16:25 +0100, Brad Rogers wrote:
> > On Sun, 4 Jul 2021 19:42:26 +0100 Brian wrote:
> > >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?
> >
> > Clearly, you haven't understood what Tixy wrote.
>
> Maybe I didn't. But your comment doesn't clarfify anything.
> Care to add anything worthwhile?
> > >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?
> >
> > Clearly, you haven't understood what Tixy wrote.
>
> Maybe I didn't. But your comment doesn't clarfify anything.
I think the point that's being made is illustrated by recent upgrades
to amd64 buster.
linux-image-4.19.0-16-amd64_4.19.181-1_amd64.deb was issued Mar27,
then linux-image-4.19.0-17-amd64_4.19.194-1_amd64.deb Jun19.
So if by Jun22 one was happy with the latter, then you're suggesting
one remove the former.
Now on Jun23, linux-image-4.19.0-17-amd64_4.19.194-2_amd64.deb becomes
available. When you run upgrade, this kernel will overwrite the Jun19
version. If Jun23 hits a snag when booting, you've got no version 16
to fall back on.
Cheers,
David.
Brian
Jul 5, 2021, 6:10:05 AM7/5/21
to
--
Brian.
0 new messages