Hi again,

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)
Password: xxxxxx
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
root@SNAIL:~#

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

This -may- sort out the problem, I will test and update this thread.
Simon.

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.

Cheers,
Simon.

Thanks for that, Simon. This was one I hadn't seen yet, and you even provided a fix!

Nathan

I had a problem when using this fix I recommended, when I had vnc installed.

So I had a look around the net and this seems more robust:

It uses a little known construct, reference can be found here www.ooblick.com/text/sh/

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:
The shell returns a blank line for a non-existent shell variable, and this I think was messing up my old test. The new one doesn't fall foul of that.

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.
Simon.