[gentoo-user] How Bad Is This...?
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:
[ 06:41:58 ] Wed Apr 16 /home/Cyor $ emerge --sync
emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
Permission denied: '/usr/portage/metadata/timestamp.chk'
emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
"Permission denied," " Read-only file system" ... WTF..!?!
[ 06:42:52 ] Wed Apr 16 /home/Cyor $ df
bash: /bin/df: Input/output error
"I/O error" okay enough of this, time to reboot.
[ 06:43:22 ] Wed Apr 16 /home/Cyor $ shutdown -h now
bash: /sbin/shutdown: Input/output error
Uh-oh, this is starting to look bad.
[ 06:44:48 ] Wed Apr 16 /home/Cyor $ man emerge
bash: man: command not found
[ 06:45:05 ] Wed Apr 16 /home/Cyor $ cd /
[ 06:45:13 ] Wed Apr 16 / $ ls
ls: cannot access stage3-i686-2007.0.tar.bz2.DIGESTS: Permission denied
ls: cannot access portage-20080407.tar.bz2: Permission denied
total 105521
1 drwxr-xr-x 21 NormalUser Domain Admins 736 Apr 12 12:02 .
1 drwxr-xr-x 21 NormalUser Domain Admins 736 Apr 12 12:02 ..
4 drwxr-xr-x 2 NormalUser Domain Admins 3888 Apr 13 09:41 bin
0 drwxr-xr-x 2 NormalUser Domain Admins48 Apr 7 17:23 boot
0 drwxr-xr-x 15 NormalUser Domain Admins 3120 Apr 15 21:23 dev
3 drwxr-xr-x 40 NormalUser Domain Admins 3144 Apr 16 00:32 etc
0 drwxr-xr-x 5 NormalUser Domain Admins 144 Apr 12 11:21 home
4 drwxr-xr-x 8 NormalUser Domain Admins 4048 Apr 12 14:31 lib
0 drwxr-xr-x 4 NormalUser Domain Admins80 Apr 12 05:19 log
0 drwxr-xr-x 6 NormalUser Domain Admins 168 Apr 11 21:44 mnt
0 drwxr-xr-x 2 Nor
RE: [gentoo-user] How Bad Is This...?
Have you tried the keys Ctrl+Alt+Suppr in tty1 for example?
> From: [EMAIL PROTECTED]
> To: gentoo-user@lists.gentoo.org
> Subject: [gentoo-user] How Bad Is This...?
> Date: Wed, 16 Apr 2008 07:43:21 -0700
>
>
> 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:
>
>
> [ 06:41:58 ] Wed Apr 16 /home/Cyor $ emerge --sync
> emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
> emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
> emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
> Permission denied: '/usr/portage/metadata/timestamp.chk'
> emergelog(): [Errno 30] Read-only file system: '/var/log/emerge.log'
>
> "Permission denied," " Read-only file system" ... WTF..!?!
>
> [ 06:42:52 ] Wed Apr 16 /home/Cyor $ df
> bash: /bin/df: Input/output error
>
> "I/O error" okay enough of this, time to reboot.
>
>
> [ 06:43:22 ] Wed Apr 16 /home/Cyor $ shutdown -h now
> bash: /sbin/shutdown: Input/output error
>
> Uh-oh, this is starting to lo
Re: [gentoo-user] How Bad Is This...?
On Wednesday 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: > 36 -rwxr-xr-x 1 NormalUser Domain Admins 36364 Apr 19 2007 > Okay, so my question is how bad is it? It's very bad. It indicates file system corruption on the ReiserFS. In my experience, I have never seen this to be followed by a clean recovery. You can try reiser.fsck with --rebuild-tree (after suitably enough research and googling) and see what gives. Sorry for the bad news. > Is there anyway to shutdown cleanly? 'shutdown -h now' ? -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] How Bad Is This...?
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 def
Re: [gentoo-user] How Bad Is This...?
On Mittwoch, 16. April 2008, Alan McKinnon wrote: > > It's very bad. It indicates file system corruption on the ReiserFS. In > my experience, I have never seen this to be followed by a clean > recovery. > > You can try reiser.fsck with --rebuild-tree (after suitably enough > research and googling) and see what gives. only after checking the harddisk. Because if --rebuild-tree runs into bad blocks or other hardware damage, he is really screwed. > > Sorry for the bad news. > > > Is there anyway to shutdown cleanly? > > 'shutdown -h now' ? that won't work in his case. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] How Bad Is This...?
On Wed, 2008-04-16 at 07:43 -0700, Bob Young wrote: > > 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? > > Thanks for listening > Bob Young > San Jose, CA. > I suspect the cables. You could also blame the controller but bad cables are easier to test and easier to replace. signature.asc Description: This is a digitally signed message part
RE: [gentoo-user] How Bad Is This...?
-Original Message- From: Volker Armin Hemmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 16, 2008 8:22 AM To: gentoo-user@lists.gentoo.org Cc: Bob Young Subject: Re: [gentoo-user] How Bad Is This...? >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: >> [snip] >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. Just wanted to let you know, it appears you were right, it was the HD itself that was bad. I substituted in the other brand new Seagate, and reinstalled. Luckily I was able to read all config files from the semi-bad drive. At this point I'm finished installing xorg-server, and have begun installing KDE. P.S. Next time I'll post the output of dmesg... Thanks for responding Bob Young San Jose, CA. -- gentoo-user@lists.gentoo.org mailing list
