View previous topic :: View next topic |
Author |
Message |
skunkworx Guru


Joined: 02 Feb 2003 Posts: 420 Location: Planet Houston
|
Posted: Tue Sep 26, 2006 12:03 am Post subject: Drive corruption interfering with "emerge world" [ |
|
|
Hello all.
One of my machines has an 80GB hard drive that I believe is slowly on its way out. Earlier today the drive red-lined with 100% capacity, and at the same time the root partition switched into read-only mode. One massive fsck later and a few file deletions later, the system is mostly working again, but now emerge world won't, failing with an input/output error.
I suspect something in the data portage uses to keep track of installed packages was corrupted. I'm hoping that this is something recoverable, but so far it has eluded my troubleshooting attempts. emerge works on single packages; I successfully re-installed python and portage, and even managed to add new packages to the system (I tested this with fortune-mod, which also brought in recode), but still emerge world causes the system to trip over the drive.
In case it helps, here is emerge's output, including the resulting traceback:
Code: | Calculating world dependencies \Traceback (most recent call last):
File "/usr/bin/emerge", line 4049, in ?
emerge_main()
File "/usr/bin/emerge", line 4044, in emerge_main
myopts, myaction, myfiles, spinner)
File "/usr/bin/emerge", line 3457, in action_build
if not mydepgraph.xcreate(myaction):
File "/usr/bin/emerge", line 1260, in xcreate
if not self.select_dep(
File "/usr/bin/emerge", line 1081, in select_dep
myeb_matches = portdb.xmatch("match-visible", x)
File "/usr/lib/portage/pym/portage.py", line 5093, in xmatch
myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep=mydep,mykey=mykey))
File "/usr/lib/portage/pym/portage.py", line 5079, in xmatch
myval=self.gvisible(self.visible(self.cp_list(mykey)))
File "/usr/lib/portage/pym/portage.py", line 5178, in gvisible
keys, eapi = self.aux_get(mycpv, ["KEYWORDS", "EAPI"])
File "/usr/lib/portage/pym/portage.py", line 4796, in aux_get
elif len(mydata.get("_eclasses_", [])) > 0:
File "/usr/lib/python2.4/UserDict.py", line 158, in get
return self[key]
File "/usr/lib/portage/pym/cache/mappings.py", line 32, in __getitem__
return self.orig[key]
File "/usr/lib/portage/pym/cache/mappings.py", line 77, in __getitem__
self.d.update(self.pull())
File "/usr/lib/portage/pym/cache/flat_hash.py", line 29, in callit
return args[0](*args[1:]+args2)
File "/usr/lib/portage/pym/cache/flat_hash.py", line 44, in _pull
d = self._parse_data(myf, cpv)
File "/usr/lib/portage/pym/cache/flat_hash.py", line 53, in _parse_data
d = dict(map(lambda x:x.rstrip().split("=", 1), data))
IOError: [Errno 5] Input/output error |
Here are the entries that appear in the system log:
Code: | Sep 25 17:53:46 [kernel] hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Sep 25 17:53:46 [kernel] hda: task_in_intr: error=0x40 { UncorrectableError }, LBAsect=91917670, sector=91917670
Sep 25 17:53:46 [kernel] ide: failed opcode was: unknown
Sep 25 17:53:46 [kernel] end_request: I/O error, dev hda, sector 91917670 |
Assuming the drive doesn't further degrade over the next few days, can anybody offer sugestions on how to fix or workaround this, so I can get emerge fully working again?
Thanks! _________________ Proud to be a... eh, forget it.
"Everyday is just one day." -- not the Traveling Wilburys
Last edited by skunkworx on Fri Sep 29, 2006 9:42 pm; edited 1 time in total |
|
Back to top |
|
 |
lagalopex Guru


Joined: 16 Oct 2004 Posts: 566
|
Posted: Tue Sep 26, 2006 12:11 am Post subject: |
|
|
Ever tried badblocks?
Expecting you have ext3 on /dev/hda1:
Code: | fsck.ext3 -c -f -k -v /dev/hda1 |
Better done from a livecd
I got a hdd working again... had worked 5 years... after this I used it for two more years... |
|
Back to top |
|
 |
skunkworx Guru


Joined: 02 Feb 2003 Posts: 420 Location: Planet Houston
|
Posted: Fri Sep 29, 2006 9:45 pm Post subject: |
|
|
I appreciate the tip, lagalopex.
The first run of fsck didn't fix everything, but then I dug a little deeper and learned how badblocks can do a read/write test instead of just a read test (fsck.ext3 -c -c). That found a lot more bad blocks, and when the fsck was finished, emerge world didn't even flinch. It looks like this drive is still usable after all, at least for a little while longer.
Thanks! _________________ Proud to be a... eh, forget it.
"Everyday is just one day." -- not the Traveling Wilburys |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|