Re: removing modules
On Sun 04 Jul 2021 at 23:53:15 -0500, David Wright wrote: > 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, 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 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. Thanks. The illustration did the trick. -- Brian.
Re: removing modules
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, 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 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.
Re: removing modules
On Sun 04 Jul 2021 at 20:16:25 +0100, Brad Rogers wrote: > On Sun, 4 Jul 2021 19:42:26 +0100 > Brian 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. Care to add anything worthewhile? -- Brian.
Re: removing modules
On Sun, 4 Jul 2021 19:42:26 +0100 Brian 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 pgpRtnUCXhXA3.pgp Description: OpenPGP digital signature
Re: removing modules
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.
Re: removing modules
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.
Re: removing modules
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
Re: removing modules
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.
Re: removing modules
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 >
Re: removing modules
> 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- | sort -n +4 to see the parts of the initrd that are likely to take most of the space. Stefan
Re: removing modules
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
Re: removing modules
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.
Re: removing modules
Hans 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.
Re: removing modules
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 root12288 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.
Re: removing modules
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
Re: removing modules
On 2021-07-03 18:12, Greg Wooledge wrote: 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. This is definitely a PC so this must be the installer thinking it might be a laptop. 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. this is after deleting the very oldest. 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 root12288 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 root@pumpkin:/boot# du -h /boot 12K /boot/lost+found 2.1M/boot/grub/i386-pc 2.3M/boot/grub/fonts 4.3M/boot/grub/locale 11M /boot/grub 157M/boot root@pumpkin:/boot# df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/sdb1 236M 159M 65M 71% /boot Can I not *just* move the older ones out of the way so upgrade doesn't run out of space ? mick -- Key ID4BFEBB31
Re: removing modules
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. > > what happens if I might remove them by 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 signature.asc Description: OpenPGP digital signature
Re: removing modules
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. > > what happens if I might remove them by 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 signature.asc Description: OpenPGP digital signature
Re: removing modules
On Sat 03 Jul 2021 at 17:50:44 (+0100), mick crane wrote: > On 2021-07-03 17:29, The Wanderer wrote: > > 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. > > 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". > 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. > 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. > > 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. $ 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.
Re: removing modules
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. what happens if I might remove them by deleting them ? I don't see any option from grub for booting different kernels. mick -- Key ID4BFEBB31
Re: removing modules
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.
Re: removing modules
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
Re: removing modules
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 signature.asc Description: OpenPGP digital signature
Re: removing modules
> > > 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 >
Re: removing modules
On 2021-07-03 17:29, The Wanderer wrote: 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. 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". 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. 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. If remove modules from kernel are the gone or are they still on disk and could be put back ? mick -- Key ID4BFEBB31
Re: removing modules
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 signature.asc Description: OpenPGP digital signature
Re: 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 ? > 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)
Re: removing modules
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 Reco
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 ID4BFEBB31
Re: Removing modules and base
On Thu, 7 Aug 1997, Joost Kooij wrote: On Wed, 6 Aug 1997, Johann Spies wrote: What does dpkg print when it tries to upgrade modutils? The output of dpkg -i was: ... /var/lib/dpkg/info/modutils.prerm: /etc/init.d/kerneld: No such file or directory ... /var/lib/dpkg/tmp.ci/prerm: /etc/init.d/kerneld: No such file or directory update-rc.d: warning /etc/init.d/kerneld doesn't exist during rc.d setup. /var/lib/dpkg/info/modutils.postinst: /etc/init.d/kerneld: No such file or directory dpkg: error while cleaning up: subprocess post-installation script returned error exit status 126 Strange.. on my box: $dpkg -S kerneld .. modutils: /sbin/kerneld modutils: /etc/init.d/kerneld .. Could you check if these files do actually exist on your system? (What is in your /etc/init.d/kerneld? mine is in fact empty.) If not, doing touch /etc/init.d/kerneld and then retrying dpkg -i modutils_2.1.34-5.deb might solve your problem. Thanks. This information helped me to solve the problem. Johann. Johann Spies [EMAIL PROTECTED] Windsorlaan 19 Pietermaritzburg 3201 Suid Afrika (South Africa) Tel. Nr. 0331-46-1310 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Removing modules and base
Please excuse me if this has been answered before. I received my Debian 1.3.1 CD, borrowed a cdrom-drive and installed 1.3.1. Dselect refuses to remove modules and base and as a result shows modutils 2.1.35-5 as broken and base 1.1.0-13 as obsolete. How can I solve this problem? Johann. Johann Spies [EMAIL PROTECTED] Windsorlaan 19 Pietermaritzburg 3201 Suid Afrika (South Africa) Tel. Nr. 0331-46-1310 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Removing modules and base
On Tue, 5 Aug 1997, Joost Kooij wrote: On Tue, 5 Aug 1997, Johann Spies wrote: Please excuse me if this has been answered before. I received my Debian 1.3.1 CD, borrowed a cdrom-drive and installed 1.3.1. Dselect refuses to remove modules and base and as a result shows modutils 2.1.35-5 as broken and base 1.1.0-13 as obsolete. How can I solve this problem? Whatever you do, DO NOT PURGE BASE!! Then you will have a real problem. Even if dselect says it is obsolete, it still owns vital parts of your system (try dpkg -L base and see for yourself.) So, DO NOT PURGE BASE!! You could: - ignore what dselect indicates. - delve into the dpkg database and remove all references to base. IIRC this was described lately. - wait for the maintainer of the package to issue a final base.deb, consisting of merely install scripts that will perform the abovementioned cleaning. The way to remove base is to cd into /var/lib/dpkg/info and open up base.list in your favorite text editor. You should then remove all references to devices. i.e delete all /dev/ files. You should then be able to remove base safely. Shaya -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Removing modules and base
On Tue, 5 Aug 1997, Johann Spies wrote: Please excuse me if this has been answered before. I received my Debian 1.3.1 CD, borrowed a cdrom-drive and installed 1.3.1. Dselect refuses to remove modules and base and as a result shows modutils 2.1.35-5 as broken and base 1.1.0-13 as obsolete. How can I solve this problem? Whatever you do, DO NOT PURGE BASE!! Then you will have a real problem. Even if dselect says it is obsolete, it still owns vital parts of your system (try dpkg -L base and see for yourself.) So, DO NOT PURGE BASE!! You could: - ignore what dselect indicates. - delve into the dpkg database and remove all references to base. IIRC this was described lately. - wait for the maintainer of the package to issue a final base.deb, consisting of merely install scripts that will perform the abovementioned cleaning. What does dpkg print when it tries to upgrade modutils? Joost -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Removing modules and base
On Tue, 5 Aug 1997, Joost Kooij wrote: On Tue, 5 Aug 1997, Johann Spies wrote: ... I received my Debian 1.3.1 CD, borrowed a cdrom-drive and installed 1.3.1. Dselect refuses to remove modules and base and as a result shows modutils 2.1.35-5 as broken and base 1.1.0-13 as obsolete. How can I solve this problem? Whatever you do, DO NOT PURGE BASE!! Then you will have a real problem. Even if dselect says it is obsolete, it still owns vital parts of your system (try dpkg -L base and see for yourself.) So, DO NOT PURGE BASE!! ... What does dpkg print when it tries to upgrade modutils? The output of dpkg -i was: Preparing to replace modutils 2.1.34-5 (using .../base/modutils_2.1.34-5.deb) ... /var/lib/dpkg/info/modutils.prerm: /etc/init.d/kerneld: No such file or directory dpkg: warning - old pre-removal script returned error exit status 1 dpkg - trying script from the new package instead ... /var/lib/dpkg/tmp.ci/prerm: /etc/init.d/kerneld: No such file or directory dpkg: error processing /cdrom/bo/binary-i386/base/modutils_2.1.34-5.deb (--install): subprocess new pre-removal script returned error exit status 1 update-rc.d: warning /etc/init.d/kerneld doesn't exist during rc.d setup. /var/lib/dpkg/info/modutils.postinst: /etc/init.d/kerneld: No such file or directory dpkg: error while cleaning up: subprocess post-installation script returned error exit status 126 Johann. Johann Spies [EMAIL PROTECTED] Windsorlaan 19 Pietermaritzburg 3201 Suid Afrika (South Africa) Tel. Nr. 0331-46-1310 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Removing modules and base
On Wed, 6 Aug 1997, Johann Spies wrote: What does dpkg print when it tries to upgrade modutils? The output of dpkg -i was: Preparing to replace modutils 2.1.34-5 (using .../base/modutils_2.1.34-5.deb) ... /var/lib/dpkg/info/modutils.prerm: /etc/init.d/kerneld: No such file or directory dpkg: warning - old pre-removal script returned error exit status 1 dpkg - trying script from the new package instead ... /var/lib/dpkg/tmp.ci/prerm: /etc/init.d/kerneld: No such file or directory dpkg: error processing /cdrom/bo/binary-i386/base/modutils_2.1.34-5.deb (--install): subprocess new pre-removal script returned error exit status 1 update-rc.d: warning /etc/init.d/kerneld doesn't exist during rc.d setup. /var/lib/dpkg/info/modutils.postinst: /etc/init.d/kerneld: No such file or directory dpkg: error while cleaning up: subprocess post-installation script returned error exit status 126 Strange.. on my box: $dpkg -S kerneld .. modutils: /sbin/kerneld modutils: /etc/init.d/kerneld .. Could you check if these files do actually exist on your system? (What is in your /etc/init.d/kerneld? mine is in fact empty.) If not, doing touch /etc/init.d/kerneld and then retrying dpkg -i modutils_2.1.34-5.deb might solve your problem. If it still doesn't work, (lame answer follows:) look at the scripts /var/lib/dpkg/info/modutils* and see if you can figure out what goes wrong. You'll learn a lot about the intricacies of your favorite linux distribution ;-) Good luck, Joost -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
