Re: Fixing the UniPlus+ root disk fsck by hand (very very long)

gilles wrote:
> As I said in the previous subject, if we replace the inode index just
> before the string "etc" with something
> that points to a real directory, the corresponding sectors are read
> but since it does not
> find the init file... it fails... (I suppose).
> I've tried some values from 01 to 15 but I'm not sure the inode table
> is still holding the correct
> entry for /etc directory... (I've found a correct dir with this
> method, that may be bin or usr)
>

That's right, replacing the inode numbers in the directory entries, as suggested in the previous post you refer to, isn't enough. (This is because the actual inodes themselves have been zeroed out) Also trying random values from 1-15 won't help. The inodes themselves must contain the proper data for the OS to find the file's actual data, and in this case, they did not, they were erased.

So what's needed is:

1. If you find the directory entry blocks for what should be /etc, /bin, and /dev (all of which have had their inode #'s zeroed out in the root directory), you'll see that they contain entries for "." and ".." The "." entries give us the needed inode numbers of 6, 7, 8 - thus we know what inodes were previously used. ".." in all of these points to inode 2, which if you look at the root directory, you'll see both "." and ".." both point to inode 2 - so we know that root's inode is 2.

The candidate directory entries all have ".." pointing to inode 2, this confirms that the directories we think are /etc, /bin, and /dev really are children of root and have a very high probability of being the right ones - we don't have to guess between /usr/bin and /bin, we know from the ".." inode that they belong under /.

2. However, if you look at the inodes themselves (6,7,8), you'll find that all the data that should be contained therein is completely zeroed out.

3. If you also look in the superblock, you'll find that inodes 6,7,8 are in the free inodes list.

So that means some sort of delete operation was performed against /etc, /dev, and /bin. (It might have been rm -rf /, but it's a very strange form of it, if so, since rm -rf should recurse depth first, but it's possible it went breadth first and was interrupted - this would explain the damage seen.)

So, in order to address these issues, you must do 3 things to undo the damage, the details of which you can find in my long post. To summarize the steps taken were:

1. You'll need to edit the root directory block to replace the 00 00 inode numbers for /etc, /dev, and /bin with the proper inode values (6,7,8)
2. You'll need to edit the actual contents of the inodes to contain the octal permission, the number of links, uid/gid, file size, the pointers to the data blocks, and create/modify/access dates.
3. You must remove inodes 6,7,8 from the deleted inode list in the superblock. This is necessary to prevent the booting UniPlus OS from using these inodes as it may create temporary files for its own use.

So now that all that is done, and Andrew has reported that it still doesn't work, the next questions are:

1. Did I have some sort of typo in my previous post which broke one or more of the 3 fixes?
2. What else is broken with the root disk?

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "LisaList" group. To post to this group, send email to lisalist_at_email.domain.hidden To unsubscribe from this group, send email to lisalist-unsubscribe_at_email.domain.hidden For more options, visit this group at http://groups.google.com/group/lisalist?hl=en -~----------~----~----~----~------~----~------~--~--- Received on 2008-03-26 04:11:37