On Thu, 10 Mar 2016 07:16:05 +0900, Brendan Sechter <sg...@hotmail.com> wrote:
> > Subject: Re: limits: setrlimit umtxp: Invalid argument
> > From: florian.ermi...@alumni.tu-berlin.de
> > Date: Wed, 9 Mar 2016 18:45:37 +0100
> > To: e...@vangyzen.net; sg...@hotmail.com; email@example.com
> > Am 9. März 2016 16:59:47 MEZ, schrieb Eric van Gyzen <e...@vangyzen.net>:
> >> On 03/09/2016 09:49, Brendan Sechter wrote:
> >>> I am running an 11.0-CURRENT VM.
> >>> After recently updating, the following appears on startup and
> >>> dhclient fails to start.
> >>> Starting dhclient.
> >>> limits: setrlimit umtxp: Invalid argument
> >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> >>> Similar messages appear for the following.
> >>> devd pflog syslogd ntpd powerd sshd sendmail_submit
> >>> sendmail_msp_queue cron
> >>> Reverting to the previous kernel did not resolve the issue.
> >>> I can manually start dhclient and ntp, but not sshd.
> >>> I do not trust that my uname information is being updated with
> >>> with build, but here it is.
> >>> $ uname -vm
> >>> FreeBSD 11.0-CURRENT #0 r287598: Thu Sep 10 14:45:48 JST 2015
> >>> root@:/usr/obj/usr/src/sys/MIRAGE_KERNEL amd64
> >> This information comes directly from the running kernel, so it looks
> >> like your kernel is not getting updated. This seems consistent
> >> with the above error messages, although I haven't tested this
> >> case. The userland tools are aware of the newly added umtxp
> >> limit, but the kernel is not aware.
> >> Eric
> > I got this problem on my laptop, too. I somehow managed not to
> > install the kernel during a recent update so my userland is slightly
> > newer than my 11-CURRENT r292755 kernel (and also forgot to
> > make proper ZFS snapshots…).
> > While I can build a newer kernel but when I boot i.e. r296556
> > `zfs(8)' coredumps and I can't mount anything but the rootfs…
> > I guess I need to get kernel & userland back in sync to fix this.
> > I will try to build the userland matching my kernel first as
> > I know its revision from `uname -a`.
> > If anyone has a better approach or tips, please let me know.
> My userland was up to date. This is what I did to get the kernel
> in sync enough to resolve the issue.
> svn up /usr/src # omit if want to use the exact same version as world
> cd /usr/src
> make buildkernel KERNCONF=MYKERNEL
> make installkernel KERNCONF=MYKERNEL
> I found a problem with my kernel configuration in the process.
> The plan is to rebuild everything after the configuration issue is
> sorted out. You may wish to use GENERIC just to get things up
> and running again.
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
I've a working pf.ko kernel and nvidia.ko from r288246 Sep 26 2015 and an
buildworld from yesterday Apr 20 2016. The kernel is custom and I've also a
loader.conf. I've no wish to run GENERIC with either debugging symbols nor
sendmail_submit is broken, not a showstopper but root gets none of his mail.
cron is broken, not a showstopper but one cron I've setup does not run
Per this thread which narrowed down the issue of out of sync problems,
dhclient devd pflog syslogd ntpd and sshd *if I had them used* would be
not functional. Unsure in each case.
Given a 2004-ish custom kernel, a GENERIC from this month, and a GENERIC from
Sept 2015, is there
any not time consuming way to do a diff between two or three of them and bring
kernel upto par with the GENERIC as far as bootability, considering the
possibility that it is
a loader.conf setting that is at fault?
something like /sbin/kernel-too-old
" please check foo foo from loader conf " or "please check bar bar from
CUSTOM-K " or even
" foo bar from CUSTOM-K is missing... "
...a utility that would lessen the need for adding/subtracting blocks
of (custom ) kernel stuff to/from generic and recompiling one-by-one,
or vice-versa, to/from the custom kernel config,
seems like a 40 day project UNLESS someone
has run into a similar custom -vs- generic situation as a matter of course and
has a workflow to
lessen whatever time and compilation effort it takes, which is basically what I
am asking here unless
a summer of code expert coder of FreeBSD fame knows that the hypothetical
binary above could
be crafted more easily than not and be a tool for developers as well as simple
FreeBSD users such
PS I encourage anyone with a readily helpful answer to add it to UPDATING as a
persons other than myself who encounter the same difficulty...
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"