Greetings!

> Having something of a problem at the moment, so thought I'd
> gather together some questions for which I could really do
> with answers. BTW, I'm running developer v2.00 image on a
> Mk2a with a 30Gb Fujitsu and 60Gb Seagate as drives 0 and 1
> resepctively.

Okay.

> First ot all, what does the empeg do with swap? There's no
> mention of it in fstab, yet e.g. mp3tofid uses swapon -a, but
> my understanding is that this enables swap on devices
> specified as swap in fstab, so by my reckoning it does
> nothing. Obviously I'm missing something here. What?

When the drive is built, a dedicated swap partition is created. You will not see it in /etc/fstab, but you will get the swap space if you turn on the feature with the swapon command.

> After it got rebooted when still rw, the second drive
> (/dev/hdc4) will not fsck, it fails with:-
>
> no room for private writable mapping
> error: -12
> fsck.ext2: Memory allocation failed while retrying to read
> bitmaps for /dev/hdc

This means that the fsck failed because you ran out of memory. Turning swap on before running the fsck should help. If this is still not enough, you can create a local swap file on one of the other partitions and use that.

> I then used the Builder image to re-initialise both disks and
> re-installed the developer 2.00 image, but a few issues are
> still niggling.

Oh. Nevermind. Nuked from orbit.

> Any attempt to fsck /dev/hdc4 again still produces that same
> error. What is this, is it important, can I fix it? How?

See above. Basically, your drive (probably the 60) is too big to fsck with other applications in memory and you need to enable swap.

> Once running again and at the cmd prompt in HyperTerminal
> 'rw' produces a message saying "mount count exceeded, run
> fsck etc", but it is quick. fsck is simple and quick to do,
> but why would it say that immediately after the fresh install?

I assume you did a number of syncs in order to reload your music. That might account for the number of read/write mounts exceeding the count.

> The music partitions don't require fsck, but 'rwm' takes
> forever, well, 3.5 minutes in fact. This is basically the sum
> of the times to mount each music partition rw, the larger
> disk taking the longer time, but I didn't time them
> individually. Setting 'ro' again is virtually instant.

Yes. The mount command basically does a mini-check of the filesystem before doing its business. Edit your "rwm" command to include the nocheck option as below:

#!/bin/sh
mount -n -o remount,rw,nocheck /drive0
[ -e /proc/ide/hdb ] && mount -n -o remount,rw,nocheck /drive1

> I've been working with this empeg for some time and via
> telnet or ftp (I did have them available before
> re-initialising), rwm did not take that long, only maybe a
> second or so longer than setting 'ro'.

You (or someone else) may have done this previously.

> Needless to say I am relunctant to proceed with the rest of
> the setup until I know what's going on here. Why would both
> music partitions now be so slow, immediately after a fresh install?

A good fsck (with swap on at the time) will help. Also modify your rwm command (it is in /bin) to include that nocheck switch.

> Can anyone shed any light on these problems as I'm running
> out of ideas?

I hope this helps a bit.