xfs_repair will fix your file system unfortunately
it will not get rid of the duplicate entries in the directory.
I suggesting that people try this to get their systems in shape.
copy the /etc directory to a fresh directory this will get
you back to one copy of each file.
Move the old directory out of the way and move the new directory
in place.
rsync -av /etc/ /etcTMP/
mv /etc /etcNOT
mv /etc/TMP /etc
Try to rm -rf /etcNOT
This will probably not fully remove the directory as it won't be able to
rm the duplicate files.
The system shouldn't have any problems at this point as /etc should be
correct.
Getting rid of the bad /etc dir will involve some xfs_db tricks that
I have not worked out yet.
Ohh and make sure to checkout the latest kernel from CVS
On Fri, 2003-01-10 at 16:26, Michael Sinz wrote:
> This is with a CVS checkout from the end of December (12/29/2002)
>
> Today, I started to get errors trying to access /etc/mtab
> Everything else looked fine.
>
> I then did an "ls" in /etc and got multiple errors about not
> being able to stat "mtab" (yes, multiple ones)
>
> I rebooted onto a different partition and ran XFS_CHECK and XFS_REPAIR
> on the partition in question and then rebooted.
>
> Now, when I do "ls /etc/mtab*" I get 12 files shown, all with the
> same size/date/etc.
>
> I tried to delete /etc/mtab and I got 12 errors.
>
> I am doing yet another XFS_REPAIR now, but XFS_CHECK did not
> report any errors so I doubt that anything would show up.
>
> This machine is on a UPS and has not had any crashes/dirty shutdowns
> in a long time. It has been running XFS for a long time now.
>
> I will try to get more details but I was in need of getting that
> machine running again so did not have a chance to grab as much
> data as I wish.
>
> BTW - The kernel is exactly from CVS with only one patch that I did
> for named core dumps (based on host name and program name). There are
> no funky drivers or other items (in fact, the kernel does not even
> have support for loadable modules enabled)
>
> Again, I am sorry that I did not get a chance to dig deeper but this
> machine needed to be back in service "asap" (one of the reasons it
> runs XFS :-)
--
Russell Cattelan <cattelan@xxxxxxxxxxx>
|