The rc.d mess strikes back (was Re: ums no longer loads on CURRENT)
yanefbsd at gmail.com
Sun Mar 1 19:41:27 PST 2009
On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote:
> On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote:
>> On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote:
>>> Garrett Cooper wrote:
>>>> device ums # Mouse
>>> This is why you cannot kldload. Not sure about any functional
>> Yeah, well that message was printed out by another process
>> altogether while loading up the kernel after the ata subsystem was
>> brought up, so something's getting confused and trying to kldload
>> by accident... I was just reproducing the message.
>> I'll provide more data to prove this claim when I can.
> Here's the picture from my iPhone: <http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=view¤t=IMG_0032.png
> >. I OBVIOUSLY didn't do the kldload... and because my /boot/
> loader.conf doesn't contain ums_load="YES", I'm really curious who
> the actual culprit is in rc.d land...
> I used to do WITHOUT_MODULES=* to not build modules, but I'm trying
> to move away from that mentality for some things like snd_emu10kx,
> but obviously there's a conflict somewhere for ums; hopefully it's
> merely cosmetic...
Ok, found the culprit. It turns out moused is being called from
devd... this is all probably related to the startup mess I reported 2
weeks ago with my NIC. I'm seeing a lot of additional problems in
terms of keeping track of daemons; for instance syslogd is getting
started up twice, but the first instance isn't recording a PID and the
second one is dying because the first one is bound to the address.
Could we just unwind this rc.d mess? It seems to be causing issues
and wasn't very thoroughly tested before commit.
More information about the freebsd-current