Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sat, 26 Nov 2005 00:05:27 -0500 jbk <jbk at mail2.gis.net> wrote: > I have had two types of experiences with system craches. The > first type the automatic journal recovery succeeds and the > boot continues as normal. In the second, the journal > recovery fails and you are dumped to a prompt where you have > to decide what tool to use. From this point I have had > disastrous results using fsck without rebooting with a > rescue disk. Recovering the root file system is a bit different from other file systems. When fsck runs during the boot process, the root file system is mounted read-only and the other file systems are not mounted. It is ok to do a full recovery on a file system that is not mounted, but not root. The reiser fsck utility will not allow you to do a complete repair on root unless you boot from recovery. Ext2 and ext3 do allow a repair of the root file system when your system is running, but that file system MUST be mounted read-only. If you try to repair a mounted file system that is mounted as read-write, the system will write the in-memory data back onto that file system, and then you are screwed. The best practice is to boot from a recovery disk and perform the repair while the root file system is unmounted. (This is true with all Linux and Unix systems). You can then mount that file system from the recovery disk and check it out. (Make sure that your recovery disk contains the proper file system and utilities at the same rev. of what your system is running. My old laptop had a bad memory chip, and it would cause my file system to trash on occasion. Additionally, I had a failing power supply on my home system causing similar results where I had to recover the file systems. (And I'm no stranger to recovering commercial Unix file systems). -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20051126/593d4f46/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |