Re: limits: setrlimit umtxp: Invalid argument

On Thu, 10 Mar 2016 07:16:05 +0900, Brendan Sechter <sgeos_at_hotmail.com> wrote:

> > Subject: Re: limits: setrlimit umtxp: Invalid argument
> > From: florian.ermisch_at_alumni.tu-berlin.de
> > Date: Wed, 9 Mar 2016 18:45:37 +0100
> > To: eric_at_vangyzen.net; sgeos_at_hotmail.com; freebsd-current_at_freebsd.org
> >
> > Am 9. März 2016 16:59:47 MEZ, schrieb Eric van Gyzen <eric_at_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_at_:/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.
> 
> Regards,
> -Brendan 		 	   		  
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"


I've a working pf.ko kernel and nvidia.ko from r288246 Sep 26 2015 and an installed
buildworld from yesterday Apr 20 2016.  The kernel is custom and I've also a large-ish
loader.conf.  I've no wish to run GENERIC with either debugging symbols nor sound enabled.

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 the custom
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
as myself...

Thanks
PS I encourage anyone with a readily helpful answer to add it to UPDATING as a resource for
persons other than myself who encounter the same difficulty...