Solved Can I build a static kernel?

Phishfry

Phishfry

While messing with Arm boards I tried to put /boot/ on a SD card and / on sata.
I had assumed the kernel was self contained in /boot/.
It is not. It has tentacles in many additional directories. My Uboot was not working with SATA so it failed.
How could I build a kernel with all needed files in /boot/ ?
Is there a kernel static compile option?
 
An even more basic question. How can I find the needed kernel files not found in /boot/ ?
I know /libexec/ is needed.
 
I'd suggest first rolling a complete ARM image file, then writing it to the SD card, and then booting that whole enchilada. A barebones FreeBSD install is more kernel than userland anyway.
 
I have played with a few of these ARM devices. The way each OS was installed and booted was different for each ARM. What ARM device are you referring to Sir?

I remember FreeBSD 11 or 12 was not optimised for Cortex A8(Pandaboard) years ago. One needed to edit the uboot to get through. SATA is out of question. Most use SD card. Mobile OSs were not problematic; and I think OpenBSD came close. The team keep improving it for CortexA8. FreeBSD comes next as they incest more resources in the ARM tier-level.
 
covacat said:
everything is in /boot unless you have a nonstandard thing
Click to expand...

What about shared libraries? I know the kernel uses those. Plus additional libraries.
All outside /boot/

I have worked around this with different approach but the topic interests me.
 
Lamia said:
What ARM device are you referring to Sir?
Click to expand...
Hummingboard2 is on the front burner. Another one on the way from SolidRun.
It is really all a learning experience.
I have learned more about U-boot and I am close to solving this. Still not SATA booting though.
 
kernel 'shared libraries' are the kernel modules
all the other code in /lib /usr/lib etc is userland
you can probably statically link most of the modules but a few (vmm, zfs)
with some effort all can be linked in a single binary but im not sure what advantage will this bring
 
Here was my hypothetical- Just dump these shared libraries into /boot/ directory.
Along with all the other needed files. Who cares how big it is.
I don't need it "Static" per say. Dependencies Included might be a better term.
Everything to boot kernel in /boot/ freestanding.
Monolithic don't sound right.
Is that what monolithic means? Freestanding bootable kernel without a userland?
 
AFAIK, the kernel does NOT use shared libraries. Userland programs typically do. That simply means that libraries are loaded into memory at runtime, one at a time. This is also called "dynamic linking". The reasons the libraries are called "shared" is that many executables can load the same library, saving lots of disk space and hassle. Matter-of-fact, programs can also share the memory image of a library (that's actually where the name "shared library" comes from), which also saves lots of memory. The alternative is copying the library code together with the main program into the executable, which is called "static linking".

The kernel does use modules. Mostly for device drivers. In the old days, it was possible to compile/link a kernel that did not use modules. I used to do that in Linux for desktops, because I exactly knew ahead of time what device drivers would be needed, specifically for each hardware. Today, this is considered highly old-fashioned and silly, since loadable modules work so well. I don't even know whether it is still possible (in Linux, FreeBSD, or other OSes) to run without loadable modules; a few years ago I remember learning that certain device drivers will not even work, other than as modules, but I don't remember the details.

Creating a kernel without modules, just because your deployment of files into the boot directory is messed up, is silly. It's throwing the baby out with the bathwater. It's perfectly possible to get kernel deployment under control; don't panic, you must be close to a solution.

The term "monolithic" kernel has multiple meanings. Originally, it is from the 70s or 80s: until then, most kernels had all of their code is kernel space (as opposed to user space), and were linked as a single binary. The main use of the term "monolithic" simply means that all OS services run in kernel space. The alternative is micro kernels, where the actual kernel-mode code is very small, and it uses daemons or drivers that run in user space. Examples include certain file systems that run in user space, with tiny kernel adapters (FUSE is a commonly seen example in the open-source world). Traditionally, those user-space kernel parts are not called "modules"; they are really just user-space executables that are required for certain kernel functionality. What we call "modules" today is not that: modules run in the kernel space; they are just parts of the kernel that are loaded as needed.

But I have also seen the word "monolithic" applied to kernels that are loaded from a single binary, without modules. Whether that's correct use of the word or not is anyone's guess. Same with using the word "static" on the kernel: A linguistic gray zone.
 
Phishfry said:
Is that what monolithic means? Freestanding bootable kernel without a userland?
Click to expand...
Not exactly... a good discussion of what a monolithic kernel is here. Basically, a monolithic kernel has a lot of hardware drivers compiled into it as kernel modules, AND the kernel has to manage all that - all that happens in a single binary (which usually lives in /boot/). A microkernel is small, and mostly has some resource management routines in it, but the modules for hardware drivers are mostly externally loaded. FreeBSD seems to be closer to a microkernel than a monolithic one (think amdgpu.ko, for example, which is an external GPU module). But, IIRC, userland is irrelevant in discussing monolithic vs micro kernels.
 
In the traditional definition of microkernel (and those do exist, for example Mach), the "outboard" parts run in user space. That is not the case for Linux and *BSD modules, which run in kernel space. The OS community refers to such architectures as "hybrid" kernels. It is a little complicated, as kernel modules are separately loaded and unloaded, but run in the same address space, protection ring and process as the kernel itself.
 
Here is exactly what I did. FreeBSD Armv7 Generic image 13.0.

Flashed it to two devices.
mSD card = mmcsd0
mSATA = ada0

Alter label crap in loader to regain device names
Set fstab to this:
Code: 
# Custom /etc/fstab for hummingboard2
/dev/ada0s2a        /            ufs            rw                        1    1
/dev/mmcsd0s1        /boot/msdos    msdosfs        rw,noatime                0    0
tmpfs            /tmp        tmpfs        rw,mode=1777,size=50m    0    0

So that works with caveats. Total duplication. To start slimming I get rid of directories on mmcsd02a.
This partition is not even mounted. I was planning on possibly keeping /boot/ here and root on SATA.
So I started deleted extraneous directories like /var and /etc as they are mounted with SATA already.
Well at some point I discover that I went too deep deleting. It won't reboot. Libraries somewhere missing.
I discovered with kenv the kernel was running from emmcsd0s2a which is not even mounted at boot.
So I did something wrong. Maybe Uboot is at play here as it knows the disks.

I now have uboot with SATA and need to work that out. Don't look back is my slogan of the day.
I am EFI booting now.

Mark this as solved stupid question.
Please feel free to continue dialog.
 
stop efi loader and do a lsdev
is the sata disk is visible to efi/u-boot than you can modify loader.conf to load everything from the sata disk
you will still need the sd card for u-boot but only the msdos partition
 
covacat said:
you will still need the sd card for u-boot but only the msdos partition
Click to expand...
That was my angle here.
I also tried mounting ada0s2a kernel with loader.conf and fstab
/dev/ada0s2a/boot/ mounted at /boot
This didn't work.
I also saw lots of user profile problems with both disks populated. History not remembered ect...

I just got EFI booting working with u-boot.
 
Phishfry said:
What about shared libraries? I know the kernel uses those. Plus additional libraries.
All outside /boot/
Click to expand...
I seriously wonder how you can "know" something that's clearly wrong?

As previously said by others, all the kernel can load are kernel modules. All modules that come with the kernel are installed in /boot/kernel. And even 3rd-party modules are installed in the /boot hierarchy (/boot/modules). The kernel never uses anything else.
 
Zirias said:
I seriously wonder how you can "know" something that's clearly wrong?
Click to expand...
I will use different terminology next time when unsure.
Sorry for wasting everyone's time.

That is the good thing about messing with Arm. It is a learning experience.
Right now I have the kernel on the fat32/EFI partition and it boots without root being found.
 
ralphbsz said:
The kernel does use modules. Mostly for device drivers. In the old days, it was possible to compile/link a kernel that did not use modules. I used to do that in Linux for desktops, because I exactly knew ahead of time what device drivers would be needed, specifically for each hardware. Today, this is considered highly old-fashioned and silly, since loadable modules work so well. I don't even know whether it is still possible (in Linux, FreeBSD, or other OSes) to run without loadable modules; a few years ago I remember learning that certain device drivers will not even work, other than as modules, but I don't remember the details.

Creating a kernel without modules, just because your deployment of files into the boot directory is messed up, is silly. It's throwing the baby out with the bathwater. It's perfectly possible to get kernel deployment under control; don't panic, you must be close to a solution.
Click to expand...
It depends on whom you're asking and which OS you are looking at. As a matter of fact recent OpenBSD releases come by default with a static kernel only. Even more so, they removed kernel module loading capabilities from their kernel years ago for security reasons.
 
hardworkingnewbie said:
It depends on whom you're asking and which OS you are looking at. As a matter of fact recent OpenBSD releases come by default with a static kernel only. Even more so, they removed kernel module loading capabilities from their kernel years ago for security reasons.
Click to expand...
That's a different scope (security) than what ralphbsz was talking about (deployment issues).

From the security perspective, I think a solution like FreeBSD's secure mode is pretty fine. But of course, this is code as well and could, in theory, fail. So to be absolutely sure no attacker can ever load own code into the kernel, you must completely remove the feature. OpenBSD often picks the "radical" way when it comes to security.
 
You must log in or register to reply here.
Back
Top