On Mittwoch, 16. April 2008, Bob Young wrote:
> I'm in the process of installing a new box, last night before going to bed
> I started installing xorg server. This morning, I found the 82nd build (out
> of 162) had failed with the following error:
>
>
> 1450K .......... .......... .......... .......... .......... 89% 44.2K
> 0:04
> 1500K .......... .......... .......... .......... .......... 92% 51.2K
> 0:02
> 1550K .......... .......... .......... .......... .......... 95% 20.0K
> 0:04
> 1600K .......... .......... .......... .......... .......... 98% 61.9K
>
> 1650K .......... .......... .......... . 100% 46.4K
>
>
> 00:33:24 (29.93 KB/s) - `/usr/portage/distfiles/curl-7.17.1.tar.bz2' saved
> [1721551/1721551]
>
> >>> Unpacking curl-7.17.1.tar.bz2 to
>
> /var/tmp/portage/net-misc/curl-7.17.1/work
> * Applying curl-7.16.2-strip-ldflags.patch ...
> [ ok ]
> * Applying curl-7.17.1-null-handler-segfault.patch ...
> [ ok ]
> * Running elibtoolize in: curl-7.17.1
> * Applying install-sh-1.5.patch ...
> * Applying portage-1.5.10.patch ...
> * Applying sed-1.5.6.patch ...
>
> >>> Source unpacked.
> >>> Compiling source in
>
> /var/tmp/portage/net-misc/curl-7.17.1/work/curl-7.17.1 ...
> *
> * ERROR: net-misc/curl-7.17.1 failed.
> * Call stack:
> * ebuild.sh, line 49: Called src_compile
> * environment, line 2344: Called die
> * The specific snippet of code:
> * die 'ldap and kerberos (gssapi) not playing nicely try version
>
> >=7.18.1';
>
> * The die message:
> * ldap and kerberos (gssapi) not playing nicely try version >=7.18.1
> *
> * If you need support, post the topmost build error, and the call stack if
> relevant.
> * A complete build log is located at
> '/var/tmp/portage/net-misc/curl-7.17.1/temp/build.log'.
> * The ebuild environment file is located at
> '/var/tmp/portage/net-misc/curl-7.17.1/temp/environment'.
> *
> * Regenerating GNU info directory index...
> * Processed 133 info files.
>
> Okay, looks like there's something wrong with curl, let's see what the
> current and latest version I can unmask is:
>
>
> [ 00:33:41 ] Wed Apr 16 /home/Cyor $ emerge -s curl
> Searching... -Traceback (most recent call last):
> File "/usr/bin/emerge", line 6971, in ?
> retval = emerge_main()
> File "/usr/bin/emerge", line 6945, in emerge_main
> myopts, myfiles, spinner)
> File "/usr/bin/emerge", line 5811, in action_search
> searchinstance.execute(mysearch)
> File "/usr/bin/emerge", line 566, in execute
> if not self.portdb.xmatch("match-visible", package):
> File "/usr/bin/emerge", line 494, in _xmatch
> matches.update(db.xmatch(level, atom))
> File "/usr/lib/portage/pym/portage.py", line 7438, in xmatch
>
> File "/usr/lib/portage/pym/portage.py", line 7372, in xmatch
>
> File "/usr/lib/portage/pym/portage.py", line 7481, in visible
>
> File "/usr/lib/portage/pym/portage.py", line 7085, in aux_get
>
> File "/usr/lib/portage/pym/cache/template.py", line 82, in __delitem__
>
> File "/usr/lib/portage/pym/cache/flat_hash.py", line 98, in _delitem
> raise cache_errors.CacheCorruption(cpv, e)
> cache.cache_errors.CacheCorruption: dev-lisp/cl-curl-20050609 is corrupt:
> [Errno 13] Permission denied:
> '/var/cache/edb/dep/usr/portage/dev-lisp/cl-curl-20050609'
>
>
> What...! the file is corrupt..? okay, maybe a --sync will fix it:
no.
>
>
> "I/O error" okay enough of this, time to reboot.
no, time for dmesg.
>
>
> [ 06:43:22 ] Wed Apr 16 /home/Cyor $ shutdown -h now
> bash: /sbin/shutdown: Input/output error
yep, dmesg.
>
> Uh-oh, this is starting to look bad.
it is.
> Also worthy of note is the reason for installing this new box, the previous
> install developed severe hard disk corruption. Because of that, this
> install is located on a brand new 250G Seagate with a five year warranty,
> so while not impossible, I tend to doubt that the hard disk it self is the
> true root cause.
it is a seagate. Harddisk problem is VERY probable. You posted a lot of
(useless) information, but not the important one:
dmesg
>
> Okay, so my question is how bad is it?
your filesystem got damaged. Your kernel might be in Lalaland dancing with the
fairies. Maybe it was just a glitch, but probably your harddisk, cables, PSU
or cooling is f* up.
>
> Is there anyway to shutdown cleanly?
not really. Since the system is hosed anyway, dmesg first (maybe save the
output on a different device). Then try sysrq-keys (alt+printscreen+e,i,u,b).
Boot from cd, check fs. Check harddisk with smart.
>
> I do have a second brand new 250G Seagate, is another clean install, with a
> *second* brand new drive the best alternative, or is some even lower level
> hardware (i.e. disk controller) the more likely culprit at this point?
the best alternative is to check what went wrong, but since Seagates are known
to die in the first couple of days - or almost never, this gentleman here
would bet on a defective harddisk.
Btw, you might want to read up on 'bathtub curve'. Stuff breaks early, or
late.
--
gentoo-user@lists.gentoo.org mailing list
