hi

I may have misunderstood the first post but

when I use smxi to install a new kernel I always reboot into it before continuing to graphics....yes I know thats not the issue

but I use autologin, so if forget to do graphics....debian sid kicks me back to console login and I can just use CLI to login to root and re-run smxi or its equalivent depending on whether you use nvidia or ati.

So miks are you saying you do not end up at a command line prompt if you forget to do your graphics?

FYI

inittab shows for me
id:5:initdefault:
z6:6:respawn:/sbin/sulogin

autologin using gdm
Back to top

Hi aus9, yes, for some reason, if I fail to reinstall fglrx after an xorg update or I reboot after installing a new kernel, I no longer get the console login I used to get. I have been running squeeze on this lappy since I bought it new about august 2009, and everything worked as expected until an upgrade I did in august 2010. In fact I posted on the debian forum about the problem here forums.debian.net/viewtopic.php?f=10&t=54425&start=0

I had to restore from my backup to get a working system again and stopped upgrading for the time being. I eventually decided to revert back to 32 bit (mainly to save on hassle with flash) so re-installed a week or two ago to see if a fresh install was any different, but it isn't. Don't know if it is related, but I can't use the radeon driver as I get lines streaking across the screen. Same interference happened when I tested out crunchbang Statler and Mint lmde, irc, both based on squeeze.
Back to top

hi

well I spotted craigevil and he is one of us...AFAIK and his request for booting live cd and looking at how far your boot got is also wise.

why not post it to
pastebin.com/

it can handel 1 Meg sizes ?

if he is right you have a breakdown in the init scripts possible udev but
you also mention you did a lot of updating so not sure if your system is actually up-to-date either.

why not post the logs first?

good luck
Back to top

Thanks aus9.

I decided to install damentz latest kernel and see what happens.

This time instead of a black screen on reboot, I got a pretty screen full of interference. Had to use rseiub to reboot. As I also have Mint 9 installed as a backup system, I can retrieve the logs withour resorting to a live cd and still have a usable system for work etc.

I have started with xorg pastebin.com/w52Ut7Hq

and here is dmesg pastebin.com/Q2CtjcMU

If you need any other logs posting, let me know.
Back to top

make sure fglrx is running on the right pcibusid

check: lspci -v | grep VGA
for the busid, then check your /etc/X11/xorg.conf and make sure it's explicitly listed, that's the main error I saw on a quick scan.
Back to top

hi

I defer to H2 and I have a nvidia card as well but it also suggests you might try a bootcode=cheatcode=boot parameter of

pci=nomsi

Message Signaled Interrupts

good luck

EDIT

alternatively boot up the other distro and chroot into your target and run smxi?
Back to top

Thanks for the suggestions, but it appears to be a case of runlevels as suspected. I decided to have a go at sysv-rc-conf and as I don't really know what I am doing, I changed kdm, gdm and x11-common, just leaving them with a check on runlevel 5. I can now boot to a prompt by adding 2 to the kernel line and ran smxi to reinstall fglrx.

fglrx 10.10 is working with the 2.6.36-0.dmz.5 liquorix kernel, so I guess the patch from arch works ok.

Suspend is playing up though and reboots rather than resumes.

If anyone has any comments on what I did with sysv-rc-conf, I would be pleased to hear them.
Back to top

x 11 shouldn't have been necessary, but what you did with gdm/kdm is correct, it looks like sysv-rc-conf may be the only way to work with runlevels safely now with insserv init level system, I'll have to update smxi to either not offer that if insserv is used or to offer sysv-rc-conf, or even better, if sysv-rc-conf has some hooks I can use it would be great to use it to alter the runlevels, or something..
Back to top

great news, sysv-rc-conf supports command line triggering of runlevels/services, so I'm going to just dump the old method and replace it with a command line triggered sysv-rc-conf update.

I'm happier integrating my work with other people's fine work, and I have always felt that sysv-rc-conf, except for being very non intuitive and not very user friendly, was a fine program, but if I can call it via smxi and have it do what is needed without user interactions that might confuse or lead to error, that is the best of both worlds, so that's what I will do.

smxi will test for and install if missing sysv-rc-conf then update the runlevels, to make this process easier and more intuitive, and, now, so that it actually works again.
Back to top

Thanks techAdmin, I will look forward to trying it out.
Back to top