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.

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?

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

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.

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

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?

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.

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

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?

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

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.

Quote:
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.

But doesn't swapon -a only work for devices marked as swap in fstab (that's what the man page says)? So exactly what swap is being enabled with swapon -a?

If the memory error when doing fsck is down to this then once I get my head around swap I should be ok:-)

Quote:
> 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.

No, this was immediately after disk initialisation with the builder image then installing the developer image. There is NO music on this - yet.

Quote:
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.
You (or someone else) may have done this previously.

Ah, yes, now I see, it was Roger:-)

I have previously used Roger's Base selection and that of course includes replacement rwm etc. That explains that. Phew, at least my system actually seems to be ok

Thanks for that. Would appreciate some more explanation of swap. How would I turn on swap on both drives?

Also, what owner and group should everything be? I would assume root:root, but I see odd UID and GID numbers, but without chown I can't change them. How does it decide what UID and GID to use? Is there a chown available?

swapon -a has no effect unless /etc/fstab has swap entries.

This can be verified after issuing the command, by following up with
cat /proc/meminfo

Cheers

Well, the swap partitions are built with the disk build. They are not included in the fstab. If you look at the root of the player, you will see that there is a symbolic link (/swapfile) that points to the device partition (/dev/hda6). When you do the "swapon -a /swapfile" you add the file (symlink to a full partition) to swapspace. No fstab needed.

In certain extreme cases, even this was not enough space to get through an fsck. Usually only when there were lots of disk problems. In that situation, you can allocate space under another filesystem and add it in the same manner.

I guess doing it this way as opposed to fstab was to only use the swap when absolutely needed, avoiding random disk access while on the road.

As for the mount count, I am not as certain. Perhaps the variable or flag was not cleared from the rebuild. I would not have expected that, though. At least it will clear properly with a final fsck. Perhaps others can comment on why it did not clear. (Unless the disk build actually failed. Then I could understand it.)

For turning swap on for both drives (assuming the partitions and space are available on both drives), you would create a symlink in the root of your player (a one-time action) and attach swap to it when needed, thus:

ln -s ./dev/hdc6 swapfile2 # one time action
swapon -a /swapfile2

As for UID & GID, I never worked to get telnet loaded, so the /etc/password on my player is still original. I do not see a chown as part of the default install, but it may come packaged with telnet. Worst case, you can always grab it from a debian distribution.

Edit: Damn. Too slow...

I just verified that swapon -a does nothing. So Pim must have something in his fstab that he omitted to mention in mp3tofid (or that I couldn't see).

As far as I can see, adding the swap lines (for both partitions - 1 on each disk) to fstab won't change anything until swapon -a is used, which will turn on swap for both partitions and then swapoff -a will do the reverse, but it won't affect normal running, It just allows a simple method to turn on all swap (and off).

Any reason therefore not to add them to fstab?