Server Crash Recovery, Forensics, and Data Security Notes - Linux

From Free Knowledge Base- The DUCK Project: information for everyone
Jump to: navigation, search
.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.

 

Archivedhansolocarbonite140.png
Carbonite Page: This page is an archived entry and should not be modified. Information on this page may be out of date, however, still useful. An example is data for legacy systems or outdated technologies that are still being used by some, such as Vacuum Tube bogey values, analog broadcast television frequencies or MS-DOS 6.22 commands. Although outdated, this information will not change or evolve any further. Certain archived pages on the D.U.C.K. Wiki have been imported from our older ANSI BBS system and other storage mediums previously used. These pages are kept unmodified for archival purposes.

Recommended Newer Resources

Q: How to check for bad sectors on system from GUI

A: Goto "Disks" which is the program name you type into the Ubuntu search. Just type "disks." Once the Disks utility opens you should select your hard drive from the left pane. In the upper right corner of the interface is a gear icon that says "More actions" click that and choose SMART Data & Self-Tests (a feature available for any modern S.M.A.R.T. enabled IDE/SATA drive). This works with a drive having that technology and Ubuntu having it enabled. The "Overall Assessment will denote the number of bad sectors. Click "Start Self-test" to refresh. An Extended test may take about 10 minutes for a drive around 80-120gb.

To more thoroughly check for bad sectors and even mark them as bad you can drop to console. You can perfrom a read-only test while the fs is mounted. 

$ sudo badblocks -v /dev/sda1

To mark the bad blocks so that Ubuntu doesnt use them...

write the location of the bad sectors into a file. 

$ sudo badblocks /dev/sda > /home/user/badblocks

Feed the file into the FSCK command to mark these bad sectors as "unusable" sectors. 

$ sudo fsck -l badblocks /dev/sda
Retrieved from "http://wiki.robotz.com/index.php?title=Server_Crash_Recovery,_Forensics,_and_Data_Security_Notes_-_Linux&oldid=10714"