you certainly been having fun a game, but like anything that happens for the first time in computing, you usual go away knowing more about it, sometimes, in windows you go away knowing more about it than the microsoft developers, which on the whole scares me ;-).<br><br>fsck on mounted partitions is bad.<br><br>fsck on non-mounted partitions are good.<br><br>you may understand now that some linuxes mount thier root file system <br>either in ram, or read only on boot. This allows checking of the root file system too.<br>it's chicken and egg, you can't mount / and check it, if fsck and the kernel need<br>to be mounted. There are some elegant, and not so elegant solutions to this.<br><br>moving partitions at the byte level is bad<br><br>moving partitions as intact filesystems (tar/cpio etc) is good.<br><br>unless you rely on partition image dumps with stuff like ghost and those<br>disk imaging applications, then your asking for trouble. Epically going between<br>disk of
different geometries and sizes..<br><br>http://sourceforge.net/projects/g4l/<br><br>is interesting, I have a bit success with.....<br><br>if fsck throws more than a few errors, it's highly likey that it cant repair<br>anything, any disconnected files, i.e. file that can't find thier parent inode (directory) are move to a folder called lost+found.<br><br>I still can't work out how you corrupted you file system in the first place.<br><br>bugs in filesystem? these are very few, the filesystem is probably one of the<br>most tested components in the system, as it's so critical to the whole running<br>of the o/s. Unless you got some crazy developer or gentoo system and<br>your running a prerelease or experimental filesystem (cool).<br><br>data recovery is a fine art, and if you image everything to being with, then<br>you can't go wrong. You should never work on live data unless you have to..<br><br>you can always plug in a extra cdrom drive, and dd the thing to it,<br>or in fact
push it over the network with netcat.<br><br>I may do a presentation on data recovery techniques if the group feels it<br>would be useful.<br><br>in the meantime check this..<br><br>http://user-mode-linux.sourceforge.net/old/sdotm.html<br><br>it deals with lots of disasters and has solutions, as your working in a uml instance no harmdone... check it out..you'll learn lots.<br><br>if it an consolation, I've never managed to recover a NT filesystem with chkdsk either, chkdsk would always run for a bit and then crashout. leaving with no option but to wipe and reinstall.(and install linux)<br><br>saying that on the amiga, disk doctor would churn a floppy for a while, then rename the disk volume name to 'lazarus'. which means 'risen from the dead'<br><br>seldom did it work, and left you with a blank disk! nice!<br><br>http://en.wikipedia.org/wiki/Easter<br><br>Cheers,<br>Lee<br><br><br><br><br><br>Laters,<br>Lee<br><br><br><br><b><i>gordon dunlop
<gordon@zubenel.freeserve.co.uk></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> I found a couple of methods in how to rescue systems. Firstly, never use <br>fsck or e2fsck (similar to fsck but for ext2/3 systems with more <br>options) on mounted partitions as they will ruin your data. In using the <br>Knoppix 5.1 live CD, the partitions of your hard disk are shown on the <br>desktop but are not mounted. I initially used e2fsck in a terminal (rot <br>mode) with the command<br># e2fsck -y /dev/sdb10<br>This started the process of correcting many errors but when it tried to <br>reallocate 5 inode in the file system it couldn't and starting doing <br>loops in trying to correct these errors. It also reported a corrupt root <br>node, I stopped the error checks. I found out that some other people <br>were having similar problems in a couple of Internet forums. One person <br>use the tune2fs -s
1 command prior to using e2fsck , this turns the <br>sparse super feature on which saves space on big files systems, and <br>restored his system to an operable condition. Another user using logical <br>volume management of his disks in Fedora used the debugfs command prior <br>to using e2fsck where he could resize the inodes and restore his system. <br>I also found out that using a setting of 0 inode size would break the <br>main inode skeletal system and dump the directories to lost+found. I now <br>had Fedora 7 up and running so the only that thing that I required was <br>some data so I opted for 0 inode option.<br># debugfs -w /dev/sdb10 -R "features ^resize_node"<br># e2fsck -y /dev/sdb10<br>The e2fsck program started and asked if I wanted to change the inode <br>size, which was then set to 0. The root node was removed and all errors <br>corrected and the programme finished with the System Modified message. I <br>then mounted the Fedora 6 partition /dev/sdb10, it gave
me the directory <br>lost+found where all the separate Fedora 6 directories, including my <br>/home/Gordon directory. All these directories were numbered (not named) <br>so I had the go inside every one to determine its contents. All I had <br>left to do was transfer the required data from lost+found into my Fedora <br>7 partition. My basic findings were that the corruption in file systems <br>can occur due to hardware errors, media errors, bugs in file systems and <br>certain types of manipulation in partitions. This type of problem <br>occurred to one person when he shrank 2 partitions, he did not mention <br>whether there was any data migration when doing this operation. Also, as <br>disks are getting bigger, resulting in larger and more complex data <br>systems, the chances of the file system increases. In my case I think <br>that my Windows Xp VM did contribute to the situation due to its huge <br>size (20GB) where a problem occurred in trying to reallocate blocks
<br>within the file system. You will find that VM's are probably the biggest <br>files within a system (3~5 GB for nomal Fedora or SuSE VM using Xen). It <br>is probably better to move them to another partition prior to data <br>migration in a partition (If you have no option but to move Operating <br>System). One of the reasons why the Xandros 4 partition moved with no <br>problems compared to Fedora 6 was the difference in size and complexity <br>of the file systems. Xandros had only 360 superblocks compare with <br>approx 1600 in Fedora . The inode size and system in Fedora was also far <br>more complex. There was no data in Xandros, just a basic OS as I just <br>use for its file manager in super-user mode (the best that I have used) <br>to move data and OS's between partitions (using the copy and paste <br>method). The Knoppix live cd has an excellent set of tools to use, there <br>is another Knoppix CD called Knoppix S-T-D where there are all sorts of <br>forensic,
network and other tools (people doing the ethical hacking <br>course at Abertay would find this CD interesting. Finally, I would not <br>like to go through the above experience again but in some ways I am glad <br>it happened as it gave me a steep learning curve in file systems and <br>system rescue. I hope this post is helpful to other people who may find <br>themselves in a similar situation in the future.<br><br>Gordon<br><br><br>_______________________________________________<br>dundee GNU/Linux Users Group mailing list<br>dundee@lists.lug.org.uk http://dundee.lug.org.uk<br>https://mailman.lug.org.uk/mailman/listinfo/dundee<br>Chat on IRC, #tlug on dundee.lug.org.uk<br></blockquote><br><p> 
<hr size=1>
Yahoo! Answers - Get better answers from someone who knows. <a
href="http://uk.answers.yahoo.com/;_ylc=X3oDMTEydmViNG02BF9TAzIxMTQ3MTcxOTAEc2VjA21haWwEc2xrA3RhZ2xpbmU">Try
it now</a>.