Re: The crippled resurrection of said etch.
On Mon, Oct 30, 2006 at 01:29:56PM -0500, Matthew Krauss wrote:
> 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?
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
Reply to: