In the end, working with devices on Linux is all about working with kernel modules.
Because for every device that you are using, a kernel module is required.
Kernel modules are loaded first through init-ramfs or init-rd while you are booting.
Init-ramfs or init-rd are system specific and they are automatically generated at the
end of the installation to make sure that you have all the configuration that you need
inside.
Where init-ramfs is what you will find on Red Hat oriented Linux and init-rd is the
equivalent on Ubuntu.
You can find the result in the slash boot directory.
If ever you need to manually trigger the generation of an init-ramfs, you use DRAKUT.
That's a Red Hat utility.
Now the big question is, why would you want to do that?
Well, you might want to do that if you have just installed this fancy new GPU card in
your system, for instance.
Then your init-ramfs won't know about it and you need to regenerate it.
Use DRAKUT or DRAKUT-F to force it.
To do the equivalent on Ubuntu, you use mkinitramfs.
Now when you are booting, systemd starts systemd-udevd to manage on-demand loading of kernel modules.
So when you plug in a USB thumb drive that contains a VFAT file system which hasn't been
mounted yet, well, systemd-udevd makes sure that the VFAT kernel module will be loaded.
And manual loading can be done as well using modprobe and the deprecated intmod command.
But you will notice that the automatic procedure is so good that you rarely will use modprobe
to manually load kernel modules.
Nevertheless, let's discuss how it works.
So if you want to see if manual loading is necessary, first you need to find out if your
device already has a kernel module.
lspci-k is an awesome command to find out.
Next you can get kernel module parameters.
Use modinfo on the kernel module that you want to use.
And then modprobe can be used to manually load the modules, including all of their dependencies.
To do the opposite, use modprobe-r.
That will remove manually loaded kernel modules.
And these kernel module dependencies, well, there is depmod.
And depmod is a process that runs to automatically generate kernel module dependencies.
Normally you don't have to worry about depmod, but if ever you are loading a kernel module
and you feel you are missing a dependency, it doesn't hurt to run the depmod utility
manually.
In old Linux releases, insmod and rmmod were used, but these really are deprecated nowadays.
Final thing you need to know about kernel modules is that they can come with kernel
module parameters.
Modinfo is what you use to find available parameters.
And you can specify the parameters in etcmodprobe.conf and or in drop-in files in etcmodprobe.d.
And alternatively, you can use a parameter name followed by its value as an argument
while manually loading the parameter.
Now messages about loading parameters are not consistent.
And as a result, it can be hard to find out if your kernel module has correctly identified
the parameter.
But you can give it a try using dmessage or files in sysmodules.
Let me show you, and let me show you specifically how we can use kernel module parameters.
I'm using lsmod.
lsmod is giving a list of all the kernel modules that are currently loaded.
And I'm going for cdrom.
That's a relatively innocent kernel module.
We can see the cdrom as a kernel as a lot of dependencies, and we can see them right
here, like srmod.
srmod is a SCSI cdrom module, which is backing the cdrom module.
Now if I want to know what is going on, I'm using modinfo.
On cdrom, and modinfo is showing me a list of parameters.
And I'm going for the parameter debug, which is a boolean.
Debug is logging additional information if anything is happening to the dmessage output.
So I want cdrom to be loaded with the parameter debug is 1.
Boolean is an on-off value, so typically 0 and 1 would work.
I'm going into etcmodprobe.d because etcmodprobe.d contains a couple of example files.
And I do not want anything that is a blacklist.
Oh, we only have blacklists?
Blacklists are to prevent the loading of specific kernel modules.
I don't want them.
So I'm going to have a look at usrlibmodprobe.d.
So remember, etc is for the customization.
Usrlib is for the standard stuff.
And maybe we have something in the standard configuration that I do like.
And there I can see a potential candidate, this ALSA.
This ALSA is for the ALSA sound module.
And there we can see some options.
Well, honestly, I also don't like it.
Now what are we going to do?
Well, man-kmodprobe, I want to know if there is any decent documentation about modprobe.conf.
So man on modprobe.conf.
Let's check it out to see if we have anything that we can do in here.
So we have install.
I don't care about install because install is for running a specific command.
I care about options.
This is the one I need.
So we need options, CD-ROM debug is one, finally.
So vim on etc modprobe.d CD-ROM.conf.
And I'm going to put in options, CD-ROM debug is one.
And that should be doing it.
All right.
Now I'm going to use modprobe-r CD-ROM.
I'm trying to unload CD-ROM, but unfortunately, CD-ROM is in use.
Okay.
That means that it is automatically started and I'm going to reboot.
And after the reboot, we are going to see if we can find anything about these options.
So now we are back and I'm going to use dmessage, pipe less,
because less allows me to search for it.
And I'm searching for CD-ROM.
And here we can see CD-ROM, that's not very much information.
And N isn't giving me anything either.
Now, as I mentioned before, it's not always easy to find information about parameters.
The other choice that you've got is in the sysmodules file system.
You go to CD-ROM and there you might have a subdirectory with the name parameters.
I don't, so apparently this module doesn't clearly keep track of its parameters.
Too bad, but that's the way it is.