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



## Bobi B. (Mar 6, 2018)

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 (Mar 6, 2018)

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:

```
#!/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 (Mar 6, 2018)

I just do more testing. This script should be started before [FONT=Courier New]LOGIN[/FONT] in case you use [FONT=Courier New]growfs[/FONT]. And in addition, [FONT=Courier New]/firstboot[/FONT] is removed automatically.

```
#!/bin/sh
#
# PROVIDE: foo
# BEFORE: LOGIN
# KEYWORD: firstboot
```


----------



## SirDice (Mar 6, 2018)

Bobi B. said:


> 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.


----------



## Bobi B. (Mar 6, 2018)

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.


----------



## Bobi B. (Mar 7, 2018)

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.


----------

