Re: The crippled resurrection of said etch.
- From: Andrew Sackville-West <andrew@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 25 Oct 2006 17:31:07 -0700
hendrik@xxxxxxxxxxxxxx wrote:
On Wed, Oct 25, 2006 at 12:34:02PM -0700, Andrew Sackville-West wrote:
hendrik@xxxxxxxxxxxxxx wrote:
Four more reboots, one successful.it could be an X problem or a gdm problem, but probably I'd guess X.
It seems to ba a problem starting gdm.
It tell sme it's starting gdm,thats normal. X does sanity checks to make sure you're not starting more
then that it'snot starting kdm because it's not the default,
then that it's not starting (presumably another *dm) because it's
not the default
than one session manager or whatever.
I know that. I just thought that the last message before the crash
might be a clue to what went wrong -- such as an unfortunate race
condition between gdm and whatever thing decides not to start the other.
But I admit this is unlikely.
then the black screen of death, preventing me from reading which otherare you locked up hard at that point or can you switch to a vt? ctrl-alt-fx?
*dm it was considering.
Locked up hard. THough I suppose I should try ssh-ing in.
Could it be that the *dm is interfering with gdm starting up?as Andre said, /etc/init.d/gdm stop.
Maybe it's whatever it does *after* trying its hand with the *dm'a
that is the culprit? Anyone know what that is?
Should I try making another *dm the default?
Should I try purging the other *dm's?
Should I try purging gdm?
Should I try running a general update of everything just in case?
then I'd get rid of the links for the moment so you can actually work on
the thing: update-rc.d gdm -f remove && update-rc.d kdm -f remove and so
forth. Then you can use startx as a user and see what happens.
Might be easier just to do this in maintenance mode, which doesn't start
the things in the first place.
There's a point -- in the two-Debian philosophy of system maintanance,
use there any way of using, say, aptitude running on one system to
install, uninstall, configure and so forth the other?
It suddenly struck me as potentially useful. Doesn't the installer do
something like this, starting from a RAMdisk?
-- hendrik
you can chroot into your etch install from sarge. you have to do some
stuff with /proc I think first such as
sarge# mount proc /etchroot/proc -t proc
and then you can
sarge# chroot /etchroot
and from there you can do stuff within the etch install, including
installing stuff. Check out the debian installer docs for using
debootstrap. its exactly the method they use to get the kernel set up.
pretty cool really.
A
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- References:
- Re: The sad demise of an etch.
- From: Andrew Sackville-West
- Re: The sad demise of an etch.
- From: hendrik
- Re: The sad demise of an etch.
- From: Paul E Condon
- Re: The sad demise of an etch.
- From: hendrik
- Re: The sad demise of an etch.
- From: Andrew Sackville-West
- Re: The sad demise of an etch.
- From: hendrik
- Re: The sad demise of an etch.
- From: Andrew Sackville-West
- Re: The sad demise of an etch.
- From: hendrik
- Re: The crippled resurrection of said etch.
- From: hendrik
- Re: The crippled resurrection of said etch.
- From: hendrik
- Re: The sad demise of an etch.
- Prev by Date: Re: The crippled resurrection of said etch.
- Next by Date: Re: The crippled resurrection of said etch.
- Previous by thread: Re: The crippled resurrection of said etch.
- Next by thread: Re: The crippled resurrection of said etch.
- Index(es):
Relevant Pages
|