[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The crippled resurrection of said etch.

hendrik@topoi.pooq.com wrote:
> On Wed, Oct 25, 2006 at 12:34:02PM -0700, Andrew Sackville-West wrote:
>> hendrik@topoi.pooq.com wrote:
>>> Four more reboots, one successful.
>>> It seems to ba a problem starting gdm.
>> it could be an X problem or a gdm problem, but probably I'd guess X.
>>> It tell sme it's starting gdm,
>>> 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
>> thats normal. X does sanity checks to make sure you're not starting more
>> 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 other 
>>> *dm it was considering.
>> are you locked up hard at that point or can you switch to a vt? ctrl-alt-fx?
> Locked up hard.  THough I suppose I should try ssh-ing in.
>>> Could it be that the *dm is interfering with gdm starting up?
>>> 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?
>> as Andre said, /etc/init.d/gdm stop.
>> 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.


Reply to: