[nanobsd] Suggestions for per-host loader.conf?

Bobi B.

Active Member

Thanks: 86
Messages: 200

#1
Greetings!

Changes in /etc can be persisted in /cfg and that works fine. However what if host needs some specific loader tunables, that shall not be applied elsewhere? I'm aware root file system can be re-mounted read/write, but that would only cause confusion a month later, when root file system is upgraded and this change is forgotten and lost. Can someone provide any suggestions how to make per-host /boot/loader.conf and/or loader tunables customizations, when running nanobsd?

Thank you!
 

oOiOo

New Member

Thanks: 1
Messages: 16

#2
Hi,
The loader.conf is read too early in boot process. But you could write a script à la /etc/rc.d/growfs that configure your OS on firstboot:
Code:
#!/bin/sh
#
# PROVIDE: foo
# BEFORE: sysctl
# KEYWORD: firstboot

. /etc/rc.subr

name="foo"
desc="fooize nanobsd"                 
start_cmd="foo_start" 
stop_cmd=":"
rcvar="foo_enable"

foo_start () 
{
        # mount / read/write
        mount -orw /
        # do stuffs

        # sync and reboot
        sync;sync;sync;
        mount -oro /
        reboot
}

load_rc_config $name
run_rc_command "$1"
add foo_enable=YES in /etc/rc.conf and create the fistboot flag: touch /fistboot. Note, that's untested: you should check if /fistboot is removed automatically.
Hope this help
 

oOiOo

New Member

Thanks: 1
Messages: 16

#3
I just do more testing. This script should be started before LOGIN in case you use growfs. And in addition, /firstboot is removed automatically.
Code:
#!/bin/sh
#
# PROVIDE: foo
# BEFORE: LOGIN
# KEYWORD: firstboot
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,346
Messages: 27,540

#4
However what if host needs some specific loader tunables, that shall not be applied elsewhere?
Can you give an example of the type of tunable that needs to be changed? Running a specific rc(8) script could be a solution but it depends on the type of change that's required. Some settings can't be changed once the kernel has started so a rc(8) script may not be able to make the change.

Also note that loader.conf is handled before the kernel is started, so you're limited about what you can do and it's going to be difficult to differentiate one host from another. Even if you hack some of the loader(8) scripts.
 
OP
OP
Bobi B.

Bobi B.

Active Member

Thanks: 86
Messages: 200

#5
Thanks, oOiOo, we do this already, but this is not going to work for loader tunables.

SirDice, one such tunable is hw.mfi.mrsas_enable="1" however that could be included everywhere (on all hosts we currently do support).

Other tunables are network performance-related: kern.ipc.nmbclusters, hw.intr_storm_threshold, hw.(em|igb|ix).(rxd|txd), hw.igb.max_interrupt_rate, net.isr.maxthreads, net.isr.defaultqlimit, hw.bce.hdr_split and net.link.ifqmaxlen, possibly something similar. I also believe those are safe to be included on all hosts, maybe apart from settings depending on RAM size and/or number of CPU cores.

It seems that I cannot think of anything truly unique right now. Nevertheless, because nanobsd production implementation is just around the corner (about to replace regular FreeBSD installs with nanobsds), I prefer to know my options ahead of time, instead of when everything is "on fire" :) It turns out the question is more theoretical, than practical one.
 
OP
OP
Bobi B.

Bobi B.

Active Member

Thanks: 86
Messages: 200

#6
It just occurred to me, that root file system update helper tool (for example /usr/src/tools/tools/nanobsd/Files/root/update) can copy /boot/loader.conf.local from currently running root filesystem to the new one. After all, update helper tool already mounts new root file system to patch /etc/fstab in some cases. This way /boot/device.hints will be stock one from FreeBSD distribution, /boot/loader.conf will be for shared tunables and /boot/loader.conf.local for per-host tunables.
 
Top