Could somebody outline the exact procedure they used to install e17ka on their un-networked Efika?

I don't think I can remember all the details, but this might help to get you started.

First - extract the contents to a disk, USB or 2.5" HDD (I used the 2.5" drive).
Second - edit the BootE17 script to make sure it's booting from the proper device (hd:0, etc. You might have to get into OF with whatever device youre booting to make sure what the device name is).

Run the BootE17 script and choose the option that you configured.

Enjoy!

_________________
I <3 tiny computers.

OK - I'm starting to get somewhere now. I didn't even realise that Open/SmartFirmware recognized scripts.

Before getting this far I took a major detour trying to create an ext2 partition and then copy files to it. As it turned out, fat32 was sufficient afterall.

Of course, I'd have covered this ground months ago if my usb flashdrive was properly recognized by SF - this is a bug, right? Is it ever going to be fixed?

How much space is available for the Efika's firmware? And how big is SF already for that matter?

Aah, yes. Fat32 is indeed sufficient.
Some drives work, some don't. Not necessarily a bug, some drives just don't conform PRECISELY to the usb mass storage specs.
Dunno how big SF is at the moment.. Matt AKA Neko would be better at answering that.
And yes, you can have Forth scripts in SF. Kinda handy for dual-boot type situations.

_________________
I <3 tiny computers.

Judging by the swapped 'z' and 'y' keys, e17ka is setup for a German keyboard layout - how do I change that?

e17ka has been ok for getting started but I'm finding the live image file layout a bit mysterious. Is it possible to just copy files over to an empty partitiion to be used as a bootable system? I gather an entirely different set of kernal arguments would be needed - what might they be?

Just in case a fellow linux newbie is reading this thread and having the same issues I've been having (and perhsps wondering why they went to the expense and trouble of bothering with this hardware/software combination) -

edit your etc/x11/xorg.conf file so that

Option "XkbLayout" "de"

becomes

Option "XkbLayout" "us"


Yeah. Can you really believe this is the 21st century?


_________________
For every Linux-snob there are 1000 windows users who just get the job done.

Man, I am glad this live-image works at all but it sure does have some rough edges...

For those that want to persist, the xorg.conf file is ever so slightly more conveniently also located in the root directory. So, if you open Leafpad and select 'Open...' from the 'File' menu, you'll see it as the last entry in the file selection dialogue box.

I will also point out that of the screen depths and resolutions that are defined in xorg.conf there is no 32 bit option. So why does boote17 pass the following kernel argument:

video=radeonfb:800x600-32

And why is it that changing that to a bit depth that is actually available still results in the highest possible resolution being used by Enlightenment?

There's another suspect kernel argument in there too:

root=/dev/ram

'ls /dev/ram*' shows ram0 through ram15 but there is no /dev/ram

While I'm on this little hobby-horse, after starting up I get a warning message about the theme - I'm guessing this has something to do with:

splash=verbose,theme:e17ka

Something as simple as setting the hardware clock is defeated by botched 'Restart' and 'Shutdown' procedures. I'm setting the system time by hand with 'date --set=<date> +<time>' And the only reason I would expect to achieve an updated hardware clock through a shutdown is that I stumbled upon /etc/conf.d/clock which contains the lines:

# TIMEZONE="Factory"

# If you want to set the Hardware Clock to the current System Time
# during shutdown, then say "yes" here.

CLOCK_SYSTOHC="no"

The solution would seem to be: Switch to a better distrbution.

video=radeonfb:800x600-32 is the framebuffer console resolution and bit-depth. I usually set it to 1280x1024-32, for massive console real estate :)
It has no effect in X.

root=/dev/ram because it uses a ramdisk.

and the theme just isn't present, I killed it from the command so it doesn't bitch anymore.

The distro is Gentoo, which is proven. e17ka is just one that's been put together for easy access on the Efika. It was also done fairly early in the Efika's lifetime, so there are things that hadn't been implemented then.

I wouldn't use it primarily, but it's a good demo to show off basic use of the system.

_________________
I <3 tiny computers.

Despite my carping on about it, I do like it for the fact that it got me to a (very nice!) graphical interface with only a mild amount of fuss.

Concerning the 'root=/dev/ram' kernel argument, doesn't it matter that /dev/ram doesn't exist?

When linux users talk about a console, is that a text only display or is it also capable of showing a bitmapped graphical display? If it's the former, why does it need to be 32 bits deep?

The console doesn't need to be 32bit, as it IS a text display. Is there any reason why it shouldn't be, though? We'd want to keep it higher bitdepth than monochrome, as some of us like colours in our console :)

_________________
I <3 tiny computers.

No good reason but there is no point having it any less.

_________________
Matt Sealey