Couple of things from the beta, still there?
I had a question with the beta that didn't get answered, and a problem ssh'ing in, see below:
The question is: when booting from CF, I don't get the option to type in grafpup pfix=ram or any other options. Is this because the bootloader installed on CF is smaller/less capable that the one on the CD's ?
And the problem ssh'ing in:
When I log in via ssh, I get an attempt to start Slim.... and then get logged out. This only happens when no-one is logged in at the actual machine - it is sitting at the login screen. This must be down to the fact that X is not running.
<logging in from a root account on another machine (SNAIL) on the local network>
root@SNAIL:~# ssh 192.168.1.88 (IP address of Grafpup machine)
Caching icons in /usr/share/pixmaps
This script will run X windows for you...
Starting X login manager, specs in /etc/X11/xorg.conf...
slim: Another instance of the program is already running with PID 2575
Exited from X. Type "xwin [openbox-session|jwm]" to restart X ([ ] mean optional).
To restart the login manager (Xorg only) type "xlogin"
(To shutdown PC type "poweroff", to reboot PC type "reboot")
If X failed to start, type "xorgwizard" to setup X
EDIT: Just found that you can Ctrl-C out of the login process to a prompt, if you're quick!
When someone is logged in at the machine itself, you can ssh in perfectly, it just drops to a shell prompt, which is all that's needed.
I can see that the login process could be improved to look at whether we're logging in remotely or not, and behave accordingly. I haven't yet got round to looking for the fix for this.
I might have a fix for the SSH-ing in problem (described above) when X is not already running. Not tested yet!
Add this line at the top of /usr/X11R7/bin/xwin
Yep, it works!
All I get now when SSH'ing in, is a 'Caching icons in /usr/share/pixmaps' and then later, 'Caching icons in /usr/share/mini-icons' which are harmless.
Nathan perhaps this fix could be incorporated into the release version? Sshd is included with Grafpup so it would make sense.
I'm on vacation now for a week.
Thanks for that, Simon. This was one I hadn't seen yet, and you even provided a fix!
I had a problem when using this fix I recommended, when I had vnc installed.
I had a VNC session open to the Grafpup machine as well as some SSH terminals, but was working on the console. I found that the xwin command was silently exiting due to my old fix.
I thought I'd better make sure the 'exit' didn't occur if the variable was *not* defined, which it could do with the old line.
You can prove it to yourself by saying to sh:
Happy 4th of July!
Still digging around trying to get my system 100%.
It seems there are two scripts that produce the output "This script will run X windows for you...." ie. xwin and xlogin.
My fix above was recommended for xwin, however xlogin gets run first usually.
I advise anyone using the fix above to apply it in xlogin (this is the place that will fix the issue, I think).
While you're in there, perhaps also change the output "This script will run X windows for you..." to something unique to xlogin. It will help with debugging as the same message from 2 sources can mislead.
Still testing this, and will keep in touch.
|All times are GMT -5. The time now is 10:30 PM.|