Difference between revisions of "Server Crash Recovery, Forensics, and Data Security Notes - Linux"
From Free Knowledge Base- The DUCK Project: information for everyone
(New page: <nowiki>.Crash Recovery, Forensics, and Data Security Notes (Why my b0x3n crasged!?!?.</nowiki> <nowiki>.Helping you get UP and RUNNING safely and secure.............................</no...) |
(No difference)
|
Revision as of 14:28, 25 June 2007
.Crash Recovery, Forensics, and Data Security Notes (Why my b0x3n crasged!?!?. .Helping you get UP and RUNNING safely and secure............................. . . . XXXXX XXXXX XXX XXXXXX X X XXXXXX XXXXX . . X X X X X X X X X X X X . . X X X X X XXXXX XXXXXXX XXXX X X . . X X XXXXX XXXXXXX X X X X X X . . XXXXX X X X X XXXXXX X X XXXXXX XXXXX . .................................................Sat Aug 6 21:56:16 CDT 2005. 1] Mounting proc filesystem fails on boot: dup2: Bad file descriptor While booting the system haults at the following message: "Mounting proc filesystem dup2: Bad file descriptor." After running fsck everyting is clean and the system will still hault on the same error. This error is actually happen because the /dev/null entry in the device inode permission is incorrect. To get the system back up and running you must correct the problem with /dev/null. Enter the root password at the service prompt and remount the root filesystem read/write, delete /dev/null and create a new one. mount -n -o remount,rw /dev/sdxX rm -rf /dev/null mknod -m 666 /dev/null c 1 3 Change /dev/sdxX to the root partition. [cause analysis]: /dev/null was modified by (user, something installed, an intruder) giving it incorrect permissions or changing it to a regular file. This can also be caused if user does 'mv filename /dev/null' for example. It is not likely that this condition was created by an intruder. It is more likely the result of operator error.