I got 2 possible explanations as to how the files in /dev could have changed
from device files to regular files. Neither one applies to me, so I'm still
at a loss.
The messages are not long, so I'll include them here:
FROM Marco Luchini:
The only times I've seen files in /dev/ trashed in that way is when root had
accidentally done a tar pipe or a dump pipe onto the same filesystem.
Because of the fact that the same files are being written that are being
read you end up with really bizarre errors. Something like:
(cd /; tar cf - . | (cd /; tar xpf - )
instead of
(cd /; tar cf - . | (cd /mnt; tar xpf - )
or the equivalent mistake with dump...
FROM George Gallen:
we you moving files around using the cp command?
if you use "cp -r xxxx" instead of "cp -R xxxx" that will do it.
-r will copy FIFO/character files as regular files, -R will descend into
subdirectories.
Possibly trying to setup new partitions or move partitions and tried to
copy entire directories but used the -r instead of -R?
Thanks everyone.
Tom Bacevicius
-----Original Message-----
From: Bacevicius, Tom
Sent: Tuesday, September 14, 1999 11:20 AM
To: Tru64-Unix-Managers (E-mail)
Subject: SUMMARY (& question): Please help figure out
why my 2100 (4.0D PK2) didn't boot
I got a few very helpful suggestions. Thanks to everyone who
responded:
It turns out that the reason the system wouldn't boot was
because many of the files in /dev were somehow changed from device files to
regular files. The file in specific that was causing the system to freeze
was /dev/console. Its permissions were set as '-rw-r--r--' when it should
have been 'crw--w--w-' . I had to rename it and run `MAKEDEV console` to
repair it.
HOW COULD THIS HAPPEN?
/dev/console was not the only file with this problem. Most,
if not all the Standard Device Files were damaged this way. I had to remove
them all and run `MAKEDEV std`.
More help would be appreciated. Thanks everyone.
Tom Bacevicius
-----Original Message-----
From: Bacevicius, Tom
Sent: Friday, September 10, 1999 4:33 PM
To: Tru64-Unix-Managers (E-mail)
Subject: Please help figure out why
my 2100 (4.0D PK2) didn't boot
Hello folks,
I am hoping you all can help me figure out
why my system didn't boot.
I was eventually able to get it booting, but
only after restoring from backup. The problem is that to the best of my
knowledge, nothing on the O/S had changed from the time of the backup.
I need to figure out the root cause for this
problem, but am at a loss. Any insight or suggestions would be greatly
appreciated.
Here is the output of my boot sequence. I
will point out where it stopped.
# uerf -R -r 300
EVENT CLASS
OPERATIONAL EVENT
OS EVENT TYPE 300.
SYSTEM STARTUP
SEQUENCE NUMBER 1.
OPERATING SYSTEM DEC
OSF/1
OCCURRED/LOGGED ON Sun
Aug 29 19:17:01 1999
OCCURRED ON SYSTEM
testbox1
SYSTEM ID x00060009 CPU
TYPE: DEC 2100
SYSTYPE x00000000
MESSAGE
Alpha boot: available memory from
_0x119a000 to 0x1ffee000
Digital UNIX V4.0D (Rev. 878); Sun
_Aug 29 14:49:29 CST 1999
physical memory = 512.00 megabytes.
available memory = 494.32 megabytes.
using 1958 buffers containing 15.29
_megabytes of memory
Master cpu at slot 0.
Firmware revision: 5.2
PALcode: Digital UNIX version 1.45
ibus0 at nexus
AlphaServer 2100 4/275
cpu
0 EV-45 4mb b-cache
cpu
1 EV-45 4mb b-cache
cpu
2 EV-45 4mb b-cache
gpc0
at ibus0
pci0
at ibus0 slot 0
tu0:
DECchip 21040: Revision: 2.3
tu0
at pci0 slot 0
tu0:
DEC TULIP (10Mbps) Ethernet
_Interface, hardware address:
........................ etc
.......
My boot stops immediately after the lines:
...
cpu 0 EV-45 4mb b-cache
cpu 1 EV-45 4mb b-cache
cpu 2 EV-45 4mb b-cache
The system just sits there waiting at this
point. A Compaq technician confirmed that this is not a hardware problem.
If there is any further information that I
can provide, please let me know.
I appreciate any help offered.
Tom Bacevicius
Received on Wed Sep 15 1999 - 15:50:20 NZST