Brad wrote: > I'm just curious what the point of sending the dmesg was? All things considered, I'd rather have five things I don't need than have one thing I wanted that was missing. If for nothing else, it's a refreshing Something Different from the "Send me some useful info!" exchanges). Heck, how many times have I spotted something in a "unneeded" dmesg that actually did or may have pertained to the user's question? (A: lots!)
If nothing else, dmesg tells us if someone is running a Theo-built kernel, a home-built GENERIC (which we have to take with a big grain of salt until we commit those changes that prevent even root from editing /usr/src/sys/arch/*/conf/GENERIC), or a definite Ricer, which are details that aren't always communicated accurately through other means. Granted, in this case, OpenBSD was working perfectly, VMware was blocking certain keystrokes, but obviously the OP didn't recognize that, or they wouldn't have posted here. Hey, not sure reassigning the "release" sequence would have occurred to me if one of my coworkers hadn't said, "You'll want to change that so CTR-ALT-F<n> works". I've also discovered there are ways to configure VMware so it doesn't work with OpenBSD. Besides, I haven't seen a VMware 5 dmesg yet, and we all know how excited I get over dmesgs. :) (what's the point of YOUR sending the dmesg again, rather than trimming down the reply? :) If in doubt, send the dmesg. If you think it isn't necessary, send the dmesg. If you are absolutely sure the question has nothing to do with hardware (or virtual hardware), and you have confirmed the situation on five different platforms, dmesg is optional. In my opinion, of course. :) However, my time lately is much less, there are lots of messages I've been completely ignoring (or laughing at to myself as others try to "help" the clueless, but still never ask for the obvious first-step in debugging) because I don't have time to beg for every bit and piece of info to verify (or disprove) a suspicion. Nick. (dmesg, dammit!)
