Solved Generic or targeted initrd?

Solved issue

CaffeineAddict

Well-Known Member
Joined
Jan 21, 2024
Messages
479
Reaction score
307
Credits
3,974
I have choosed generic initrd during installation due to lack of understanding..
Now I'm currious to know the difference in detail, if we choose targeted inird that means only modules for detected hardware is included right?

Does this mean that if we attach additional hardware such as microphone, camera, keyboard, mouse etc. then we might be missing drivers for the new hardware?
What options are there to install missing modules then if targeted inird is choosen? how do you find drivers and install them?

Since I'm using Debian and have no plans to use any other distro any time soon feel free to limit your answers to installing drivers on Debian with targeted initrd.

Is there anything else I need to know if using targeted initrd?
 


The generic initrd includes a greater number of commonly found modules that are in common usage, whereas the targeted initrd is smaller and includes just the hardware that has been found by the kernel at the time of creation of the initrd file. Your description is accurate.

Does this mean that if we attach additional hardware such as microphone, camera, keyboard, mouse etc. then we might be missing drivers for the new hardware?

In relation to the keyboard and mouse, the kernel has a wide selection of drivers which cover what is in common usage, so drivers for those would not usually be required to be compiled and lodged in the drivers directories by the user. One can see the range of what's in the kernel in relation to keyboard and mice with a command like:
Code:
ls /lib/modules/$(uname -r)/kernel/drivers/hid

For more specialised keyboard and mice, special drivers may need to be built.

What options are there to install missing modules then if targeted inird is choosen? how do you find drivers and install them?

For some cameras and microphones and other peripheral hardware, there may or may not be appropriate drivers in the kernel so the user may need to build them if they are absent.

In general, for any drivers not in the kernel, they can often be found on sites like github, codeberg, or on manufacturer's websites, or other sites developers choose to distribute their work. They may provide source code or binaries for these things.

To take one common example, wifi drivers have a limited range of drivers in the linux kernel, so the user may need to source the code. Together with that code usually comes the instructions for compiling and installing the driver, including the dependencies and other necessary details. For debian it usually means that the user needs the "build-essential" tools installed which can do the compiling and installation.

When modules are built and installed, it's usually not necessary to renew the initrd image, since once the kernel recognises the module under the /lib/modules directory, and the hardware is attached, it will usually load the module during boot. If it doesn't, the user can configure the module's loading with entries in /etc/modules-load.d/. In debian, each upgrade of the kernel will create a new initrd image, so that part of the system is usually taken care of automatically.

The targeted initrd supports the minimalist approach to installation of operating systems, and is often relevant for embedded systems where small size of software is useful or important or critical. For ordinary usage on relatively modern hardware from the last few years, the user gets little or no detectable advantage from such a minimalist approach. YMMV.
 
For ordinary usage on relatively modern hardware from the last few years, the user gets little or no detectable advantage from such a minimalist approach.
I'm thinking about this, it makes sense to have additional drivers if needed already installed..

during installment there is a warning saying that initrd might be so big some bootloaders might fail to load it.
I don't have this problem but I notice it takes a few seconds like 4 sec to load it during boot.
beside this I see no other disadvantage, if that should be called disadvantage at all IDK, but fast boot is not bad either.

EDIT:
generic initrd is 64 MiB while targeted one is 20 MiB, I checked it in VM
That's not huge difference for additional drivers, you're right!
 
Last edited:
I'm thinking about this, it makes sense to have additional drivers if needed already installed..

during installment there is a warning saying that initrd might be so big some bootloaders might fail to load it.
I don't have this problem but I notice it takes a few seconds like 4 sec to load it during boot.
beside this I see no other disadvantage, if that should be called disadvantage at all IDK, but fast boot is not bad either.

EDIT:
generic initrd is 64 MiB while targeted one is 20 MiB, I checked it in VM
That's not huge difference for additional drivers, you're right!
It's possible to decrease the size of the current initrd through configuration. Altering the config: MODULES=most, in the /etc/initramfs-tools/initramfs.conf, to: MODULES=dep, and then renewing the initrd image with a command like:

Code:
update-initramfs -u -k <kernel-version-number>-amd64
Then update grub.

There's always a slight chance that a necessary driver is not included, so that's a caveat. I guess I'd back up the original in that case.
 
It's possible to decrease the size of the current initrd through configuration.
Thank you for sharing this solution, it's good to know how it's done.
I've decided to go with your previous post and stick with generic one because it makes sense.

And thank you for explanation, I finally understand the difference.
 

Members online


Top