On Mon, Oct 30, 2006 at 01:29:56PM -0500, Matthew Krauss wrote: > [EMAIL PROTECTED] 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?
That did happen a day or so ago. But it happened once, and the restrictive shell has happened several times. At that time fsck put #501066 into lost+found. -rw-r--r-- 1 root root 105299 2006-10-27 14:21 #501066 Its contents may be important. Here are its first few lines: Name: abiword-common/add-type1-module Template: abiword-common/add-type1-module Owners: abiword-common Name: adduser/homedir-permission Template: adduser/homedir-permission Value: true Owners: adduser Flags: seen Name: aolserver/admin_name Template: aolserver/admin_name Value: www-data Owners: aolserver Flags: seen Name: aolserver/doc_root Template: aolserver/doc_root Value: /var/www Owners: aolserver Flags: seen Is this something that is very important to put back? If so, where? Or is it some kind of temporary file that gets regenerated on demand anyway? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
