Solved Difference between /boot/loader.conf and /etc/rc.conf

Hi! Maybe this is a stupid thread, but I think all stupid questions in this forum may help some people looking at Google :rolleyes:

The question is: what is the difference between /boot/loader.conf and /etc/rc.conf?, that is, for example, to have linux_load="YES" in /boot/loader.conf or to have linux_enable="YES" in /etc/rc.conf? Or, for another example, what's the difference between enabling nvidia in /boot/loader.conf or enabling it in /etc/rc.conf?

Thanks :)
 
Last edited:
loader.conf(5) is loaded by the FreeBSD loader. The loader then loads all modules in there before the kernel even boots. /etc/rc.conf is read when the kernel is already up and running, the root is mounted, and init(8) is running.

linux_load="YES" in /boot/loader.conf only loads the Linux kernel module, and linux_enable="YES" runs /etc/rc.d/abi which does more setup of the Linux compat layer. It also loads the Linux kernel module which is why you don't really need to add it to /boot/loader.conf.

For the nvidia driver there really is no difference. I always load it in /etc/rc.conf because it loads faster for me when the system is up. zfsloader(8) reads are quite slow so I push as much module loading as possible to /etc/rc.conf.

Additionally you can set tunables (e.g. kern.vty) in /boot/loader.conf which can only be set before the kernel boots.
 
Hi everyone.
I don't want to open a new thread so I open this again.

Im trying to emprove my understanding of the boot process. Actually Im using a slightly chaotic mixture of /boot/loader.conf and /etc/rc.conf. E.g. I load radeonkms.ko and msdosfs_iconv in the kld_list in /etc/rc.conf but cd9960_iconv in /boot/loader.conf. Don't know why - it developed historically.

I always load it in /etc/rc.conf because it loads faster for me when the system is up

Since settings in the /boot/loader.conf are fed directly into the boot loader at system startup, I clould speed up the boot process to load most tunables in /etc/rc.conf, if I got it right.
But Im a little bit confused so I could add tmpfs to the kld_list or I could use tmpmfs="YES" in /etc/rc.conf. Both worked but when should i load something in kld_list and when should I use foo_enable="YES"?

An additional point concerns ZFS. Since I boot from ZFS I have zfs_load="YES" in /boot/loader.conf and zfs_enable="YES" in /etc/rc.conf to mount pools during initialization. Is one obsolete? And what about ZFS tunables? I put all of them in /boot/loader.conf but i read somewhere that some ZFS tunables could be used with sysctl(8) and therefore go into /etc/rc.conf. Should I keep only those in loader.conf which can be only adjusted at boot time?

Thanks for your hints and answers!
 
Since settings in the /boot/loader.conf are fed directly into the boot loader at system startup, I clould speed up the boot process to load most tunables in /etc/rc.conf, if I got it right.
Correct. In fact, it's usually recommended not to overuse /boot/loader.conf and only add settings or load modules which are required to actually boot the system.

Basically... just because you can use one (or the other) file to load kernel modules doesn't automatically imply that you should.

An additional point concerns ZFS. Since I boot from ZFS I have zfs_load="YES" in /boot/loader.conf and zfs_enable="YES" in /etc/rc.conf to mount pools during initialization. Is one obsolete?
No.

Let's reset the clock 3 years back and let me have a shot at the original question.

So... /boot/loader.conf is used by the boot loader to apply settings and load kernel modules which are required to boot the system. Booting a system roughly consists of 2 major parts. First the kernel gets loaded and it starts to detect & initialize your hardware. Then it will mount the root filesystem and transfer control to init. This is a standard procedure on all Unix-like systems, except Linux which replaced init with the monstrosity that is systemd thus making it really hard to consider it a serious Unix-like system anymore (but that's my personal opinion on the matter).

Back to the story: init will then take control and start other services and programs in order to fully boot the system (think about the rc.d structure on FreeBSD). And rc.d is mostly controlled by... you guessed it: /etc/rc.conf which controls the whole thing.

I think a good way to get a better impression is to look at /boot/defaults/loader.conf and /etc/defaults/rc.conf. You'll notice that the default loader.conf only deals with very specific boot issues; what kernel to load, if a splash screen should be used, the delay of the boot menu, what logo that boot menu should have and of course also if extra kernel modules are required.

Whereas rc.conf only deals with userland issues; which services to start and what settings to use (from network related to filesystem related).

Fun fact: mounting your filesystem is a userland problem, indicated by the existence of /etc/rc.d/FILESYSTEMS (there's more, but I'm trying to keep this short & simple).

Therefor: ZFS in /boot/loader.conf is required to provide the kernel with ZFS support so that it can access your ZFS pool, whereas ZFS in /etc/rc.conf is required to make sure the filesystems get mounted.

So how come the boot loader can access ZFS while your kernel wouldn't be able to without the entries in loader.conf? (that would be my next question anyway). Simple: because of the bootloader version which got installed:

Code:
peter@zefiris:/etc/rc.d $ ls -l /boot/gpt*
-r--r--r--  1 root  wheel   66098 Nov 12 18:16 /boot/gptboot
-r--r--r--  1 root  wheel  114754 Nov 12 18:16 /boot/gptzfsboot
One has support for ZFS whereas the other doesn't (only UFS).

So here's the issue: what do you think would happen if the kernel wouldn't be able to access the root fileystem? For example because it doesn't know about UFS or ZFS?
Then it'll prompt you about not being able to access the root filesystem and ask you to specify it.

And what about ZFS tunables? I put all of them in /boot/loader.conf but i read somewhere that some ZFS tunables could be used with sysctl(8) and therefore go into /etc/rc.conf. Should I keep only those in loader.conf which can be only adjusted at boot time?
Depends on the tunables. Do you really need to tune ZFS in the first place?

Anyway, I always play that safe and put it into loader.conf which will then transfer all that to the kernel and that's the end of that. It depends on the tunable but why take the risk..
 
ShelLuser - Wow. Thanks for your efforts and detailed description. Im only a regular user quite new to *BSD and actually somewhere on the learning curve..
I studied the handbook for most concerns but not really in such depth. So I am very grateful for all the help here.

except Linux which replaced init with the monstrosity that is systemd thus making it really hard to consider it a serious Unix-like system anymore (but that's my personal opinion on the matter).

You're damn right! I was completely happy with none of the Linux distributions - however I also like Arch for their minimal base system.

Anyway, I always play that safe and put it into loader.conf which will then transfer all that to the kernel and that's the end of that. It depends on the tunable but why take the risk..

Think I will stay with that way.

One last question. What excactly is the difference between the kld_list and the kldload calls in /etc/rc.conf?
 
well kldload give you the ability to load some modules on the fly for the kernel but those will be lost after reboot. rc.conf will executes all those everytime you boot your computer. The computer will first boot the kernel and then load the modules from rc.conf. You can as well see it as an easy way to load modules without having to build a new kernel.
 
One last question. What excactly is the difference between the kld_list and the kldload calls in /etc/rc.conf?
That's a bit of a lazy question; rc.conf(5) explains all the available options, though I wonder where you came up with kldload within this context because that doesn't exist.

The kld_list entry is merely a list of kernel modules to load whereas kldload(8) isn't directly related to rc.conf but merely a command within the base system which can be used to manually load kernel modules.
 
I think a good way to get a better impression is to look at /etc/defaults/rc.conf.
I think any newer user needs to pour over this excellent recommendation.
/etc/defaults/rc.conf has proper settings for many scenarios.
I can't understand why some people insist on video drivers in /boot/loader.conf.
Who cares what video resolution bootup messages use and you are slowing down your bootup time by preempting rc.d.
The messages fly by so quick I don't know who could read them let alone worry about resolution.
Now serial console in loader I understand. It is absolutely needed early in the boot process.
 
The kld_list entry is merely a list of kernel modules to load whereas kldload(8) isn't directly related to rc.conf but merely a command within the base system which can be used to manually load kernel modules.
What stumps me here is the format for that list. So
Code:
kldload_list="radeonkms.ko"
works fine, but
Code:
kldload_list="radeonkms.ko,acpi_ibm.ko"
fails to load either of them, as does
Code:
kldload_list="radeonkms.ko;acpi_ibm.ko"
I was not able to find any examples, rc.conf(5) just states "list". Can you give me a correct line to load several modules?
 
I was not able to find any examples, rc.conf(5) just states "list". Can you give me a correct line to load several modules?
In /etc/rc.conf use kld_list instead of kldload_list. I think the kldload_foo syntax is used in /boot/loader.conf and Im not quiet sure if it works in rc.
And kld_list is a space-delimited list so use
Code:
kld_list="/boot/modules/radeonkms.ko acpi_ibm"
 
In /etc/rc.conf use kld_list instead of kldload_list. I think the kldload_foo syntax is used in /boot/loader.conf and Im not quiet sure if it works in rc.
And kld_list is a space-delimited list so use
Code:
kld_list="/boot/modules/radeonkms.ko acpi_ibm"
You are absolutely right, thx!
  • regarding the variable name - I have no idea why I used the wrong one in my post, my /etc/rc.conf uses the correct name...
  • the space-delimited list format: Yes, I don't get an error any more, but no, the second module is not loaded :-/ -- will be looking into this some more... All is well ✅
 
Who cares what video resolution bootup messages use and you are slowing down your bootup time by preempting rc.d.
The messages fly by so quick I don't know who could read them let alone worry about resolution.
I was trying to find the initial boot msgs but they are not recorded in /var/run/dmesg.boot That starts with
Code:
---<<BOOT>>---
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE-p3 GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT(vga): resolution 640x480

but I'm sure I saw an error msg flash past between the menu screen and the blue Booting... msg and I couldn't see that recorded anywhere.
 
Back
Top