kernel older than base

[jb_daefo]

I've a BSD (freebsd, apologies for posting in OpenBSD, but maybe persons who browse OpenBSD might know, I've on my calendar to delete this post in a week's time if possible if someone messages or replies that no answer is available properly in this subforum)

kernel that is seven or so months behind the base. Thus
sendmail, cron, and seven other do not work, but by
nvidia.ko pf.ko and the older kernel, functionality was restored
( the custom kernel (older) works and the newer ( custom ) one
dumps core )...

Someone knows of which way to fix

adapt generic >> custom kernel file and test
adapt custom >> generic kernel file and test
know in advance of those two, if a line(s) in /boot/loader.conf are at fault.
or a fourth method.

I've also posted to the freebsd-current mail list... no reply so far.
Almost had no use of the newly installed system at all... so seeking
any and all expertise.

*mods* feel free place this post elsewhere if it should be there or
ask for editing so I can merge them somewhat if need be... as I
said above I plan to delete this post if it wastes anyones time...

[Carpetsmoker]

Fetch the kernel.txz and/or base.txz from the FTP server, e.g.:

ftp://ftp.freebsd.org/pub/FreeBSD/re.../10.1-RELEASE/

extract, reboot, PROFIT!

I'm confused why you're posting this in OpenBSD and not FreeBSD though ...

[ocicat]

Moved to FreeBSD General forum.

[jb_daefo]

Alas, it is a mismatch between v11 Sept 2015 and v11 Apr 2016... not a release.

[Carpetsmoker]

Just get the closest release. Usually not having an exact match is fine.

And you can also overwrite both base and the kernel, that's effectively the same as a reinstall except that you don't lose all the stuff outside base (e.g. /etc, /var, /usr/local, etc.)

In dem olden days the sets came with an install script, but no longer seems to be the case. You probably want to make sure that:

- base.txz doesn't overwrite stuff you don't want it to overwrite (like stuff in /etc. IIRC it doesn't, I haven't used FreeBSD in two years so perhaps this changed).
- Use the correct flags to tar to preserve permissions, flags, and such.

You may also be able to use my pkg_sanity script to clean up some of the mess, by the way.

[jb_daefo]

Happened to fix it just then. Almost. some questions remain...
I used a GENERIC with minimal debugging and sound removed.
Still dumped core.
I moved loader.conf out of the way.
Works. ... uname r298350 from two days ago about.
Still to do... add in custom kernel settings / loader.conf (latter first) several lines at
a time to see where the problem may be.
If the loader.conf is fixed by a setting or two removed, then I may simply copy/reinstall
the custom kernel from that r298350 which has already been built and retest.

tl;dr the loader.conf probably has a problematic setting or one or several, and also
maybe the custom kernel is missing something essential to restore almost all of the
lines in the loader.conf. IOW it could be not one but 2 or three, but I suspect not more
than two problematic lines in the custom kernel and/or the loader.conf

At any rate it all appears workable right now. Just a matter of time
To reiterate, this is v11...

[jb_daefo]

# out snd_pcm_load="YES"
# out snd_acm_load="YES"
# out kern.msgbufsize="130000"
# out kern.ipc.shmmni="1024"
# out kern.ipc.shmseg="1024"
# out hw.snd.maxautovchans="4"
# out hw.snd.targetirqrate="36"
# out hint.pcm.0.buffersize="65536"
# out hw.snd.verbose="3"
# out kern.ipc.semmns="240"
# out kern.ipc.semume="40"
# out kern.ipc.semmnu="120"
# out vfs.read_max="128"
# out kern.randompid="1"
# out kern.ipc.shmmax="67108864"
# out kern.ipc.shmall="32768"
# out vm.kmem_size="700M"
# out vm.kmem_size_max="700M"
# out vfs.zfs.arc_max="250M"
# out kern.sched.preempt_thresh="224"
# out vfs.usermount="1"
# out kern.geom.part.check_integrity="0"
# out vm.overcommit="1"
# out kern.maxfilesperproc="65536"
# out kern.ipc.somaxconn="1024"
# out kern.ipc.nmbclusters="81920"
# out kern.fallback_elf_brand="3"
# out vfs.write_behind="0"


Removed those (about half of what was there) from
loader.conf... custom kernel restored and working fine.
...................
Remains to be seen which is problematic and/or has
a wrong value assigned to it...

So solved almost completely for now.

And learned a few tricks...

[jb_daefo]

Originally Posted by jb_daefo

# out snd_pcm_load="YES"
# out snd_acm_load="YES"
# out kern.msgbufsize="130000"
# out kern.ipc.shmmni="1024"
# out kern.ipc.shmseg="1024"
# out hw.snd.maxautovchans="4"
# out hw.snd.targetirqrate="36"
# out hint.pcm.0.buffersize="65536"
# out hw.snd.verbose="3"
# out kern.ipc.semmns="240"
# out kern.ipc.semume="40"
# out kern.ipc.semmnu="120"
# out vfs.read_max="128"
# out kern.randompid="1"
# out kern.ipc.shmmax="67108864"
# out kern.ipc.shmall="32768"
# out vm.kmem_size="700M"
# out vm.kmem_size_max="700M"
# out vfs.zfs.arc_max="250M"
# out kern.sched.preempt_thresh="224"
# out vfs.usermount="1"
# out kern.geom.part.check_integrity="0"
# out vm.overcommit="1"
# out kern.maxfilesperproc="65536"
# out kern.ipc.somaxconn="1024"
# out kern.ipc.nmbclusters="81920"
# out kern.fallback_elf_brand="3"
# out vfs.write_behind="0"


Removed those (about half of what was there) from
loader.conf... custom kernel restored and working fine.
...................
Remains to be seen which is problematic and/or has
a wrong value assigned to it...

So solved almost completely for now.

And learned a few tricks...

.................................................. ................
and now nfe0 seems to drop out randomly after a few hours. I emailed
the freebsd-current list [another person had similar issues]... perchance
someone knows of an MTU , duplex, nfe sysctl, one of those
sysctls above that was removed, another add-in card, a second card
that may work after the first drops out [ sort of like lagg0 ], or some
other workaround [ a more stable driver/chipset to use... ]
[ slight chance it is due to many areas of this local area switching
from [redacted] to [ redacted ], but that is not the broadband provider here,
so it would be some hop upstream... and works again upon reboot
so doubtful...

[jb_daefo]

Never mind about the sysctls... I"ve loaded some at CLI, found
one invalid, one giving a false or after-boot return, problems with
three, etc. so they are categorized. Only the nfe0 question remains
but it may/may not be fixed with at-present included newly OR at-present
excluded newly so for now it is best *locally* tested, except for the
other chipset card or MTU questions... apologies for not having
posted a week later when I had more to input, or had solved it.

[jb_daefo]

May have found a fix for the nfe0 problem... a script to not-constantly ping just a few times a domain on the web... uptime went from 1, 3 hours to six hours (just once so far...)