[26760] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: sunblade 150s crash with corrupt gconf

daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Mar 6 17:34:19 2006

Date: Mon, 6 Mar 2006 17:32:44 -0500
From: John Hawkinson <jhawk@mit.edu>
To: Robert Basch <rbasch@mit.edu>
Message-ID: <20060306223244.GY26428@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C2D00CC-C2EE-4583-8714-718C269C55C4@MIT.EDU>
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu

Robert Basch <rbasch@MIT.EDU> wrote on Mon,  6 Mar 2006
at 17:28:40 -0500 in <3C2D00CC-C2EE-4583-8714-718C269C55C4@MIT.EDU>:


> I visited m56-129-8 and m26-100-1.

Thanks.

> Only the former had a /etc/gconf.broken directory, which looked
> fine.  I moved it back into place, and tried rebooting a couple of
> times; the only problem I noticed is that the boot sequence takes a
> long time (several minutes, most of which is after the afs cache
> scan message is displayed), but eventually the login screen does
> appear.  I also successfully rebooted m26-100-1.

Curious.

> Is it possible that the problem in both cases was just a
> painfully slow boot sequence, with no evidence of
> progress getting displayed on the console?

Hmm. I guess it is possible, but I am rather skeptical.
In the case of m56-129-8, I found it with a sign labeled
"broken" on it, and it looked like it had been that way for
several hours. In the case of m26-100-1, I certainly let it run
for 10 minutes before booting the kernel debugger, etc.

Do we know why it was painfully slow? I assume it was related to
the presence of /etc/gconf.

--jhawk

home help back first fref pref prev next nref lref last post