Suppressing insmod's warning at initrd time (module is from the staging directory, the quality is unknown, you have been warned.)

I have built a 'hugefied' generic kernel, by making an initrd with all the modules built in the huge kernel, which are not built in the generic kernel.

The resulting kernel turned out to be 34M in size, grub (but not elilo) bootable. It boots successfully, but there is a problem that in a few places during the bootup process it stops for user input, which makes unattended reboots impossible.

In particular, the boot process gets paused at the following lines, right after insmod:

module is from the staging directory, the quality is unknown, you have been warned.

Well, this is not very useful, since when the module is built into the kernel, it's loaded together with the kernel any way.

So my question is: how do I remove this pause during the boot process?

I didn't manage to reproduce this on a fully booted system. (I unpacked the initrd skeleton from /usr/share/mkinitrd, and used busybox insmod from there.)

./busybox insmod /lib/modules/4.19.69/kernel/drivers/staging/media/zoran/videocodec.ko

The actual module doesn't matter, it does give a warning in the dmesg, but doesn't wait before continuing.

Apparently the issue is not with busybox-insmod. But then with what?

It's an interesting project, if you enjoy that. 34M? Really? Is that

make allyesconfig

The 4.19.34 kernel I built for this box is 4.4M. There's no initrd. You only need the stuff available to the kernel between kernel & initrd that gets / mounted ro, because after that it will have access to /lib/modules. Now with the driver for my kernel, my cpu and my chipset compiled in, There's little else I need. Now I appreciate the kernel may have more compiled in than that, for things like X & peripheral stuff, and mine certainly does. But even lib/modules/4.19.34 for my kernel is only 24M, because what use is a module I will never use?

The staging directory I thought was for devs & crashtesters with the latest gear to experiment with the latest drivers. My recommendation would be to leave it out. It's all alpha & beta stuff.

Originally Posted by business_kid It's an interesting project, if you enjoy that. 34M? Really? Is that make allyesconfig The 4.19.34 kernel I built for this box is 4.4M. There's no initrd. You only need the stuff available to the kernel between kernel & initrd that gets / mounted ro, because after that it will have access to /lib/modules. Now with the driver for my kernel, my cpu and my chipset compiled in, There's little else I need. Now I appreciate the kernel may have more compiled in than that, for things like X & peripheral stuff, and mine certainly does. But even lib/modules/4.19.34 for my kernel is only 24M, because what use is a module I will never use? The staging directory I thought was for devs & crashtesters with the latest gear to experiment with the latest drivers. My recommendation would be to leave it out. It's all alpha & beta stuff.

Man, do you understand that you're now telling Patrick Volkerding how to build a kernel?

This setup has nothing at all in common with the

make allyesconfig

. This setup is literally diff'ing the results of

find

for the module directories produced by the huge kernel config and the generic kernel config. The generic config has ~300 modules, the huge one has about 195, so the difference is really 102 modules having the combined weight of about 15 megabytes. The only difference I made to the generic's .config is:

CONFIG_INITRAMFS_SOURCE="/boot/initrd-tree/"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_INITRAMFS_COMPRESSION=".gz"

I didn't add anything from the "staging" directory, Patrick did, and he was right, because even if the speakup module is still "staging" after all the years, it doesn't mean it is useless. Oftentimes it is the only way to get any information from a machine without a display.

I am astonished how badly people read what's really given in two shapes -- in the shape of a forum post, and the attached script.

Originally Posted by Lockywolf Man, do you understand that you're now telling Patrick Volkerding how to build a kernel?

No he is not. He is trying to get to grips with what you are attempting to do. Which is a totally useless effort if you ask me. Unless you can explain why you do what you do?
Also, I can not understand how you create a 34 MB kernel? The script you attached creates a generic kernel at the end (based on config-generic-4.19.69.x64) and that one is apparently the kernel you boot. Am I missing something here perhaps? All you seem to have done extra was create a big fat initrd with all modules for drivers that are built into the huge kernel but not into the generic kernel.

I didn't add anything from the "staging" directory, Patrick did, and he was right, because even if the speakup module is still "staging" after all the years, it doesn't mean it is useless. Oftentimes it is the only way to get any information from a machine without a display. I am astonished how badly people read what's really given in two shapes -- in the shape of a forum post, and the attached script.

You might need a better understanding of the existence of the huge and generic kernels, and the goal of an initrd.
A kernel needs to be able to load support for all hardware in your computer, and it needs to make the root filesystem accessible to the 'userspace' programs. A huge kernel has all that support built in with the purpose of being able to boot any computer, recognize all hardware components, and let you install Slackware onto it. The Linux kernel probes the hardware and loads the drivers when needed. It will never load code it is not required to load (say, for hardware you do have installed into the computer).
A generic kernel does not have all this hardware support built in, which allows it to be smaller and load faster. It then relies on an initrd which contains the kernel drivers and support programs to initialize all your hardware and make the root fileystem available to init. By 'support programs' you should think of the programs that can unlock a LUKS volume, or assemble a RAID array, or make Logical Volumes available.

What you effectively do by dumping all of these extra modules into an initrd, is force an "insmod" for every module you added. This way, all the drivers are forcibly loaded into the kernel and probably most of these are totally irrelevant to your hardware.
The result: a system which loads a lot slower (because all these modules are going to initialize themselves) and errors when you load a module that was not supposed to be loaded forcibly.

Again, try telling us why you are doing this.

Originally Posted by Lockywolf CONFIG_INITRAMFS_SOURCE="/boot/initrd-tree/" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_INITRAMFS_COMPRESSION=".gz"

I assume this "CONFIG_INITRAMFS_SOURCE" definition is what creates your big kernel. You are basically instructing the kernel build to add a copy of your initrd to the end of the kernel image file, so you do not have to specify separate kernel and initrd filenames to your bootloader.
With that cleared up, the previous post is still 100% relevant.

Originally Posted by Alien Bob It will never load code it is not required to load (say, for hardware you do have installed into the computer).

Any justification to this claim? It is a huge kernel, that has all these modules built-in. Of course it loads all the code, unless proven otherwise.

Unless you can explain why you do what you do?

I want a kernel image that has the flexibility of a huge one (i.e. contains all the "stuff" needed to boot on all hardware the huge kernel would boot), but does not _load_ the useless stuff just because this stuff is compiled-in. I am writing "stuff", not "code", because there is also some firmware, which is not used by the kernel itself, so can be considered data, not code.

This setup accomplishes half of this goal: the image that consists of the kernel binary plus the initrd appended at the end should be able to boot on everything on what the huge kernel boots. The second half of the task is _not_ solved, since indeed the initrd created by mkinitrd insmods everything as soon as an initrd is loaded. I guess I would need to tune up the initrd's internal udev, which is installed by mkinitrd -u, but that's another story.

At the moment I need to shut up this weird "staging" warning for the speakup code. The speakup code doesn't have much to do with hardware, and is compiled into the huge kernel, so I want it in my setup too.

Originally Posted by Lockywolf Any justification to this claim? It is a huge kernel, that has all these modules built-in. Of course it loads all the code, unless proven otherwise.

The whole kernel image loads into RAM, just like the initrd. Up to this point, there is no difference between any kernel/initrd permutation.

But then the kernel boots. It checks all the hardware in the system, and determines what drivers to load in order to probe and initialize the hardware components. Here the difference starts.
A huge kernel has all the drivers built-in so the kernel runs the driver code which fits with the discovered hardware. All the other driver code in that huge kernel is never run.
A generic kernel will at some point determine that it requires to run a driver which was built as a module. The kernel module loader will handle the driver loading dynamically. But again, only those driver modules that the kernel determined are actually needed for initializing the hardware.
The Slackware initrd contains a script, called "init", which will run when the initrd is loaded into RAM. The script will run "insmod" against every module in the initrd, which is different from how a kernel would load a driver on-demand, fir instance when you plugin a USB device during run-time.
The Slackware initrd is supposed to only contain the modules that you actually need to make the root filesystem available. The kernel will take care of all the rest after the init script inside the initrd finishes. All these modules you put in there, they are not needed during initial boot.

I want a kernel image that has the flexibility of a huge one (i.e. contains all the "stuff" needed to boot on all hardware the huge kernel would boot), but does not _load_ the useless stuff just because this stuff is compiled-in. I am writing "stuff", not "code", because there is also some firmware, which is not used by the kernel itself, so can be considered data, not code. This setup accomplishes half of this goal: the image that consists of the kernel binary plus the initrd appended at the end should be able to boot on everything on what the huge kernel boots. The second half of the task is _not_ solved, since indeed the initrd created by mkinitrd insmods everything as soon as an initrd is loaded. I guess I would need to tune up the initrd's internal udev, which is installed by mkinitrd -u, but that's another story. At the moment I need to shut up this weird "staging" warning for the speakup code. The speakup code doesn't have much to do with hardware, and is compiled into the huge kernel, so I want it in my setup too.

Well, the way Pat builds the Slackware kernel and allows you to create an initrd, is the right way to achieve what you want. You are complicating things for no reason.