Site Home Page
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Compiling
Installation
Building filesystems
Troubles
User Contributions
Related Links
The ToDo list
Projects
Diary
Thanks
Contacts
Tutorials
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Virtual Networking
Management Console
Kernel Debugging
gprof and gcov
Running X
Diagnosing problems
Configuration
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
How you can help
Overview
Documentation
Utilities
Kernel bugs
Kernel projects
Screenshots
A virtual network
An X session
Transcripts
A login session
A debugging session
Slackware installation
Reference
Kernel switches
Slackware README
Papers
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
WVU 2002 (html)
Fun and Games
Kernel Hangman
Disaster of the Month

The Sysadmin Disaster of the Month

Each month, we will introduce a disaster scenario and accept submissions of recovery procedures from them. For examples of good disasters, see my O'Reilly article here.

If you're new to UML, you'll probably want to read the following pages before starting to solve this month's problem:

The December 2001 Disaster
This month's disaster involves a trashed filesystem. To create the disaster, boot up UML with a COW-ed or copied root filesystem, and zero out the root filesystem's superblock:
dd if=/dev/zero of=/dev/ubd/0 seek=1 bs=1024 count=1
You will then get all kinds of nasty-loooking stuff in the kernel log such as:
                
EXT2-fs error (device ubd(98,0)): ext2_write_inode: bad inode number: 50571
EXT2-fs error (device ubd(98,0)): ext2_write_inode: bad inode number: 33108
EXT2-fs error (device ubd(98,0)): ext2_write_inode: bad inode number: 32987
EXT2-fs error (device ubd(98,0)): ext2_write_inode: bad inode number: 33165
EXT2-fs error (device ubd(98,0)): ext2_write_inode: bad inode number: 33112
EXT2-fs error (device ubd(98,0)): ext2_write_inode: bad inode number: 34175
EXT2-fs error (device ubd(98,0)): ext2_new_block: block(1006) >= blocks count(0) - block_group = 0, es == a0a8c400 
EXT2-fs error (device ubd(98,0)): ext2_new_block: block(1116) >= blocks count(0) - block_group = 0, es == a0a8c400 

              
You can try running halt, but it probably won't work, so shut it down with the mconsole instead:
                
(debian) sysrq u
OK 
(debian) halt
OK 

              
Your mission, should you choose to accept it, is to restore this filesystem to health.
Submit your solution
If you have a solution to this month's problem and you want it to be immortalized on this very site, submit it here.

I will pick one or more winning solutions based on criteria such as

  • originality - all else being equal, I like non-obvious solutions
  • subtlety - if applicable, small fixes are better than big ones
  • brevity - short and sweet is better than long and involved
  • parsimony - the fewer external resources you need, the better

Who you are (any identification is OK, including none at all)

Your billiant recovery:

Propose a disaster
If you have a scenario which you think would make a good Disaster of the Month, please submit it here. If you have a good solution, include it as well. Disasters which have actually happened in real life are especially good, but anything which can happen on a physical box is fine.

Each month, I will look over the submissions and choose an interesting one to feature as that month's disaster of the month.

Who you are (any identification is OK, including none at all)

Your disaster:

Hosted at SourceForge Logo