Re: The crippled resurrection of said etch.

[Matthew Krauss <Matthew@Greenberg-Group.com>]

hendrik@topoi.pooq.com wrote:
> On Thu, Oct 26, 2006 at 10:25:37AM -0400, Matthew Krauss wrote:
>   
[snip]
> > What I would try to isolate the problem is:
> >
> > 1. Reboot in to single user mode.
> > 2. Log in as root.
> > 3. Try starting X alone:
> >    $ X 2>&1 | less
> >    3a. If X starts, you may kill it with ctrl-alt-backspace;
> >     
>
> X starts.
> Killed it with ctrl-alt-backspace
>
>   
> >    3b. If X does not start, you have the output to debug;
> >    3c. If you get a kernel panic, you know you have serious X problems.
> > 4. Next try starting gdm directly:
> >    $ /etc/init.d/gdm start
> >    4a. If gdm starts, there is probably a problem in your startup scripts;
> >    4b. If gdm does not start, you can check the logs under /var/log/gdm/
> >    4c. If you get a kernel panic, you know you have serious gdm problems.
> >     
>
> gdm starts.  A cursor blinks in the upper left of a black screen, then 
> the cursor disappears, leaving the black screen of death.
> Did a hard reset to reboot.  No trace of a log file.
>
> try /etc/init.d/kdm start
>
> it refuses; kdm is not default.
>
> dpkg-reconfigure kdm
> and make kdm the default.
>
> repreat
>
> /etc/init.d/kdm start
>
> acts just like /etc/init.d/gdm did before -- black screen of death
>   
This was good thinking, here -- it's very surprising, but you seem to 
have shown that both gdm and kdm have a problem where X alone does 
not??  I'm not sure how to explain that off hand, but will think about 
it...  At any rate, you've also ruled out interference from more than 
one *dm running at a time.
> reset to reboot.
>
> This time, after the usual environment checking, it starts a maintanance 
> shell with a shorter path:
>
> /lib/init:/sbin:/bin
>
> As a result, lots of commands don't work.  Suppliying the path 
> explicitly,
>
> /usr/bin/dpkg-reconfigure  
>
> fails.  Its first error message reports that it cannot execute the 
> 'locale' command.  True enough. 'locale' is not on the path.
> This looks like a but in dpkg-reconfigure -- shouldn't scripts that are 
> executed as root specify their command names a little more explicitly?
>
> Something is wrong with the maintenance shell this time -- why has its 
> $PATH suddenly changed?
>   
Just a wild wild guess, but maybe you have developed problems on your 
file system from the hard boots -- if there is anything more serious 
then the automatic checks can handle, you will be dumped in to 
maintenance shell from where you are supposed to fix it, and I *think* 
that it is different from the regular single-user mode you were using 
before.  Did you see any messages to that effect? Something about 
running fsck?

Regards,
Matthew

[snip]