Well, we had one system on which you couldn't log in on the console for a while after rebooting, but it'd start working sometimes. What was happening was that the manufacturer had, for some idiot reason, hardcoded the names of the terminals they wanted to support into getty (this manufacturers own terminals, that I can understand, but also a handful of common types like adm3a) so getty could clear the screen properly (I guess hacking that into gettydefs was too obvious or something). If getty couldn't recognise the terminal type on the command line, it'd display a message on the console reading "Unknown terminal type pc100". We ignored this flamage, which was a pity. 'Cos that was the problem.
It did this *before* opening the terminal, so if it happened to run between the time rc completed and the getty on the console started the console got attached to some random terminal somewhere, so when login attempted to open /dev/tty to prompt for a password it failed.
Moral: always deal with error messages even when you *know* they're bogus.
Moral: never cry wolf.
> I'll mount it in /tmp
Though this may strike most sane sysadmins as bad practice, SunOS (3.4 or so - my memory is vague) shipped a command called "on". If you were logged on machine A and wanted to execute a command on machine B, you said "on B command", sort of like rsh.
However, A would mount B's disks under some invokations of "on" and it would mount it in /tmp! Of course, lots of folks got bitten by this stupid command and it was taken out after a long delay by Sun.
Anyone remember the details? I've blocked out my memory of pre-4.0 SunOS. Am I just hallucinating?
After changing my /etc/inittab file, I was going to kick init by sending it a HUP signal to tell it the file had changed. Unfortunately, I missed and the 1 became a Q... kill -q 1. Large systems die in interesting ways when you lose init!