Page: 1, 2  Next

Ran Sgxfi on LMDE 64bit - no longer boots
xircon
Status: Interested
Joined: 08 Jan 2011
Posts: 10
Reply Quote
Log file - pastebin.com/qQgXrRFE

Mint forum - forums.linuxmint.com/viewtopic.php?f=141&t=62521&p=365950#p365950

Boots to a rapidly flashing cursor in the top left corner, the script moaned about fglrx but to fast for me to read it properly.

Any way to recover?

Cheers

Steve
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
your system is booting fine, but fglrx is crashing on start, or is starting on another, non-existent screen.

Make sure to distinguish those events.

In general I warn users against running fglrx 64 bit, it's the most unreliable driver in the world, and running the 64 bit stuff makes your odds even lower.

Ignoring that, I need to see the following:

/etc/Xorg/xorg.conf

/var/log/Xorg.0.log

I would say rerun sgfxi as well and post a new log, but since fglrx has hardlocked in a crash you can't really exit X, which is in fact running, but it's crashed or is running on the wrong screen, so it's hard to exit it.

You can always try, of course, by doing: ctrl+alt+F1
when you see the blinking cursor, or f2

if this gives you a login, login and run sgfxi again.

the latter item will show exactly why fglrx failed to start. Usually it's 'no screens found', which usually means an incorrectly created xorg.conf file, which is my current guess for why mint users are seeing some problems. That's just a guess of course.

The problem, as I noted on the mint forums, is that mint has decided to release with default desktop start runlevel of 2, this makes starting in console mode but as userlevel much harder than it should be for regular users.

In general this presents such a pain in terms of user support I really almost want to hand the support mess back to the distro that makes that poor decision.

However, there are a few things you can do, all a pain, since you have to go into single user mode and do things manually you should never need to do.

If you can do a console login, do this: smxi -kwid
then pick misc tweaks => advanced tweaks -> runlevel set
and adjust your runlevel to start in 3 as default, this will allow you to boot into console runlevel 2 without X starting, which makes debugging fglrx issues MUCH easier. Once fglrx has crashed you usually have to hard reset the system to reboot, which will just crash again on x start so it does you no good in general.

Your most emergency option is this:

boot to single user mode (aka safe mode), login, edit: nano /etc/Xorg/xorg.conf

use down arrow to get to Driver "fglrx"
change that to: Driver "vesa"
then hit: ctrl + o
to save the changed file, and
ctrl +x
to exit
then:
init 2
to start the desktop.

Once it starts, do: smxi -Gi
then do the tweak to runlevels so you can start in runlevel 2 without fgrlx / X starting.
Back to top
xircon
Status: Interested
Joined: 08 Jan 2011
Posts: 10
Reply Quote
Thanks for all the info, managed to get out of it another way:

Downloaded drivers from AMD and installed in the recovery console.

Rebooted.

Re-installed the original Mint drivers.

Edited xorg.conf to get compositing enabled, for some reason it was disabled.

Couldn't get out of it, everything was completely deadlocked, just a flashing cursor, ctrl-alt f1 etc did not work.

Everything back to normal.

Cheers

Steve
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
just so you know, you already had the driver downloaded, sgfxi doesn't repeatedly download that driver, it's in: /usr/src/sgfxi-downloads

however, sadly, your report does little to help any other user, and using sgfxi would have resulted in the same result.

composite is not generally enabled for fglrx due to historical failures, though I suppose it works now, that's not related at all however unless you were also running compiz, which is a highly critical piece of information since that's a 3d composite using desktop.

Actually, now that I think of it, I think I'll test for compiz if I can figure out what to look for in terms of it being actually the default desktop method.

I'll consider this yet another waste of my time re bug reports, since I am no closer to knowing why some Mint installs are failing to start X than I was when I started this sequence. I guess having added improved sgfxi error logging is worth something in general though, so I won't call today a total loss....

Maybe I'll just stop paying attention to Mint, I don't know, what do you think I should do? I'm really not interested in what goes wrong with derived distros to be honest, though I do like the lmde project.
Back to top
xircon
Status: Interested
Joined: 08 Jan 2011
Posts: 10
Reply Quote
Understand what you are saying, I really like LMDE64, it is polished and runs well. I have spent a couple of weeks distro hopping (I was a long term Mandriva user but Mandriva is dead and Mageia has not yet risen from the ashes). Think I will stick with LMDE, bit of a steep learning curve initially (RPM->Deb), but it runs really well and the forums are not full of spotty obnoxious kids!

I didn't mention the fact I was running Compiz because it didn't seem relevant, it wouldn't even get to the GDM login screen, so Compiz had not even loaded at that point. In my set-up metacity runs until the startup programs are run, then it runs compiz --replace.

I am quite willing to be a guinea pig if you would like me to carry out some tests under your instruction (especially now I have the information you supplied to quickly un-bork my machine :)) but unfortunately it is not in my nature to sit on hands, I just went ahead and tried to fix it myself.

I am in the UK (Sheffield) so if I can be of any assistance, feel free to give me a shout.

Cheers

Steve

:edit:
Forgot to mention, sgfxi will not run in recovery mode and I do not appear to have a network connection (wired or wireless) either.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
thanks for following up.

Good to know about when compiz starts, that helps figure it out, I never use that stuff so it's good to have the actual information. The fewer things to debug/insert to test the better.

There's some valuable things in your report, I can see some weaknesses, for example, sgfxi was never built to expect no network connection since unless the distro uses a gui wifi connection manager as its primary connection tool, and an incorrectly configured one at that, ie, one that does not grant all users rights the connection, the connection was always present.

The main reason I dropped the old connection test is that certain ISPs failed to deliver a proper response because of very hard to diagnose router/switch issues, so I just dropped it in favor of the current download file tests.

So clearly I should have sgfxi run the newly inserted connection test prior to any apt install and exit with a clear error if no connection, that's easy to do. That will take care of the first issue.

Second, if the runlevel is 1, single user mode, it should at least show a warning to user that certain things may be inactive.

I guess I should set the default for fglrx now to switch on composite, previously fglrx did not support that.

fglrx + default runlevel 2 is a real problem for any distro, and it's why that's a mistake to set it there. Debian does not care, in a sense rightfully, because Debian is about free and only free software, so they are rightfully annoyed if asked to fix something to make something work better because of a non free issue, but even with that in mind, I've always considered the start everything in runlevel 2 that debian uses a bad default simply because x should not start in the same runlevel as everything else, you should have an intermediate mode to work in if you so chose.

by the way, in my opinion, having worked a bit with rpm, apt/deb is significantly superior. sgfxi spupports basic rpm, but it was not fun to develop that, nor was I at all impressed by rpm in the process.

Once I have some more concrete tests I'll ask you to run them, and once I add in those extra error cases. While sgfxi doesn't have to solve all errors, it should deliver meaningful errors to the user so they can remedy the situation.
Back to top
xircon
Status: Interested
Joined: 08 Jan 2011
Posts: 10
Reply Quote
No problems, my email is xirconuk at gmail dot com.

Didn't realise Debian run levels where different, just looked them up on wikipedia:

Debian Linux runlevels
ID Description
0 Halt
1 Single-User mode
2-5 Full Multi-User with console logins and display manager if installed
6 Reboot

So not very helpful then!! My machine returns:

:: Code ::
who -r
run-level 2  2011-01-09 19:11                   last=S


I always thought that they were fixed because the SCO systems I used matched my Mandrake system - ho hum.

So again, a steep learning curve, but also must remember not to take anything for granted!

For reference, I am running a heavily modified Gnome/Compiz (because I like eye candy!), I abandoned KDE after 10 years because I just don't like KDE4, so Gnome is also new territory. I also have openbox and LXDE installed.

Just let me know when you need me.

Cheers

Steve
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
I've added two new things in sgfxi, one is to help test/debug: sgfxi -! 32
note that's an exclamation mark, and requires a space between it and the number.

This will remove all non free drivers, reset all the modeset to default values, re edit grub files, move xorg.conf to a backup location, and so on.

The end result is a fresh system with no video configurations that are not default, at least as far as I can tell.

This is a good first step to fixing borked installs, strip out everything.

then as the second step, I updated sgfxi's modesetting things to add in a second syntax which appears to be the cause of the failures in at least mint default kernels, this has been tested and seems to work now.

So this may help solve some of the issues we've found so far, I got another user today who gave some of his time for some tedious testing/retesting, which really helps, and with the new changes he reported things worked as expected.

The trick to test is: run: sgfxi -! 32
it will probably tell you to reboot, if it does, do so.

Then you will boot into the native xorg driver with no xorg.conf file, this should be the default for xorg in general.

It may not always start X, but it should not lock up X since all the non free drivers have been stripped out.

Which means if x doesn't start right, you can simply: ctrl alt f1
then login console and run: sgfxi
which should work for most users in most scenarios.

We'll see if more tweaks are required, I still haven't added in the runlevel 1 warning, that needs to also display.
Back to top
xircon
Status: Interested
Joined: 08 Jan 2011
Posts: 10
Reply Quote
Cheers, will have a go on Sunday, heading down south for a funeral :( and wont be back until late Saturday.
Back to top
xircon
Status: Interested
Joined: 08 Jan 2011
Posts: 10
Reply Quote
Apologies, never got chance to do anything on Sunday, will try this weekend hopefully.
Back to top
Display posts from previous:   
Page: 1, 2  Next
All times are GMT - 8 Hours