SCHOOL OF TECHNOLOGY AND COMPUTER SCIENCE TATA INSTITUTE OF FUNDAMENTAL RESEARCH
RUNNING LINUX ON A WRISTWATCH PROTOTYPE
Chandra Narayanaswami Chandra received his B.Tech. in Electrical Engineering from the Indian Institute of Technology, Bombay, and his M.S. and Ph.D. degrees in Computer and Systems Engineering from Rensselaer Polytechnic Institute. He currently manages a group on Wearable Computing that is investigating challenging issues in form factors, input devices, navigation, applications, user interfaces, and power management for wearable computing.
hi,
machine ,.. was :-) .. running RHL ( pcq) 7.1 , ext2 filesystem, kernel 2.4.13 not much probs till now.
Suddenly wont boot .. kernel gives error: unable to mount root fs on 03:05 bad descriptor stored on superblock 0 ( something to that effect).. shutdown was proper.
I have tried all the tricks i know ...rescued countless system crashes before... but this one really stumps me. The machine was _FINE_
tried fsck / e2fs ... etc... even tried restoring / booting from rescue disk and restoring from the superblock backups stored inside the filesystem... no luck.
fdisk (linux) shows the filesystem prefectly as if nothing is wrong ..
any ideas ???? Can I get any data back ?? more Important ... why this happened ? In 4+ years off working with linux ... this one really stumps me Am I missing something ?
-.. heres the really amusing part. I had created a mini-os ( to test new kernels / system support at clients places. basically a ramdisk image). loads thru' lilo from the root file system. This WORKS !!!! the main system does not boot from the same system / filesystem... I have got additional 3 kernels to boot my system from ( inside lilo) ... None boot... all the same error..
what i really want to know is _WHY_ this happened . Can anyone please give any tips ? also ... any way of getting my data back ?
( Unless it HDD @ fault... but I doubt it. )
C'ya Erle.
On Tue, 11 Dec 2001, erle wrote:
machine ,.. was :-) .. running RHL ( pcq) 7.1 , ext2 filesystem,kernel 2.4.13 not much probs till now.
Suddenly wont boot .. kernel gives error: unable to mount root fs on 03:05 bad descriptor stored on superblock 0 ( something to that effect).. shutdown was proper.
Probably one of the many file system bugs in the 2.4 series. It has been known to damage file systems on rare occassions. Try using tune2fs, but I'm really not sure what you can do or what the real problem is.
Philip
Probably one of the many file system bugs in the 2.4 series. It has been known to damage file systems on rare occassions. Try using
Bugs ? stable release of the kernel ?.. OOOhhhh ... :-) Hope no Anti-Opensource people R reading this : -) .... ( no offence intended).. ~ just kidding !
Have attached the error generated . you are right Philip .. i guess it is a filesystem error... - EXT2-fs error ( device ide0 (3,5)) : ext2_check_descriptors. Block Bitmap for group 0 not in group ( block 78185643)! EXT2-fs : group descriptors corrupted kernel panic : unable to mount root fs on 03:05
- i am mailing the errors to the kernel guys, and to a mailing list i found for ext2. Lets see what they say. - anyone wants to take a dab at trying to answer this ? I am determined to get to the root cause of this error .
C'ya Erle.
Sometime Today, erle assembled some asciibets to say:
Bugs ? stable release of the kernel ?..
In Linus' own words - `remember not to make major changes in a stable release' - well, almost his own words. Changing the VFS in a stable release is not something most people would do.
Philip
----- Original Message ----- From: "Philip S Tellis" philip.tellis@iname.com To: linuxers@mm.ilug-bom.org.in Sent: Wednesday, December 12, 2001 11:03 PM Subject: Re: [ILUG-BOM] HELP!: unusual filesystem crash
Sometime Today, erle assembled some asciibets to say:
Bugs ? stable release of the kernel ?..
In Linus' own words - `remember not to make major changes in a stable release' - well, almost his own words. Changing the VFS in a stable release is not something most people would do.
Philip
i know philip.. was just kidding... system was a test machine .. :-)
C"ya Erle.
Hi,
I was working on PCQ 7.1 (2.4 kernel) sometime back... and faced the same problem twice.. first time I was able to recover through fsck only but second time without luck... Now I am using another hard disk on primary to boot from it and access the data on this disk on secondary by mounting it. Try if you can mount it from another hard disk and access the data.
That's where the journaled file systems come to use..
-Mayuresh
If memory serves me right, On Dec 11, erle wrote :
e:hi, e: e: machine ,.. was :-) .. running RHL ( pcq) 7.1 , ext2 filesystem, e:kernel 2.4.13 e: not much probs till now. e: e:Suddenly wont boot .. e:kernel gives error: unable to mount root fs on 03:05 e:bad descriptor stored on superblock 0 ( something to that effect).. e:shutdown was proper. e: e:I have tried all the tricks i know ...rescued countless system crashes e:before... but this one really stumps me. The machine was _FINE_ e: e:tried fsck / e2fs ... etc... e:even tried restoring / booting from rescue disk and restoring from the e:superblock backups stored inside the filesystem... no luck. e: e:fdisk (linux) shows the filesystem prefectly as if nothing is wrong .. e: e:any ideas ???? Can I get any data back ?? e: more Important ... why this happened ? In 4+ years off working with linux e:... this one really stumps me e:Am I missing something ? e: e:-.. heres the really amusing part. e:I had created a mini-os ( to test new kernels / system support at clients e:places. basically a ramdisk image). loads thru' lilo from the root file e:system. e:This WORKS !!!! e:the main system does not boot from the same system / filesystem... e:I have got additional 3 kernels to boot my system from ( inside lilo) ... e:None boot... all the same error.. e: e:what i really want to know is _WHY_ this happened . Can anyone please give e:any tips ? e:also ... any way of getting my data back ? e: e:( Unless it HDD @ fault... but I doubt it. ) e: e:C'ya e:Erle. e: e: e: e: e:_______________________________________________ e:http://mm.ilug-bom.org.in/mailman/listinfo/linuxers e:
I was working on PCQ 7.1 (2.4 kernel) sometime back... and faced the same problem twice.. first time I was able to recover through fsck only but
thanks... was about to get down to trying that...
what i really want to know is : 1. why this occured .. if its possible to get down to that 2. Is this specific to Redhat ?
regards Erle.
On Wed, 12 Dec 2001, Mayuresh Bakshi wrote:
I was working on PCQ 7.1 (2.4 kernel) sometime back... and faced the same problem twice.. first time I was able to recover through fsck only but second time without luck... Now I am using another hard disk on primary to boot from it and access the data on this disk on secondary by mounting it. Try if you can mount it from another hard disk and access the data.
You mean you can mount the partition an access it properly if you boot from another partition, but can't boot from that partition? That is beyond strange. 1. What error does it give if you try to boot from the partition? 2. Does fsck pass? Even if you force a check with -f? 3. What about badblocks?
-* long mail*- U have been warned :-) I know i started this thread... but i got my answers, and I guess it may help someone .....
this is a really strange error. I finally got down to the bottom of this
On Thu, 13 Dec 2001, erle wrote:
now when you format a disk.. as usual superblock backups are stored at veriuos locations inside the Hdd. mke2fs usually spits out a series of numbers related to where it has stored these backups.. _ SAVE THIS _ most ignore.
Having ignored it, is it now possible to get it after the format (but before the crash)? If there isn't a utility to do it, there should be one. I suppose the algo they use to determine where to store the superblocks should be documented somewhere. If not, it shouldn't be too hard to look at the source of mke2fs to determine it.
erle wrote:
so you will have to try starting from block 1 ( useless now b/c if it was working .. u wouldn't be trying this.) in multiples of your filesystem. from what I gather its not stored at each multiple... but at a few of them. long & tediuos perhaps.. but serves you . .... me ? :-) right for not storing those superblock backups. ( for those of you giggling away... no I did not do this 80 times... )
if that doesn't work... my guess is... Format
I had faced a similar problem long ago ... the documentation for the disktools (I do not remember which one) does mention the most likely number to use for the alternate superblock, and it works under most systems ... you do not need to try out every block. I am not anywhere near my Linux box right now [it's all powered down and wrapped up in the lab], but I am pretty sure its the fsck manpage that mentions these numbers.
Here's what I had found in a file called "Design and Implementation of the Second Extended Filesystem" , meant for the Kernel Hackers Guide. I don't have the URL anymore, but similar information is probably just a google search away.
"A filesystem is made up of block groups. Block groups are analogous to BSD FFS's cylinder groups. However, block groups are not tied to the physical layout of the blocks on the disk, since modern drives tend to be optimized for sequential access and hide their physical geometry to the operating system.
Each block group contains a redundant copy of crucial filesystem control informations (superblock and the filesystem descriptors) and also contains a part of the filesystem (a block bitmap, an inode bitmap, a piece of the inode table, and data blocks).
Each block group contains a redundant copy of crucial filesystem control informations (superblock and the filesystem descriptors) and also contains a part of the filesystem (a block bitmap, an inode bitmap, a piece of the inode table, and data blocks)."
HTH, SameerDS.
-- MTech Student, Reconfigurable Computing Lab, KReSIT, IIT-Bombay
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
sameer wrote:
I had faced a similar problem long ago ... the documentation for the disktools (I do not remember which one) does mention the most likely
number
to use for the alternate superblock, and it works under most systems ...
true, I have read that too. But its only a guide. U still have to "play" around with the numbers. take this for e.g. ( from: LINUX (UNIX) Unleashed, System Administrator's Edition ) these are given as an e.g.
8193,16385,24577,32769,40961,49153,57345,65537,73729.......
-- None of these worked... what worked for me was 32768.
Just installed Debian .. the second backup block for me starts @ 32768. Next is 65536. .. nothing in between. I had found another document that states try starting from 32767 and in multiples thereof.
Vinay Pai wrote: superblocks should be documented somewhere. If not, it shouldn't be too hard to look at the source of mke2fs to determine it.
that _might_ be possible... havent found any available program to determine the same. Would be interesting. Maybe we should have a go @ writing such a program.... it could be useful.
C'ya Erle.
erle wrote:
take this for e.g. ( from: LINUX (UNIX) Unleashed, System Administrator's Edition ) these are given as an e.g.
8193,16385,24577,32769,40961,49153,57345,65537,73729.......
That is because the book assumes each block group consists of 8192 (2^13) blocks ...
-- None of these worked... what worked for me was 32768. Just installed Debian .. the second backup block for me starts @ 32768. Next is 65536. .. nothing in between.
That is because Debian apparently uses 65536 blocks (2^16) in each group. I now remember I had used 65536 as the place for the alternate superblock on my RHL machine back then ... it seems convenient to use, since it will work for both, Debian machines as well as RHL. Point to note is that these are all just default numbers - they can be different in case of custom formatted filesystems. But using higher multiples will almost always work, since they are likely to encompass even the filesystems with smaller block group sizes ...
Vinay Pai wrote: superblocks should be documented somewhere. If not, it shouldn't be too hard to look at the source of mke2fs to determine it.
that _might_ be possible... havent found any available program to determine the same. Would be interesting. Maybe we should have a go @ writing such a program.... it could be useful.
Superblock positions solely depend on the size of the block group used, which IIRC, can be specified as a commandline argument to mke2fs ... So its basically just a matter of remembering the size that is reported at the time of formatting, which, as Erle remarked, isn't something that we take too seriously :-)
SameerDS.
-- MTech Student, Reconfigurable Computing Lab, KReSIT, IIT-Bombay
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
-
erle -
Mayuresh Bakshi -
Nagarjuna G. -
Philip S Tellis -
Sameer D. Sahasrabuddhe -
Vinay Pai