# FreeBSD 12.0-RELEASE Update successful but kernel modules can not be loaded anymore



## damjank (Oct 6, 2019)

Hello Guys.

I installed fresh installation of FreeBSD 12.0 minimal; I then installed minimal packages, the rest was done via ports. I did freebsd-update fetch in install - it wen along OK.
Afterwords I get errors like: kldload: can't load pf: Operation not permitted and kldload: can't load mac_ntpd: Operation not permitted

I have made numerous modifications to sysctl and rconf - most notable are kern.securelevel=2 in sysctl and perhaps kern_securelevel_enable="YES" in rconf
Could those be interfering with normal kernel load or is that remnant of upgrade?

Any pointer would be nice as I can not get my date straight on VM and use jil software as FW is not working properly...
thank you in advance!
RgD


----------



## k.jacker (Oct 7, 2019)

STABLE branches can not be updated via `freebsd-update`.
Kernel modules can not be loaded, once _kern.securelevel_ has been set to anything higher than the default of -1.
Thus, if you want to load a module, you have to do that during the early stage of the booting process, from /boot/loader.conf and set your desired securelevel in /etc/sysctl.conf.
I'd suggest to stick to a RELEASE, if you are new to FreeBSD and stick to either pkg OR ports.


damjank said:


> I have made numerous modifications to sysctl


Generally speaking, you should not tweak things, unless you understand what you are doing and you actually try to solve a problem or change a behaviour to your likings.


----------



## SirDice (Oct 7, 2019)

damjank said:


> I did freebsd-update fetch in install - it wen along OK.


Then you're not running 12.0-STABLE. You cannot upgrade a -STABLE version this way.



damjank said:


> most notable are kern.securelevel=2 in sysctl and perhaps kern_securelevel_enable="YES"


Maybe you should understand what this does before blindly enabling it?


```
The kernel runs with five different security levels.  Any super-user
     process can raise the level, but no process can lower it.  The security
     levels are:

     -1    Permanently insecure mode - always run the system in insecure mode.
           This is the default initial value.

     0     Insecure mode - immutable and append-only flags may be turned off.
           All devices may be read or written subject to their permissions.

     1     Secure mode - the system immutable and system append-only flags may
           not be turned off; disks for mounted file systems, /dev/mem and
           /dev/kmem may not be opened for writing; /dev/io (if your platform
           has it) may not be opened at all; kernel modules (see kld(4)) may
           not be loaded or unloaded.  The kernel debugger may not be entered
           using the debug.kdb.enter sysctl.  A panic or trap cannot be forced
           using the debug.kdb.panic and other sysctl's.

     2     Highly secure mode - same as secure mode, plus disks may not be
           opened for writing (except by mount(2)) whether mounted or not.
           This level precludes tampering with file systems by unmounting
           them, but also inhibits running newfs(8) while the system is multi-
           user.

           In addition, kernel time changes are restricted to less than or
           equal to one second.  Attempts to change the time by more than this
           will log the message "Time adjustment clamped to +1 second".

     3     Network secure mode - same as highly secure mode, plus IP packet
           filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
           changed and dummynet(4) or pf(4) configuration cannot be adjusted.

     The security level can be configured with variables documented in
     rc.conf(5).
```


----------



## damjank (Oct 7, 2019)

Thank you all for various reminders and suggestions to check. I chose words poorly - I did in-fact not upgrade, I was doing updates since I was using ISO from dec2018 - there were more then 1000 system patches (correct wording?).
Immediately as, suggested, when I raised priority of modules loading eg. as soon as possible in boot process, all modules loaded correctly BEFORE security settings were (thank you k.jacker for the reminder). Now, I have working PF and NTPd.
For the record, nothing was enabled blindly - it was my first system update though; to this date I have never updated system as they all were in completely closed environment but this one and they all were migrated to newer VM on regular basis as per security compliance in company.
Cheers!
Rgd


----------



## SirDice (Oct 7, 2019)

Please get your versions straightened out though, there is a big difference between -RELEASE, -STABLE and -CURRENT.

This is a -RELEASE:

```
dice@case:~ % uname -a
FreeBSD case.dicelan.home 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  amd64
```
This is a -STABLE:

```
dice@molly:~ % uname -a
FreeBSD molly.dicelan.home 12.1-STABLE FreeBSD 12.1-STABLE r353128 MOLLY  amd64
```

Handbook: 23.4. Tracking a Development Branch


----------



## damjank (Oct 7, 2019)

I have 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  amd64 - installed from ISO 12.0 dated 07.12.2018
I did `freebsd-update fetch install` and that got me those 1K patches; I however did not do eg `freebsd-update -r 12.1-STABLE upgrade`


----------



## SirDice (Oct 7, 2019)

You have a -RELEASE version, not -STABLE, -STABLE is a _development_ version. In our case "stable" refers to the API/ABI, not its fitness to run without problems. 



damjank said:


> I however did not do eg  freebsd-update -r 12.1-STABLE upgrade


No worries, it hasn't been released yet. It's still in the beta phase.


----------



## damjank (Oct 7, 2019)

Then we're all good! Thx for aditional clarification, i am marking this as resolved.
rgd


----------

