Programmer: you ask "If anyone has boot scripts set up to boot into X that would be very useful for me (I don't really have the time to go looking for how to set it up).. .. That takes time at home, most of this I can do from work.."
Well, I had to come home from work to answer this. It took a while to get it to boot into X. There is a lot out there on usenet archives about that, but doesn't work on the iopener. Login is one of the many programs that is just a link to busybox. There was a good article about busybox in a recent linux journal. Basically, depending on how much you choose to compile in, the busybox binary can have more or less of the functionality of each of the apps it runs. One approach used to boot into X on normal boxes is to define a run level where instead of spawning a getty, you login and then start X as that user, like this:
1:3:respawn:/bin/su - username -c /usr/X11R6/bin/startx
or something like that.
I forget exactly what I read on dejanews, but I think people claimed that since init is run by root, it is not supposed to prompt for a password. However, the busybox login does prompt for a password, so this doesn't work.
Instead, I have this line in my inittab:
1:3:respawn:/bin/su - username
and then in /etc/passwd, I define username's shell as startx like thus:
username::100:100:JAILBAIT User,,,:/home/user:/usr/X11R6/bin/startx
OK, so I just announced to the world that there is a user login on my I-O without a password (notice the space between the first colons). Well, maybe some security guru will tell me how this is a security risk, but the fact is there is no telnetd running, and try as I might, ssh and ssh-X will just give me "X is already running errors" when I try to log in via ssh. And that was before I turned off allowing ssh logins to passwordless users. So I think I am OK.
Note, I have /home/user mounted over NFS during booting, so I can save stuff, like blackbox preferences and jukebox settings.
Note also, I also keep a run level 2 around so that I can boot just into a shell as normal. The first tty will of course come up blamk, but alt over to the next and log in as usual. There doesn't seem to be a delay at boot time, but if you keep hitting tab during boot, it will allow you to add "init 2" to lilo.
I can't for the life of me remember what writes the /var/lemxclients and /var/lemxinitres; it is done is a script somewhere. I couldn't find it just now (another hint: to get a visual file manager, I have netscape run via ssh -X over from the iopener right now, and just pointed it to file:/ and viola, instant remote-display file manager of your jailbait file system!). Anyway, get the commands you want run at start up in there (including blackbox), and away you go. I have it start up kjukebox, open to the .jbd file holding its configuration.
Northstar: I am not familiar with GQView. I remember trying to run XMMS on the I-O while I briefly had a hard drive in there (with RH 6.2 and a 2.2.14 kernel with the USB backport running). It didn't seem as if the I-O had enough horsepower to run XMMS, although I tihnk that may have just because of the animations I had on. Sometimes my I-O will just barely get by with kmpg with a XMMS-like skin, including animation, while the animation-less kjukebox works well.
The other thing about pulling in XMMS is that you also need the gtk/gnome libs. Of course, I had to bring in QT and KDE libs for kjukebox. And that was a pain. Bringing in everything indicated by ldd was easy. But there are plenty of other files, such as button bitmaps and config files that are scattered over the place that I had to find by trial and error before I got it all to work. Maybe it would be easier with gnome and GTK. The point is, this took me a while and may not be something Programmer does on a lark.
A couple of other points: /devfs is a pain. I had problems with getting permissions on the sound devices (which of course are not persistent). I tried the persistence kludges on the devfs web pages, but that just made my I-O unbootable and I had to do hook up the hard drive again to get the sandisk back to working condition. So instead, I just have another script run at startup that sets the permissions on the sound devices so that users can write to them.
