Hi

As some of you might know, I am trying to use my Empeg as secondary storage for images taken with my digicam (stored on Compact Flash cards) when I'm away from my computer.
My secondary harddrive is a CompactFlash card connected to the Empeg using an IDE-CF converter. The CF card is FAT formatted and its partition is seen as /dev/hdc1 from the empeg.

I have now run in to a small problem:
I get this message on the serial port when the Empeg boots:

Mounting second music parattempt to access beyond end of device

tition

03:44: rw=0, want=2, limit=0

dev 03:44 blksize=1024 blocknr=1 sector=2 size=1024 count=1

EXT2-fs: unable to read superblock

Tried to mount /dev/hdc4 but got error 22

Error mounting partitions (possibly already mounted)

I have no entries in my /etc/fstab that mounts /dev/hdc1 at boot (I mount & unmount the CF-partition manually using a script).

I could live with this errormessage, if it was only a problem at boot time. But I have now discovered, that when I try to synchronize the Empeg using Emplode, the Empeg reboots,
Emplode returns the following error: "Synchronize failed while checking media" and I get a similar output on the serial port:

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

/sbin/fsck.ext2: Attempt to read block from filesystem resultattempt to access beyond end of device

ed in sho03:44: rw=0, want=2, limit=0

rt read wdev 03:44 blksize=1024 blocknr=1 sector=2 size=1024 count=1

hile trying tEXT2-fs: unable to read superblock

o open /dev/hdc4

Restored terminal settings

Remounting first music partition read-only

Remounting second music partition read-only

No secondary hard disk

Restart code received

Starting player

It seems to me as if something forces a mount and a fsck on /dev/hdc4.
I tried disabling "Filesystem Check on Sync" and disabling the "Search for a second harddrive" using Hijack, but none of it has helped...

Does anyone know, if it is the player application that does this mount or is it "built into" the kernel ?

If it is located in the kernel I could just build my own special kernel with the fix in it (if someone could tell me where to look), as I'm probably the only person on the planet with this specific problem (at least I have now learned how to compile my own Empeg kernels with FAT support, so I won't be bothering you with THAT when the next version of Hijack is released )

Regards
Nicolai

I think init actually mounts all the drives. People have written replacement shell scripts that do all of the necessary stuff init does, you might want to have a look for those.

- Trevor

I'm pretty sure that the "player" executeable does the "remount rw" operation during the "synchronize", and that's the part that is messing up for you here. Pitty the software isn't just a bit more clever about things, but it is not, and we don't have source code to fix it.

So, you'll have to hack the kernel -- just have it check the process name of the caller to "sys_remount", and silently fail /dev/hdc4 whenever the process name is "/empeg/bin/player". This test can be done as:

    if (!strcmp(current->comm, "player")) {

        // player software is doing this call

    }

Cheers

Hi Mark & Trevor

I put the following "hack" into the kernel in /fs/super.c :

	if (!strcmp(dev_name, "/dev/hdc4")) {

		printk("Skipping mount of /dev/hdc4\n");

		free_mount_page(page);

		retval = 0;

		goto out;

I decided just to check for any attempt to mount /dev/hdc4 as I will not be needing this device at all.
It does the trick of silently ignoring any attempts to mount the filesystem.

But now it seems to me, as if it is the fsck.ext2 following the mount that makes the synchronization fail. This is probably built into the player application as you suggested. I have tried a lot of fiddling around with using scripts to intercept the fsck.ext2 call but with no luck.

I also tried returning another value than 0 in the mount system call, to tell the system that the mount went wrong, but apparently this doesn't stop the player app from trying to run an fsck on it...

In the meantime I also found out that Jemplode apparently synch's ok - while Emplode still fails.
As I can just use Jemplode, I have decided to just ignore the "problem"...
But at least I had a lot of fun poking around in the kernel

Thank you both for your suggestions...

/Nicolai

Umm.. I suspect doing that would also prevent you from copying files from the flash card, n'est-ce pas?

Speaking of which.. rather than bloating the kernel with the MS-DOS filesystem code, one might instead try porting the "mtools" package to the Empeg (should port fairly easily).

Cheers

Hi Mark

No problem copying the images from the CF card.
They are located on /dev/hdc1 ...

Porting the mtools sounds like a great idea though...

/Nicolai