Ok, use paste.debian or another one that permits large files and paste:

/var/log/smxi.log

and

/var/log/sgfxi/sgfxi.log

Whatever difference will be subtle it will be hard to find.
Back to top

smxi at paste.debian.net/137412/

sgfxi at paste.debian.net/137413/
Back to top

Thank you, that's helpful.

I'm wondering if the issue could come because when you start sgfxi from smxi, it tells it not to do the restart x thing at the end, but I wonder if I should have smxi simply exit when you start sgfxi, and let sgfxi handle the entire last part, since it seems to not have any issues.

While this isn't a fix per se since I still won't know why smxi fails, it might be worth just handing control over to sgfxi and exiting smxi execution.

Let me try that because it's the easiest thing to do, and it should in theory solve your issue.
Back to top

h2,

Thanks. That should work fine. A pragmatic solution!

drb
Back to top

actually, while testing this, I found one possible cause of the failure.

If the system is using systemd, and if you use the 'console login' option of kdm login screen, then that kills the x session, but does NOT kill the systemd kdm.service unit.

The result of this took me a few run throughs to notice, the issue was that the smxi/sgfxi x detection failed to find x since it was off, and did not check kdm, since in the pre systemd days, you could not be running kdm without xorg.

To counteract this issue, I have added in a new systemd test for x detection, which further checks to see if
systemctl list-units lists an active session for the dm detected.

Even if x is off now, with systemd, if the desktop is running, it will still shut it down.

This in my case fixed the failure to start dm/x from smxi, though the issue was not actually specific to smxi, sgfxi had the same failure.

But the behavior is exactly what you described, because kdm is already a running unit in systemctl, when smxi/sgfxi issue the start x command, systemd shrugs and says, it's already running, so nothing to do here, which results in no actual desktop / x start.

In that case, systemctl restart kdm.service fixed it too.

So that's at least one issue fixed.

Note that the failuire to detect x only happened if you chose the console login option from kdm logini screen, using ctrl alt f1 for example would show x to be running, and things should have worked.

So that's that.

This may or may not have fixed your issue, it depends on what you did.

The clear sign this was the cause was if you started smxi and it did not ask you to shut down your desktop/x at first. I should have spotted this the first time I tested it because i didn't see that question when smxi started, but it took a few times before I realized the running kdm was not being detected because x actually is off. I'm glad I used the console login option, I never actually use that in general, otherwise I would never have discovered this systemd oddity.
Back to top

I type smxi and it then asks me to shutdown the desktop to continue with the script
Back to top

I'm referring to a very specific circumstance, before this fix, if you used kdm login option 'console login'. All other methods would have shown the shutdown x option with or without this fix.

However, that's irrelevant, the question is, is it fixed in your case?

It's hard to test the cause because both smxi and sgfxi now contain the fixed systemd logic for desktop shutdown.

So if smxi still does this, it means that sgfxi is doing it, since smxi is not in the desktop start process any longer now after it starts sgfxi.
Back to top

I'll check at the next kernel update. I'll try to install driver in smxi.

drb
Back to top

Next kernel update came in today. nvidia 200 series graphics driver updated from within smxi with no problems.
Back to top

Oh, good, so that seems to have fixed it, that's a relief, heh.

This may also fix untold other unreported issues like that as well, I hope anyway, I know some distros had issues with running sgfxi from inside smxi, so this may have been related, at least as of using systemd it may have been, not before though.

thanks for keeping up on it.
Back to top