You are not logged in.
On my Intel vid laptop.. I had GDM last and it didn't help..
On this laptop. GDM is last.. but it is ati.. and i dont have the issue...
Hmm the reason the rc.local isnt helping is still cus it is a timing issue...
So your pc is just booting too fast..
here's my Daemon list:
DAEMONS=(syslog-ng network netfs crond hal alsa @gdm cups stbd @openntpd)
haven't had any trouble now in a few days. I think the upgrade solved the problem for me anyway.
Offline
Well since this wonderful bug and the fact that i dont want to screw stuff up even more by downgrading gdm when the rest of gnome is a different version, I have lost 3 hours of a esitmated 22 hour hard drive recovery, and i will be uninstalling arch linux. It used to be stable, but now its even more unstable then ubuntu (which had a crash bug which was the whole reason i switched). I'm sorry, but this stuff really has to be ..i don't know...tested before it gets sent out?
Offline
... I have lost 3 hours of a esitmated 22 hour hard drive recovery, and i will be uninstalling arch linux. It used to be stable, but now its even more unstable then ubuntu (which had a crash bug which was the whole reason i switched). I'm sorry, but this stuff really has to be ..i don't know...tested before it gets sent out?
That's one good reason to make a period backup of your system, even if it's running well... and especially before a very major upgrade just in case it's a bumpy ride and you want to roll back. That should probably go for any rolling released distro which doesn't put temporary barriers/brakes on upgrading software package versions.
Offline
well mine crashed this morning... so much for the upgrades!
Offline
Did you also try the other fixes like editing innitab. I used that method right at the begining of this thread and I have not experienced any random logout issues since.
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline
Did you also try the other fixes like editing innitab. I used that method right at the begining of this thread and I have not experienced any random logout issues since.
I just added the line to servers in the
# GDM configuration storage
[xdmcp]
[chooser]
[security]
[debug]
[servers]
0=Standard vt7
file.
right now I'm having trouble tranfering files to my external drive which always worked before. what's going on?
Offline
The problem persists even after the recent upgrade. Even with gdm in rc.local, I am occasionally stuck at the console with a message like this:
gdm-simple-slave[3859]: WARNING: Unable to open session: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
For some reason, the dbus stuff is not starting fast enough for gdm.
Offline
@vinoman2, [servers] is no longer a valid option in custom.conf. You need to try one of the other fixes (e.g edit inittab), just take a look at the first 2 pages. Certainly editing custom.conf has not affected your external drive.
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline
@vinoman2, [servers] is no longer a valid option in custom.conf. You need to try one of the other fixes (e.g edit inittab), just take a look at the first 2 pages. Certainly editing custom.conf has not affected your external drive.
I've already had two more crashes this morning. I may be the next person to bail on Arch. I see it's no better than other distros. I know nobody cares what I do but I'm not the only getting tired of little things going wrong
Offline
I have to agree, Arch linux really became nuts on my computer recently. Everytime i reset my computer when something hangs in my desktop (thats not hardware problem) and try to boot it again i get error that unable to mount root system, i restart computer and then arch starts to check my hdd, and it always finds errors after that. I thought that its ext4 foult, so i formated my hdd, reinstalled new arch 09.08 with ext3, but still, i see all these problems. Back in the 2008, arch was reliable, i could reset my computer many times but arch never gets errors, it was rock solid and stable. I really dont understand what has happened to arch since 2.6.30 kernel. I hope they will fix all these bugs, and if not, im going to switch to something else, maybe slackware or maybe gentoo, though i dont like that gentoo is source based. Anyway gl making arch better, because now im quite disappointed
Last edited by syms (2009-10-26 15:18:41)
Offline
@vinoman2 and syms - these problems might not be Arch's fault. They might be in the Gnome 2.28 upstream... Also, I don't understand why all the fuss. Just downgrade back to gdm-2.20 as described on the Gnome 2.28 Changes wiki article. Despite these little hiccups, Arch is still the one of the best distros out there.
Last edited by graysky (2009-10-26 19:51:01)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
@vinoman2 and syms - these problems might not be Arch's fault. They might be in the Gnome 2.28 upstream... Also, I don't understand why all the fuss. Just downgrade back to gdm-2.20 as described on the Gnome 2.28 Changes wiki article. Despite these little hiccups, Arch is still the one of the best distros out there.
thanks for the advice, but I have since cleared the cache so I can't go back. I just wish that whoever puts out the upgrades waits until everything works so I don't have to be asking all these questions in the first place.
I have remmed out a line that someone else mentioned and so far I haven't has any other crashes. Good. I would rather stay with Arch.
Offline
But how could be that gnome 2.28 makes errors on disk? I dont believe that its gnome 2.28 foult that i always get errors on hard drive.
@vinoman2, gdm 2.20 is available in aur, check it out
Offline
I've tried GDM 2.28 + Xfce4 = no crashes,
I've tried startx + exec xfce4-session at init 3 = no crashes,
I've tried startx + exec gnome-session at init 3 = X crashed down,
I've tried GDM 2.28 + gnome = X crashed down
Finally I've tried GDM 2.28 + gnome + newly created user = no crash - but haven't tested too long.
It seems to me, that this problem _is_not_gdm_related_...
(now I'm a happy Fluxbox user )
Last edited by jesusjimenez (2009-10-27 22:56:57)
Offline
insanemal wrote:On my Intel vid laptop.. I had GDM last and it didn't help..
On this laptop. GDM is last.. but it is ati.. and i dont have the issue...
Hmm the reason the rc.local isnt helping is still cus it is a timing issue...
So your pc is just booting too fast..here's my Daemon list:
DAEMONS=(syslog-ng network netfs crond hal alsa @gdm cups stbd @openntpd)
haven't had any trouble now in a few days. I think the upgrade solved the problem for me anyway.
I'd move gdm to the end of the list... but yeah.. and not backgrounded.. but thats me..
Offline
I've tried GDM 2.28 + Xfce4 = no crashes,
I've tried startx + exec xfce4-session at init 3 = no crashes,
I've tried startx + exec gnome-session at init 3 = X crashed down,
I've tried GDM 2.28 + gnome = X crashed downFinally I've tried GDM 2.28 + gnome + newly created user = no crash - but haven't tested too long.
It seems to me, that this problem _is_not_gdm_related_...(now I'm a happy Fluxbox user
)
Sorry man.. it is definitely a GDM issue..
The specifics of the issue are that GDM is starting on the same TTY as agetty.
This shouldn't happen as GDM is supposed to check that the TTY isn't in use and then bind to the first available one.
What appears to be happening is gdm is doing its test and finding that TTY2 is available. There are only two reasons for this,
1. TTY2 is available.. this means that GDM is firing up before the 6 agetty sessions start.
2. Its just going for TTY2 regardless.
You can be fairly sure its not number 2 because killing GDM and allowing it to restart it self causes it to start on TTY7.
Also there are commonly logs suggesting that agetty is having issues starting on TTY2.
This is not the first time this issue has happened.
It seems to cause the most issues for Arch users because most of us don't change our run levels to 5.
The reality is if we did.. the issue would not happen.
Even if we ran run level 3, and removed all agettys from TTY's 2-6 as chances are we don't need them.
I generally only use TTY1 if something goes horribly wrong.
Offline
Since remming out #c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
in inittab I haven't had a complete crash, but I have had a couple Firefox crashes, but its probably not related.
Offline
jesusjimenez wrote:I've tried GDM 2.28 + Xfce4 = no crashes,
I've tried startx + exec xfce4-session at init 3 = no crashes,
I've tried startx + exec gnome-session at init 3 = X crashed down,
I've tried GDM 2.28 + gnome = X crashed downFinally I've tried GDM 2.28 + gnome + newly created user = no crash - but haven't tested too long.
It seems to me, that this problem _is_not_gdm_related_...(now I'm a happy Fluxbox user
)
Sorry man.. it is definitely a GDM issue..
The specifics of the issue are that GDM is starting on the same TTY as agetty.
This shouldn't happen as GDM is supposed to check that the TTY isn't in use and then bind to the first available one.
What appears to be happening is gdm is doing its test and finding that TTY2 is available. There are only two reasons for this,
1. TTY2 is available.. this means that GDM is firing up before the 6 agetty sessions start.
2. Its just going for TTY2 regardless.You can be fairly sure its not number 2 because killing GDM and allowing it to restart it self causes it to start on TTY7.
Also there are commonly logs suggesting that agetty is having issues starting on TTY2.
This is not the first time this issue has happened.It seems to cause the most issues for Arch users because most of us don't change our run levels to 5.
The reality is if we did.. the issue would not happen.
Even if we ran run level 3, and removed all agettys from TTY's 2-6 as chances are we don't need them.I generally only use TTY1 if something goes horribly wrong.
Did you read my post well? I said there is a crash in gnome-session even with NO gdm running. But whatever... it made me switch to Fluxbox and the world is spinning faster since then.
Offline
I've tried GDM 2.28 + Xfce4 = no crashes,
I've tried startx + exec xfce4-session at init 3 = no crashes,
I've tried startx + exec gnome-session at init 3 = X crashed down,
I've tried GDM 2.28 + gnome = X crashed downFinally I've tried GDM 2.28 + gnome + newly created user = no crash - but haven't tested too long.
It seems to me, that this problem _is_not_gdm_related_...(now I'm a happy Fluxbox user
)
Did you read my post well? I said there is a crash in gnome-session even with NO gdm running. But whatever... it made me switch to Fluxbox and the world is spinning faster since then.
Well that doesn't mean it was the same cause. There are many different causes..
Can you confirm the TTY and the error in your everything.log that is seen with this bug?
it looks something like
gdm-binary[2052]: WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
There are very specific markers of this issue...
Also where did you use startx from, rc.local?
using startx with different session scripts shouldn't cause this issue. the session scripts don't generally much around with which TTY Xorg binds to.
And, unless your launching startx from rc.local or something, the various agetty's should of launched causing Xorg's auto attach to move to the last available TTY.
Also this was a known issue in a previous version of GDM. A bug report was filed back then and it was fixed. This is more than likely a regression that has happened.
I'm not having a go at you, I'm genuinely interested in your answers, as I feel the current "fix" of commenting out agetty on TTY2 is a dirty hack. However, you have to understand there is significant evidence to suggest that GDM is responsible. And when your testing has so little information about how it was performed, and lacks logs correlating your "out of sort" crash to the "gdm bug" , you have to expect to get some criticism.
Last edited by insanemal (2009-10-28 13:30:37)
Offline
Well that doesn't mean it was the same cause. There are many different causes..
Can you confirm the TTY and the error in your everything.log that is seen with this bug?
it looks something likegdm-binary[2052]: WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
No such error in everything.log, only following stuff in /var/log/gdm/:0.log
Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x38) [0x80b0078]
Segmentation fault at address 0xadca6200
Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting
There are very specific markers of this issue...
Also where did you use startx from, rc.local?
No, startx from TTY1.
using startx with different session scripts shouldn't cause this issue. the session scripts don't generally much around with which TTY Xorg binds to.
And, unless your launching startx from rc.local or something, the various agetty's should of launched causing Xorg's auto attach to move to the last available TTY.Also this was a known issue in a previous version of GDM. A bug report was filed back then and it was fixed. This is more than likely a regression that has happened.
I'm not having a go at you, I'm genuinely interested in your answers, as I feel the current "fix" of commenting out agetty on TTY2 is a dirty hack.
I'm sorry for my reaction.
TTY2 "fix" did not work for me, rc.local fix did not work for me either. I always started gdm by entering runlevel 5.
However, you have to understand there is significant evidence to suggest that GDM is responsible. And when your testing has so little information about how it was performed, and lacks logs correlating your "out of sort" crash to the "gdm bug" , you have to expect to get some criticism.
OK, I'll give it a try and I will attach some logs relating to this crash.
Simply, what leads me to believe that *my* crashes are not GDM related - currently I'm running Fluxbox session started from GDM at runlevel 5 (with inittab tty2 uncommented) more than 10 hours of excessive work without any problem. As I have more work to do, I'll do some Gnome testing as soon as I'm finished with it
Offline
OK, I'll give it a try and I will attach some logs relating to this crash.
Simply, what leads me to believe that *my* crashes are not GDM related - currently I'm running Fluxbox session started from GDM at runlevel 5 (with inittab tty2 uncommented) more than 10 hours of excessive work without any problem. As I have more work to do, I'll do some Gnome testing as soon as I'm finished with it
Awesome! What video card did you say you had?
Offline
jesusjimenez wrote:OK, I'll give it a try and I will attach some logs relating to this crash.
Simply, what leads me to believe that *my* crashes are not GDM related - currently I'm running Fluxbox session started from GDM at runlevel 5 (with inittab tty2 uncommented) more than 10 hours of excessive work without any problem. As I have more work to do, I'll do some Gnome testing as soon as I'm finished with itAwesome! What video card did you say you had?
nVidia Quadro NVS 140M @ ThinkPad R61, nvidia drivers 190.42-1
Offline
I'm having the same issue on my desktop. I have a nvidia card,... a 7800 I think. I haven't tried any of the fixes suggested in this thread, but I turned off the screen-locking password entering thing and am just avoiding the problem right now.
I don't think this is arch's problem.
Offline
inittab method helped me
Arch 64, xfce4
Offline
Glad that helped!!
Also Im seeing a trend in that Nvida and Intel seems to be effected.. but i havent seen many ATI people say they were effected.
Offline