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. > > Regards, > -Brendan > _______________________________________________ > firstname.lastname@example.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > 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 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... _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"