1 |
On Mittwoch, 16. April 2008, Bob Young wrote: |
2 |
> I'm in the process of installing a new box, last night before going to bed |
3 |
> I started installing xorg server. This morning, I found the 82nd build (out |
4 |
> of 162) had failed with the following error: |
5 |
> |
6 |
> |
7 |
> 1450K .......... .......... .......... .......... .......... 89% 44.2K |
8 |
> 0:04 |
9 |
> 1500K .......... .......... .......... .......... .......... 92% 51.2K |
10 |
> 0:02 |
11 |
> 1550K .......... .......... .......... .......... .......... 95% 20.0K |
12 |
> 0:04 |
13 |
> 1600K .......... .......... .......... .......... .......... 98% 61.9K |
14 |
> |
15 |
> 1650K .......... .......... .......... . 100% 46.4K |
16 |
> |
17 |
> |
18 |
> 00:33:24 (29.93 KB/s) - `/usr/portage/distfiles/curl-7.17.1.tar.bz2' saved |
19 |
> [1721551/1721551] |
20 |
> |
21 |
> >>> Unpacking curl-7.17.1.tar.bz2 to |
22 |
> |
23 |
> /var/tmp/portage/net-misc/curl-7.17.1/work |
24 |
> * Applying curl-7.16.2-strip-ldflags.patch ... |
25 |
> [ ok ] |
26 |
> * Applying curl-7.17.1-null-handler-segfault.patch ... |
27 |
> [ ok ] |
28 |
> * Running elibtoolize in: curl-7.17.1 |
29 |
> * Applying install-sh-1.5.patch ... |
30 |
> * Applying portage-1.5.10.patch ... |
31 |
> * Applying sed-1.5.6.patch ... |
32 |
> |
33 |
> >>> Source unpacked. |
34 |
> >>> Compiling source in |
35 |
> |
36 |
> /var/tmp/portage/net-misc/curl-7.17.1/work/curl-7.17.1 ... |
37 |
> * |
38 |
> * ERROR: net-misc/curl-7.17.1 failed. |
39 |
> * Call stack: |
40 |
> * ebuild.sh, line 49: Called src_compile |
41 |
> * environment, line 2344: Called die |
42 |
> * The specific snippet of code: |
43 |
> * die 'ldap and kerberos (gssapi) not playing nicely try version |
44 |
> |
45 |
> >=7.18.1'; |
46 |
> |
47 |
> * The die message: |
48 |
> * ldap and kerberos (gssapi) not playing nicely try version >=7.18.1 |
49 |
> * |
50 |
> * If you need support, post the topmost build error, and the call stack if |
51 |
> relevant. |
52 |
> * A complete build log is located at |
53 |
> '/var/tmp/portage/net-misc/curl-7.17.1/temp/build.log'. |
54 |
> * The ebuild environment file is located at |
55 |
> '/var/tmp/portage/net-misc/curl-7.17.1/temp/environment'. |
56 |
> * |
57 |
> * Regenerating GNU info directory index... |
58 |
> * Processed 133 info files. |
59 |
> |
60 |
> Okay, looks like there's something wrong with curl, let's see what the |
61 |
> current and latest version I can unmask is: |
62 |
> |
63 |
> |
64 |
> [ 00:33:41 ] Wed Apr 16 /home/Cyor $ emerge -s curl |
65 |
> Searching... -Traceback (most recent call last): |
66 |
> File "/usr/bin/emerge", line 6971, in ? |
67 |
> retval = emerge_main() |
68 |
> File "/usr/bin/emerge", line 6945, in emerge_main |
69 |
> myopts, myfiles, spinner) |
70 |
> File "/usr/bin/emerge", line 5811, in action_search |
71 |
> searchinstance.execute(mysearch) |
72 |
> File "/usr/bin/emerge", line 566, in execute |
73 |
> if not self.portdb.xmatch("match-visible", package): |
74 |
> File "/usr/bin/emerge", line 494, in _xmatch |
75 |
> matches.update(db.xmatch(level, atom)) |
76 |
> File "/usr/lib/portage/pym/portage.py", line 7438, in xmatch |
77 |
> |
78 |
> File "/usr/lib/portage/pym/portage.py", line 7372, in xmatch |
79 |
> |
80 |
> File "/usr/lib/portage/pym/portage.py", line 7481, in visible |
81 |
> |
82 |
> File "/usr/lib/portage/pym/portage.py", line 7085, in aux_get |
83 |
> |
84 |
> File "/usr/lib/portage/pym/cache/template.py", line 82, in __delitem__ |
85 |
> |
86 |
> File "/usr/lib/portage/pym/cache/flat_hash.py", line 98, in _delitem |
87 |
> raise cache_errors.CacheCorruption(cpv, e) |
88 |
> cache.cache_errors.CacheCorruption: dev-lisp/cl-curl-20050609 is corrupt: |
89 |
> [Errno 13] Permission denied: |
90 |
> '/var/cache/edb/dep/usr/portage/dev-lisp/cl-curl-20050609' |
91 |
> |
92 |
> |
93 |
> What...! the file is corrupt..? okay, maybe a --sync will fix it: |
94 |
|
95 |
no. |
96 |
|
97 |
> |
98 |
> |
99 |
> "I/O error" okay enough of this, time to reboot. |
100 |
|
101 |
no, time for dmesg. |
102 |
|
103 |
> |
104 |
> |
105 |
> [ 06:43:22 ] Wed Apr 16 /home/Cyor $ shutdown -h now |
106 |
> bash: /sbin/shutdown: Input/output error |
107 |
|
108 |
yep, dmesg. |
109 |
|
110 |
> |
111 |
> Uh-oh, this is starting to look bad. |
112 |
|
113 |
it is. |
114 |
|
115 |
> Also worthy of note is the reason for installing this new box, the previous |
116 |
> install developed severe hard disk corruption. Because of that, this |
117 |
> install is located on a brand new 250G Seagate with a five year warranty, |
118 |
> so while not impossible, I tend to doubt that the hard disk it self is the |
119 |
> true root cause. |
120 |
|
121 |
it is a seagate. Harddisk problem is VERY probable. You posted a lot of |
122 |
(useless) information, but not the important one: |
123 |
dmesg |
124 |
|
125 |
> |
126 |
> Okay, so my question is how bad is it? |
127 |
|
128 |
your filesystem got damaged. Your kernel might be in Lalaland dancing with the |
129 |
fairies. Maybe it was just a glitch, but probably your harddisk, cables, PSU |
130 |
or cooling is f* up. |
131 |
|
132 |
> |
133 |
> Is there anyway to shutdown cleanly? |
134 |
|
135 |
not really. Since the system is hosed anyway, dmesg first (maybe save the |
136 |
output on a different device). Then try sysrq-keys (alt+printscreen+e,i,u,b). |
137 |
Boot from cd, check fs. Check harddisk with smart. |
138 |
|
139 |
> |
140 |
> I do have a second brand new 250G Seagate, is another clean install, with a |
141 |
> *second* brand new drive the best alternative, or is some even lower level |
142 |
> hardware (i.e. disk controller) the more likely culprit at this point? |
143 |
|
144 |
the best alternative is to check what went wrong, but since Seagates are known |
145 |
to die in the first couple of days - or almost never, this gentleman here |
146 |
would bet on a defective harddisk. |
147 |
|
148 |
Btw, you might want to read up on 'bathtub curve'. Stuff breaks early, or |
149 |
late. |
150 |
-- |
151 |
gentoo-user@l.g.o mailing list |