Re: [gentoo-user] Corruption in reiserfs partition

[Jorge Peixoto de Morais Neto]

On 9/8/07, Volker Armin Hemmann <volker.armin.hemmann@××××××××××××.de>
wrote:
>
> On Samstag, 8. September 2007, Jorge Peixoto de Morais Neto wrote:
> > http://forums.gentoo.org/viewtopic-p-4225196.html#4225196
> >
> > Hi. The forums being down, can you give me help by mail on the topic
> > http://forums.gentoo.org/viewtopic-p-4225196.html#4225196, since I can't
> > use my Gentoo installation until the problem is solved?
> >
> > The most important thing to me is to know the answer to the two
> questions:
> >
> > 1) How can I know if other files were corrupted?
>
> well, you can try a script that compares the md5sums of the files
> installed
> with the m5sums of the files on the harddisk. But everything that wasn#t
> installed with portage can't be checked that way.

There is a equery command for that... equery check if memory serves. But I
issued this command some days ago and it always reports some files as
different... so I guess it is normal for one or two files out of 1000 in a
package to be modified without Portage knowing... but I want to know about
the packages that were modified *because of the corruption.*, not the ones
that were modified because of other reasons... but, perhaps this is the only
option: issue equery check and
1) if the checksum match I know it was not corrupted
2) if it does not match than it may or may not be because of the corruption

Too bad it does not apply to files not managed by Portage.
Hum, perhaps I should have made checksums of my personal data? Obviously,
nothing substitutes a backup, but for data that is not worth backing up
(because it is huge - thus costly to back up - and I can withstand a small
chance of losing said data, since I can obtain it again; a rip of a DVD
movie for example) I could at least save checksums, so if the file gets
corrupted, at least I'll know...


> 2) Do you think I should just use the computer, after reemerging the
> > packages that provide the corrupted files?
>
> yes

Do you think that there is any plausible chance that using the partition
might cause further damage?


> The background is: a corruption ocurred in my reiserfs partition, possibly
> > due to hardware problems; I performed reiserfsck and recovered virtually
> > all files, but at least some files in /bin are corrupted. In fact, they
> > cannot be executed, and executing the "file" command on them tells that
> > they are just "data" instead of recognising them as an executable. See:
> >
> >
> > jorge@jorge:/media/hda2/bin$ for file in *; do file "${file}" | grep -q
> > data && wc -c "${file}"; done
> > 13772 basename
> > 13500 chroot
> > 27048 cut
> > 79420 dir
> > 13836 dirname
> > 59084 du
> > 13436 env
> > 23336 expr
> > 24516 head
> > 14644 mkfifo
> > 18988 readlink
> > 34100 rm
> > 14684 rmdir
> > 17740 seq
> > 14772 sleep
> > 65168 sort
> > 37380 stty
> > 12584 sync
> > 35852 tail
> > 34328 touch
> > 27492 tr
> > 12200 true
> > 12800 tty
> > 15316 uname
> > 79420 vdir
> > 23108 wc
> > 12876 yes
> >
> > Aren't all these files part of coreutils?
>
> not all, but most of them.
>
> >
> > For more details, see the forum thread.
> > I would appreciate any help. Thanks.
>
> It doesn't look so bad. You can try moving the corrupted stuff to a backup
> dir, and create symlinks to busybox. Busybox should be installed on your
> system.

Yes it is.

for example
> ln  -s busybox rm

Gentoo should have an automated way to do this. For me, it looks like there
should be an eselect option for "activating" busybox.


> I hope you learned your lessons!
>
> Lesson 1: /home on its own partition.

I read somewhere that most of the time when a disk fails it will take all of
its partitions with it, so putting /home is its own partition does not help.

Perhaps that person was wrong... at least in my case, I clearly had a
logical failure in the partition, with no physical failure in the disk, so
if I had multiple partitions, maybe only one would have problems.


> Lesson 2: backups.

Hehe. Yes I know. Fortunately it seems I was very lucky this time...