Moving server from OpenBSD to FreeBSD

Z

Zaragon

Hey all,

My file server is currently running OpenBSD (using RAID1 2-way mirrors) and I'm planning on moving it over to FreeBSD to take advantage of ZFS, since I'm going to be using a 24-bay rackmount Supermicro now instead of the old tower case I've been using.

Aside from the change to using ZFS, which I've been heavily researching, are there any major gotchas I should be aware of when moving to FreeBSD? I've been using OpenBSD for my servers for something close to 20 years (whenever the first version of pf was released), but I've never touched FreeBSD, and almost all the migration guides seem to be focused on Windows or Linux users, not NetBSD or OpenBSD users.

I don't intend to run X or desktop applications on it, so I expect that'll make the migration easier, and I'd imagine most of the packages I use on OpenBSD are available on FreeBSD (and if not, I can find alternatives). I'm primarily looking for differences in the main OS that might trip me up.

TIA for any help you can provide!
 
The biggest difference I can think of is how anything you install out of a package or port is going to want to be configured in /usr/local/etc. Openbsd AFAICT keeps everything in /etc as do most Linuxes. This includes startup scripts, which live in /usr/local/etc/rc.d on Freebsd.

Network config is a little different in that you do it in /etc/rc.conf instead of in hostname.ifname files. Oh, and you edit /etc/rc.conf, not /etc/rc.conf.local. The default values in Freebsd are in /etc/defaults/rc.conf.

Keep in mind your pf ruleset might not work in Freebsd. The version of pf in Freebsd is based on the pf that was released in Openbsd 4.5, and has been "heavily modified" according to the man page.

I'm sure I'm forgetting things, but I doubt you'll have much trouble with the migration. ZFS seems magical to me after years of struggling with LVM on Linux. Well worth the change.
 
My servers are currently running OpenBSD, and now (finally) a personal laptop running FreeBSD. I would say that working with ports and pkg in generally has been a wonderful process. I would be careful mixing ports/pkg libraries, things can get interesting. You can find any every OpenBSD package within the ports library.

I've taken to using OpenBSD as the firewall/gatekeeper, and FreeBSD as the data manager/ admin. I think you will be pleasantly surprised with the progress that FreeBSD has made.
Also, documentation, on documentation. OpenBSD has the manual, FreeBSD covers everything. They've even got their own developer handbook! Anything you may need can (usually) be solved by checking the docs. Its one of the main reasons I chose FreeBSD on my personal laptop. Even if I can't find the exact right thing, I can find out how to diagnose the problem, and build what I need.
 
Yeah, I'm aware of the PF differences, but I have a separate physical machine that's going to remain on OpenBSD that functions as my firewall/nameserver/ntp server/http server/dhcp server/VPN endpoint (it might do a few more things, that's just all I remember offhand. The file server is only accessible via the LAN (and by extension, to anyone connected via the VPN) and so doesn't run any sort of packet filter--in fact the current machine only runs Samba, NFS, and NTP. I'm not really using NFS anymore and probably won't enable it on the new FreeBSD server.

I wasn't aware about the differences in the network/rc.conf configuration or the existence of /usr/local/etc, that's exactly the sort of thing I'm talking about as gotchas. If anyone has any more keep them coming, that's very helpful.
 
I've gotten started setting up my machine. and ran into a few gotchas.

First the good news though. Guided ZFS on root from the install was a piece a cake; it was so much fun I did it twice! Couple of binaries were packages on OpenBSD but are part of the base system on FreeBSD (like bzip2, lz4, and xz) not really a surprise. Didn't find a single thing I needed that wasn't either already in the system or available in a package or port just like on OpenBSD. Then again, I didn't expect I would.

The network config was a non-issue, after seeing how the setup configured the first interface it was easy. Same for the hostname, also configured via /etc/rc.conf, which is also different on OpenBSD (stored in the file /etc/mygate).

And I'd originally posted that I wouldn't be using any sort of packet filter, but I forgot that sshguard just hooks in to the packet filter of your choice (which is the only reason my original file server has pf running). Fortunately, the pf.conf from the old server is so simple that the only thing I needed to do was change the name of the network interface, and FreeBSD accepted it as-is.

The /usr/local/etc keeps biting me; sometimes files are in /etc (syctl.conf, rc.conf), sometimes they are in /usr/local/etc (sshguard.conf, zshenv), and sometimes they're in /etc/default, with the expectation that you'll overwrite with additional config in either /etc or /usr/local/etc ( periodic in particular seems to scatter stuff everywhere). I understand the purpose of having /usr/local/etc but it is sure making my life more difficult right now when I go to configure things.

One that wasn't mentioned was /etc/crontab; OpenBSD doesn't use that and just uses root's crontab. Ran into this one when I was trying to figure out where periodic was getting started from and crontab -e as root just gave me an empty file.

Everything else remaining is either ZFS specific (such as difficulties mounting the zroot created by the default installer from the LiveCD) or package specific (having difficulties making any sense out of smartd.conf).
 
I run both and couldn't think of any major issues you'd have so didn't post before and doesn't sound like you've encountered anything dire.

On FreeBSD I miss OpenBSD's enhanced systat but both OSs are very good in my experience. Similar enough it's not too hard to switch from one to the other as needs be. But I'm straying into the non-FreeBSD discussion so 🤐

Thanks for posting the update on how it went for you.
 
Zaragon said:
[...]
The /usr/local/etc keeps biting me; sometimes files are in /etc (syctl.conf, rc.conf), sometimes they are in /usr/local/etc (sshguard.conf, zshenv), and sometimes they're in /etc/default, with the expectation that you'll overwrite with additional config in either /etc or /usr/local/etc ( periodic in particular seems to scatter stuff everywhere). I understand the purpose of having /usr/local/etc but it is sure making my life more difficult right now when I go to configure things.

One that wasn't mentioned was /etc/crontab; OpenBSD doesn't use that and just uses root's crontab. Ran into this one when I was trying to figure out where periodic was getting started from and crontab -e as root just gave me an empty file.

Everything else remaining is either ZFS specific (such as difficulties mounting the zroot created by the default installer from the LiveCD) or package specific (having difficulties making any sense out of smartd.conf).
Click to expand...

Well done on the move.

First, probably a quick read of hier(7) is in order. This will tell you rather quickly what is what and what goes where.

Basically, you should disregard ANYTHING in /etc/defaults as it's for the system startup; don't be tempted to edit files in there unless you really know what you're doing.

All ports and packages keep their configuration information in /usr/local/etc, never /etc. I've not personally encountered any exception to this rule.

I guess it can be confusing when /etc/rc.conf and /etc/rc.conf.local exist. I'm not convinced of the benefit of the latter.
 
you will get used to the fact that ports/packages configuration is under /usr/local/etc and base system stuff is in /etc. This has a nice effect: before a major upgrade on ports and packages, you could take a snapshot of /usr/local and simply rollback an upgrade if something is completely broken.
And one more thing: I encourage you to use jails if you feel the need to setup more services ... it's really great to work with those "networked chroots on steroids"
 
Ah, I suppose I wasn't clear; I'm more "cloning and then replacing" than I am technically migrating. I've purchased a new server (Supermicro 846 chassis), which is going to take the place of the old server (generic PC with HBA), which is still up. The old server is going to remain up until I'm satisfied that the new server is performing the way I want it to, then I'll power off the old server, change the IP of the new server, and then power it down and replace the old server with it. That's probably at least two weeks away. In the meantime the new server sits on my desk and serenades me while I work with its lovely droning fans.

I've already wiped and reinstalled once after messing around with the root zpool, I'm not afraid to do it again (though now that I have things setup mostly the way I want them, I'd much rather rollback to a snapshot, instead). I'm still working on shuffling data around off the old server so I can steal 6 of its drives and start using those to learn ZFS better. I'll probably copy (not move) some of that data to the new zpool just to mess with and test things.

I'm definitely using this time to learn and mess with the new OS, though it looks like having used OpenBSD for nearly two decades has given me a leg up on switching to FreeBSD (compared to people switching from Linux). I went through the Linux to BSD pain when I originally switched to OpenBSD. I haven't found this to be NEARLY as bad.

mark_j, thanks for the tips on hier(7), after scanning through that the filesystem hierarchy isn't much different than OpenBSD (with the exception of /usr/local/etc and /etc/defaults). It doesn't really explain the purpose of /usr/local/etc or how the config files layer. Kind of a new concept for me, I'm used to there being one config file per service, even if the locations vary. That especially seems to be giving me grief with periodic; nothing I've put in the config seems to be doing anything. Still got to dig into that. Running periodic daily manually does something, but it doesn't do (for example) the periodic ZFS scrub I tried to configure. I'm assuming it's only doing the stuff that's configured in the base install.

I'm not sure why /etc/rc.conf.local exists on FreeBSD either, maybe someone else can chime in. In OpenBSD /etc/rc.conf is the base configuration script and gets replaced with every upgrade, and /etc/rc.conf.local is the local configuration. Instead on FreeBSD the base configuration script is in /etc/defaults/rc.conf and the local configuration is just in /etc/rc.conf. It's basically the same division, but with different locations. I suppose I could get behind the idea of an /usr/local/etc/rc.conf, if any ports or packages needed to add stuff to rc.conf, but I don't understand the need for a third rc configuration file in etc.

Edit: The discussion of /etc/defaults and /etc/rc.conf.local actually let me track down what was wrong with periodic; it works the same way as rc. I had my changes in /usr/local/etc/periodic.conf, which it doesn't seem to read. Moving them to /etc/periodic.conf made the scrubs work.
 
Zaragon said:
Everything else remaining is either ZFS specific (such as difficulties mounting the zroot created by the default installer from the LiveCD) or package specific (having difficulties making any sense out of smartd.conf).
Click to expand...
Here's mine, in case it helps:
Code: 
DEVICESCAN -R 194 -R 231 -a -o on -S on -s (S/../.././02|L/../../6/03) -m root
It took a while to come up with it based on the man page and the old version from my Linux server. I've honestly forgotten what most of it means. I only remember that the -s (S/...) part schedules (S)hort and (L)ong tests, and that "-m root" mean email root when there's a problem.

As an aside, I hate these "self-documenting" config files that wind up being hundreds of lines of commented-out stuff. Makes it really hard to figure out what, if anything, you should change on upgrade. The worst offender is php.ini. It took me hours to come up with a reasonable one. I keep it (and other configs) in git now just to stay sane.
 
Zaragon said:
I've already wiped and reinstalled once after messing around with the root zpool, I'm not afraid to do it again (though now that I have things setup mostly the way I want them, I'd much rather rollback to a snapshot, instead).
Click to expand...
That is exactly the correct attitude. Right now, recreating or just partly reconfiguring the machine is still easy. So invest the time now to get it to the way you like it. Once you have it in production, making major changes will be much more painful and risky.

I transitioned my home server from OpenBSD to FreeBSD about 8 or 10 years ago, and it was not painful at all, very much like your experience.
 
Zaragon said:
I'm not sure why /etc/rc.conf.local exists on FreeBSD either, maybe someone else can chime in. In OpenBSD /etc/rc.conf is the base configuration script and gets replaced with every upgrade, and /etc/rc.conf.local is the local configuration.
Click to expand...

Finally it will depend on each individual how they handle these files, so this is in part only the way I made up to handle things.
The basic rule is: in /etc lives the base system, and everything that comes via ports goes to /usr/local; this includes their start/stop scripts /usr/local/etc/rc.d, their periodics /usr/local/etc/periodic, etc.
Then there is a couple of default configs in /etc/defaults - these do only concern the base system, not any ports, and these will be replaced on every upgrade. If you need to change or add things, only the changes go to the same file in /etc, and these will not be replaced on upgrades. But, as these do only concern the base system, the respective configurations for the ports might be put in similar files with the suffix .local, e.g. /etc/rc.conf.local, /etc/periodic.conf.local, etc.
If you prefer to instead have files like /usr/local/etc/rc.conf and /usr/local/etc/periodic.conf, that is also possible by adding such files to the respective variables in the base configuration (but there is to consider that there might be a point in time where the system needs to read certain files for initialization, while /usr/local is not yet mounted!).
It is also possible (and I prefer to do it), to create a third place for things that are neither base system nor ports, but other locally written or vendor specific components.
 
This is an interesting point. Even though the rc script lives in /usr/local/etc/rc.d it examines /etc/rc.conf to determine if it should run at all, and for additional settings. I examine the rc script to figure out what to put in /etc/rc.conf. Usually it's a straightforward portname_enable="YES", but not always:
Code: 
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-n $hostname"
 
you can also do service name-of-script rcvar and it will tell you. Examples:
Code: 
tingo@kg-core2$ service mysql-server rcvar
# mysql
#
mysql_enable="NO"
#   (default: "")

tingo@kg-core2$ service calibre rcvar
# calibre
#
calibre_enable="NO"
#   (default: "")
 
Jose said:
I examine the rc script to figure out what to put in /etc/rc.conf. Usually it's a straightforward portname_enable="YES", but not always:
Click to expand...

There are also some common settings. For instance, you can put in something like
Code: 
portname_env="PGGSSENCMODE=disable"
to make a port run with a specific environment variable, which can be very helpful.
Read the comments in /etc/rc.subr for further features.
 
I think it is worth noting that /boot/loader.conf is another common settings file.
The scheme used there commonly is:
modulename_load="YES"
loader.conf is commonly is used for starting kernel modules for hardware enablement.
For example I use Chelsio 10G cards for ethernet.
They required both the module and firmware in /boot/loader.conf to get usable interfaces.
if_cxgbe_load="YES"
t4fw_cfg_load="YES"
 
Before I get into replies I wanted to state how impressed I am with the stability of this system! I happened to bump one of the SATA cables (without noticing it) while unplugging the network cable from the wall. That caused one of the two drives in zroot to drop out. ZFS and the mirrored swap partition handled it without a hiccup. I onlined the drive again and it came back online with no issue.

Then I decided to see how robust this system is, so I unplugged (at the drive end) the SATA cable I thought was the problem. Turns out I guessed wrong and bumped the other cable while plugging it back in. Entire pool goes offline, but the system keeps chugging along. Go back to the command line, clear the zpool and bring it back online, and everything's back to normal like nothing ever happened. Even the swap partition came back like nothing happened.

Considering my OpenBSD file server kernel panicked when both drives in a data mirror died at the same time, then refused to finish booting because it couldn't check the filesystem on the drives that weren't there anymore, color me thoroughly impressed.

Jose said:
This is an interesting point. Even though the rc script lives in /usr/local/etc/rc.d it examines /etc/rc.conf to determine if it should run at all, and for additional settings. I examine the rc script to figure out what to put in /etc/rc.conf. Usually it's a straightforward portname_enable="YES", but not always:
Code: 
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-n $hostname"
Click to expand...

Yeah, that's what threw me hard with zfs-periodic. The important parts reside in /usr/local/etc, but you have to add the options that enable it in /etc/periodic.conf.

I get what FreeBSD is trying to do with separating /etc and /usr/local/etc, I'm just not convinced of the benefit yet. It seems to be primarily for ease of upgrade, but I configure things more often than I upgrade.

I'm still not wild about /etc/crontab instead of just using root's crontab either, and unlike /usr/local/etc, I don't understand the rationale for this one.

Jose said:
Here's mine, in case it helps:
Code: 
DEVICESCAN -R 194 -R 231 -a -o on -S on -s (S/../.././02|L/../../6/03) -m root
It took a while to come up with it based on the man page and the old version from my Linux server. I've honestly forgotten what most of it means. I only remember that the -s (S/...) part schedules (S)hort and (L)ong tests, and that "-m root" mean email root when there's a problem.
Click to expand...

Thanks, that's helpful except for one thing--mail that goes to the local root account may as well go straight to /dev/null. I don't think I've ever once checked the Mail on any of the three OpenBSD boxes that I maintain, since they're all headless servers jammed in data closets.

I would love to have some way to actually get it to email my actual Gmail account, but I imagine that involves sendmail and I've never been able to make sendmail do anything I've ever tried. And I configured my own BIND 9 server! (If anyone can actually point me to a guide that will help me do this, I'd be eternally grateful.)

Failing that, at least a way to send it to the system log somewhere, since I do at least periodically grep through those looking for interesting things.
 
Zaragon said:
Thanks, that's helpful except for one thing--mail that goes to the local root account may as well go straight to /dev/null. I don't think I've ever once checked the Mail on any of the three OpenBSD boxes that I maintain, since they're all headless servers jammed in data closets.

I would love to have some way to actually get it to email my actual Gmail account, but I imagine that involves sendmail and I've never been able to make sendmail do anything I've ever tried. And I configured my own BIND 9 server! (If anyone can actually point me to a guide that will help me do this, I'd be eternally grateful.)

Failing that, at least a way to send it to the system log somewhere, since I do at least periodically grep through those looking for interesting things.
Click to expand...
I always alias root to a real mail account in /etc/mail/aliases
Code: 
# $FreeBSD: releng/12.1/etc/mail/aliases 243752 2012-12-01 15:11:46Z rwatson $
#       @(#)aliases     5.3 (Berkeley) 5/24/90
#
#  Aliases in this file will NOT be expanded in the header from
#  Mail, but WILL be visible over networks.
#
#       >>>>>>>>>>      The program "newaliases" must be run after
#       >> NOTE >>      this file is updated for any changes to
#       >>>>>>>>>>      show through to sendmail.
#
#
# See also RFC 2142, `MAILBOX NAMES FOR COMMON SERVICES, ROLES
# AND FUNCTIONS', May 1997
#       http://tools.ietf.org/html/rfc2142

# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.

root: me@my.domain

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root
...
That plus a newaliases should get you off to the races with mail going to root if you didn't mess with the stock Sendmail config. I stopped trying to get Sendmail to do things about 20 years ago. I recommend Postfix if you need an MTA.

Edit: This is the same on Openbsd, BTW.
 
Very good thread with a lot of useful information and discussion. And yes, the system is very, very stable. I started using 12.1 a few weeks ago as a desktop system in place of Slackware Linux on a few of my systems, one a laptop (Thinkpad X250). I've tried to do this over a number of years, periodically testing FreeBSD and, in the past, always found a showstopping problem. This version, while not perfect (what is?), has finally done the job for me and it's really a pleasure to use. ZFS is magic (one of my systems has multiple SSDs and I went through the LVM pain with Linux; this was a piece of cake) and I really like being able to back up a running system with a ZFS snapshot that I then zfs send to a backup drive. I shut my Linux systems down to back them up to avoid them wiggling around while doing so. Not necessary with ZFS and FreeBSD. I also like the performance and generally up-to-date packages.
I've also used OpenBSD off and on, mostly off, over the years and found that I was bothered by the sluggishness. And the lack of a modern filesystem. And packages being somewhat out-of-date, though running current helps with that. The system is generally behind the times, perhaps because of the total emphasis on security. Linus Torvalds had something pungent to say about that, as I recall. My biggest issue with OpenBSD, though is de Raadt. He's undeniably brilliant, but perhaps not quite as brilliant as he thinks he is, and his nastiness has rubbed off on some of his lieutenants. They are doing good work, but it's not good enough for me to put up with the unpleasantness.
 
Jose said:
I always alias root to a real mail account in /etc/mail/aliases
Code: 
# $FreeBSD: releng/12.1/etc/mail/aliases 243752 2012-12-01 15:11:46Z rwatson $
#       @(#)aliases     5.3 (Berkeley) 5/24/90
#
#  Aliases in this file will NOT be expanded in the header from
#  Mail, but WILL be visible over networks.
#
#       >>>>>>>>>>      The program "newaliases" must be run after
#       >> NOTE >>      this file is updated for any changes to
#       >>>>>>>>>>      show through to sendmail.
#
#
# See also RFC 2142, `MAILBOX NAMES FOR COMMON SERVICES, ROLES
# AND FUNCTIONS', May 1997
#       http://tools.ietf.org/html/rfc2142

# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.

root: me@my.domain

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root
...
That plus a newaliases should get you off to the races with mail going to root if you didn't mess with the stock Sendmail config. I stopped trying to get Sendmail to do things about 20 years ago. I recommend Postfix if you need an MTA.

Edit: This is the same on Openbsd, BTW.
Click to expand...

Does that work for sending to an actual mail account outside my LAN, though? I don't run a local mailserver and I don't generally check *any* of the local accounts on either of my *BSD servers, so forwarding it to a local user on the same box unfortunately isn't all that helpful either. And I was always under the assumption that (for example) Gmail's SMTP server would reject any attempt by a dynamic IP to forward email to it. I do have my own domain name and functioning dynamic DNS through Google Domains, if there's anything that can be configured there that would allow it to work?

donallen said:
Very good thread with a lot of useful information and discussion. And yes, the system is very, very stable. I started using 12.1 a few weeks ago as a desktop system in place of Slackware Linux on a few of my systems, one a laptop (Thinkpad X250). I've tried to do this over a number of years, periodically testing FreeBSD and, in the past, always found a showstopping problem. This version, while not perfect (what is?), has finally done the job for me and it's really a pleasure to use. ZFS is magic (one of my systems has multiple SSDs and I went through the LVM pain with Linux; this was a piece of cake) and I really like being able to back up a running system with a ZFS snapshot that I then zfs send to a backup drive. I shut my Linux systems down to back them up to avoid them wiggling around while doing so. Not necessary with ZFS and FreeBSD. I also like the performance and generally up-to-date packages.
I've also used OpenBSD off and on, mostly off, over the years and found that I was bothered by the sluggishness. And the lack of a modern filesystem. And packages being somewhat out-of-date, though running current helps with that. The system is generally behind the times, perhaps because of the total emphasis on security. Linus Torvalds had something pungent to say about that, as I recall. My biggest issue with OpenBSD, though is de Raadt. He's undeniably brilliant, but perhaps not quite as brilliant as he thinks he is, and his nastiness has rubbed off on some of his lieutenants. They are doing good work, but it's not good enough for me to put up with the unpleasantness.
Click to expand...

Perhaps I'm lucky my first experience with FreeBSD is 12.1, then? Just about everything has worked right out of the box, and the few things that haven't I've been generally able to trace to me not understanding how FreeBSD does things.

I've been using OpenBSD as a general purpose network appliance (named/dhcpd/pf) for years, which it excels at, and as a file server using softraid RAID1 mirrors, which it does not. I've been drooling over ZFS snapshots since I found out about them--I used to work for NetApp and got very used to how WAFL worked, and ZFS is about the closest thing I've seen in the home space.

I've never found OpenBSD's "lack of a modern filesystem" to be an issue; I've lost more data to ext2 in Linux than I ever have to UFS in OpenBSD. It's not clear to me how much better UFS is in FreeBSD because I planned to use root-on-ZFS from day one, so never looked into it. Is it that much better than OpenBSD's version? ...unless of course you're just referring to ZFS, in which case I agree that OpenBSD has nothing that can touch it. Neither does Linux, IMO, and it doesn't really look like ZFS is ever going to be as integrated into Linux as it is into FreeBSD because of how Torvalds clearly feels about it.

Performance-wise, OpenBSD is generally behind... well, everyone, except possibly NetBSD (haven't used NetBSD in two decades, but it was never a screamer either). It's not their focus, and I get it. I'm still likely to continue to use it for my network appliances because of the security, but I'm likely to use FreeBSD from this point forward for any internally facing server. I only used OpenBSD for that because it was what I knew, and it's simpler to stick with what you know.

I never considered Linux; even though I got my start with Linux back in the mid-90's, but it's gotten more and more disjointed and fragmented and I don't like the direction most major Linux distributions are going. Systemd alone was enough to make me swear off Linux permanently in my own home--there's no polite way to say how I feel about it so that's all I'll say. I have an XUbuntu workstation at work, and while it's fine for actually getting work done it's a chore to actually configure anything.

As far as de Raadt (and Torvalds, for that matter), I consider both to be brilliant people (or at least much, much smarter than I am) whose social skills are lacking, and I don't much care for either of them. However I vastly prefer *BSD to Linux and find that (unpleasantness aside) I tend to agree with the substance of what de Raadt says more often than I do Torvalds. I have a real hard time understanding why Torvalds makes the decisions he does, whereas with de Raadt I can generally follow his reasoning (even if I don't always agree with it).

Usually though, I try to stay out of the communities as much as possible as I find that in most cases the closer you get to the people in charge, the less pleasant they are, and I prefer to use my OS without getting dragged into politics.
 
drhowarddrfine said:
man rc.conf
Click to expand...
Well "historical reasons" is not very explanatory so here goes.
In the early days FreeBSD updates would overwrite /boot/loader.conf and /etc/rc.conf.
So you would put localized settings in rc.conf.local/loader.conf.local and the update process would ignore these files.
Fast forward to today and you will notice that freebsd-update prompts you about /etc/rc.conf and /boot/loader.conf.

Infact OPNsense still requires you to put localized settings (for instance if_cxgbe_load for Chelsio) in boot.loader.local on their NanoBSD version. NanoBSD uses a read only configuration for certian configuration files so boot.loader.conf is used.
 
You must log in or register to reply here.
Back
Top