Any Idea how to get a small(est) Kernel?

H

hruodr

I compiled MINIMAL, but boot crashes, at least boot with pxe. It had about 8MB, compared to 27 MB of 11.2 GENERIC.

I need it for faster booting with slow USB or pxeboot.

I thank for any hint.
 
Start with a GENERIC kernel, remove some things, test. Remove more, test again. Repeat until there's nothing left to remove.
 
What does "boot crashes" mean? Without any more information, all we can tell you that your custom kernel either is configured wrong, or built wrong, or something else is wrong. If you give us the detailed error message, we might be able to diagnose the problem . Matter-of-fact, if you write down the detailed error message, and type it into the forum, I'm going to bet that suddenly the problem will become clear to you and you can fix it yourself.

I also think that the exercise of reducing the kernel size is probably not very useful in terms of overall time saving. Let's assume that you are booting over Ethernet (PXE), and using 100 base T, which runs at roughly 10MB/s. Or maybe reading from a USB stick, let's assume USB-2, and those tend to run at 10-30 MB/s. In that case, the ~20 MB of space you are saving will end up a 2 second saving. Your whole boot process is probably around a minute, and the amount of data to be read is dominated by other things. Putting much time into shrinking the kernel is probably not a good investment.
 
ralphbsz said:
you are saving will end up a 2 second saving.
Click to expand...

That is the result of calculations, not empiric results. It takes indeed less time to load. The question ist: why?

Booting with PXE, I cannot see error messages. The last lines I manage to read are:

SMP ...
Timecounter ...
 
I have an almost minimal Kernel, 9796624 bytes, that works if I have in kernel config file:

Code: 
device          miibus
device          re

and does not work if I do not have them, also not putting in loader.conf:

Code: 
miibus_load="YES"
if_re_load="YES"
 
hruodr said:
I have an almost minimal Kernel, 9796624 bytes, that works if I have in kernel config file: ...
and does not work if I do not have them, ...
Click to expand...
What is the ethernet controller hardware on your computer? re(4) is the device driver for a common ethernet adaptor, and miibus(4) is the device driver for the framework for talking to the media interface (the thing that controls whether the wire is 10bt or 100bt and such). If your hardware needs those drivers, and you don't have them, then at some point during the boot process you will lose ethernet access, and that's the end of booting.

In theory it should work to have them built as modules and put them into loader.conf (at least I think it should), but doing kernel modules can be error-prone for the inexperienced, so I would compile them in. If your custom kernel is hardware-specific, that is also likely to be the fastest option: either way you will have to load them from "disk" (really USB or network) sooner or later, and if they are compiled in, you're saving two extra file lookups and opens during the boot process.
 
I would presume that PXE booting would require a working network interface. Booting is done by pxeboot(8). But once the kernel has been initialized NFS is used to mount the root filesystem. It can't do that if there's no network ;)

For USB kernels however you can probably remove any and all network interfaces as it doesn't need them to boot. But in turn it requires umass(4) for example to be compiled in because it needs it in order to mount the root filesystem.

Think about the steps required once your 'mini' kernel has been initialized and what you need to take the next one; mounting a root filesystem. Those are the essential modules you are required to have or else the system simply cannot boot. Pretty much everything else can be loaded as a module later on, if needed. But it can't do that if it cannot mount a root filesystem.
 
Thanks, ralphbsz and SirDice, of course I know that I need the driver for the interface and that is why I left re0 there.

The delivered MINIMAL configuration file is interesting, because it exclude what can be load with kldload, but unfortunately loader.conf seems not to be processed by PXE booting, or at least not at the appropriate time for booting with PXE.

I think, file lookups will not take much time. It is the loading, and this will happen anyway.

BTW: if I reduce the kernel to 1/3, then it will take 1/3 of the time? This is another way of making the calculations that give a different result. :)
 
hruodr said:
The delivered MINIMAL configuration file is interesting, because it exclude what can be load with kldload,
Click to expand...
Keep in mind that almost everything is actually a module. The kernel configuration basically defines which modules are statically linked into the kernel file.

hruodr said:
, but unfortunately loader.conf seems not to be processed by PXE booting, or at least not at the appropriate time for booting with PXE.
Click to expand...
Read 31.8. Diskless Operation with PXE and diskless(8) to get a better idea of the various boot stages and steps with PXE booting.

hruodr said:
if I reduce the kernel to 1/3, then it will take 1/3 of the time?
Click to expand...
There's no linear relationship between the kernel's size and the time it takes to load and initialize. There could be a very small module that takes a lot of time to initialize or the other way around. Loading the kernel is only part of the boot time, there's also some time required to probe and enable the various kernel modules.
 
SirDice said:
[...] diskless(8) to get a better idea of the various boot stages and steps with PXE booting.
Click to expand...

From man pxeboot:

The pxeboot bootloader retrieves the kernel, modules, and other files either via NFS over UDP or by TFTP, selectable through compile-time options. [...] Note that pxeboot expects to fetch /boot/loader.rc from the specified server before loading any other files. [...] This may be changed by setting the nfs.read_size variable in /boot/loader.conf [...]
Click to expand...

Is it not clear that it should process /boot/loader.conf from the very beginning?
 
hruodr said:
BTW: if I reduce the kernel to 1/3, then it will take 1/3 of the time? This is another way of making the calculations that give a different result. :)
Click to expand...
If you reduce the kernel to 1/3 the size, then just loading the kernel into memory from the file system (could be a remote file system in the case of a network boot) will take roughly 1/3 of the time. Which is the same as saying that reading a file that is 1/3 the size will take roughly 1/3 the time, because that's really what loading the kernel is: Open a file on a file system, perform a series of reads, and deposit the result in memory. This is slightly optimistic, since there is a constant overhead for finding and opening the file (about 100ms +- a factor of 10 either way), compared to a few seconds for the actual reading (assuming a 10 MByte/s speed), so it is not quite as good. This also assumes that the kernel is read completely and linearly, which I think is the case for the boot loader.

BUT: the time required to read the kernel from the file system and copy it into memory is a tiny fraction of the overall boot time, which is on the order of 1/2 minute to 1 minute (plus or minus a factor of several). That boot time is dominated by the time it takes to initialize hardware, and then software subsystems. Watch your machine booting sometime, and time roughly how long it takes. And then think about whether saving what is probably a few seconds on the kernel loading time is a good investment of effort.
 
Also keep in mind that drivers for hardware that is not around take no extra time, since they are invoked based on PCI IDs, and not left checking for themselves if there is hardware they can handle.
 
You must log in or register to reply here.
Back
Top