I was uploading a long MP3 when Win98 crashed. I rebooted and tried starting Emplode again. And everytime I try to start up Emplode I get this error message:

In reply to:

---

Download failed while checking media. Error 0xc0041016

---

The player boots up fine but everything has been erased. Even the owner information is erased.

I'm running WIn98, with v2.0b11 with no Hijack. I need some advice ASAP. Anything would be greatly appreciated.

Curly

Doesn't sound good:( Can you hook it up to the serial prompt and capture the text that it's spitting out?

...Look here for steps on how to connect to the serial prompt if you don't already know how:

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=7&categories=Upgrade%2C+customization%2C+and+third-party+software+questions#82

-mark

OK, that was the first time I've done that. Here's what it said:

In reply to:

---

I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
EXT2-fs error (device ide0(3,4)): ext2_check_descriptors: Block bitmap for group
0 not in group (block 1396520500)!
Remounting filesystem read-only
EXT2-fs: group descriptors corrupted !
Tried to mount /dev/hda4 as ext2 but got error 22
Error mounting partitions (possibly already mounted)
Remounting first music partition read-only
No primary hard disk
Remounting second music partition read-only
No secondary hard disk
Press 'q' now to go into development mode. You Have Zero Seconds To ComplyþStart
ing player
player.cpp : 385:empeg-car 2.00-beta11 2002/02/08.
! tags.cpp : 61:Failed to open tags (0xc0041002).
Prolux 4 empeg car - 2.1434 Feb 7 2002
Vcb: 0x4086d000

---

Not good - it's telling you that your drive is corrupted... equivilant of windows telling you to run scandisk..

can you get a shell prompt?
drop to a shell (press "q" when it says to), then try forcing a checkdisk...

umount /dev/hda4
fsck -f /dev/hda4

-m

Ok I'm assuming I did it correctly. Here's the results:

In reply to:

---

empeg:/empeg/bin# umount /dev/hda4
umount: /dev/hda4: not found
empeg:/empeg/bin# fsck -f /dev/hda4
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
Group descriptors look bad... trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

empeg:/empeg/bin#

---

I'm assuming that "empeg:/empeg/bin#_" is the prompt and "umount /dev/hda4" and "fsck -f /dev/hda4" are commands?

>sigh< doesn't look good..

You might want to wait until someone from Empeg can verify what I'm recommending (or offer a better solution), but you might need to re-initialize that disk (wiping everything) then reload:(

-mark

Yeah - you did it right.. actually, just found an FAQ on that item as well:

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=8&categories=Known+problems+and+troubleshooting+questions#162

-m

In reply to:

---

>sigh< doesn't look good..

You might want to wait until someone from Empeg can verify what I'm recommending (or offer a better solution), but you might need to re-initialize that disk (wiping everything) then reload:(

---

OMG!!

Maybe there's a problem with the disk drive cable:
http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=8&categories=Known+problems+and+troubleshooting+questions#148

or

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=8#85

I doubt it - if it was a disk drive problem, you wouldn't have gotten as far as you did with the bootup process...

Your drive (I'm assuming that it's a single-drive unit?) is split into seperate partitions; the partition that boot up the empeg is fine, the one holding the music isn't...

...In the case of a disconnected cable, the empeg just doens't boot...

-mark

Ok Mark, thanks for all the help.

I guess I'll just hit the sack and hopefully someone from Empeg, or another brilliant mind, will offer some more advice by the time I wake up

-Curly-

In reply to:

---

Group descriptors look bad... trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

---

Did you try its suggestion?

fsck -b 8193 -f /dev/hda4

I have now. Here is the result:

In reply to:

---

empeg:/empeg/bin# fsck -b 8193 -f /dev/hda4
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

---

Greetings!

OK. Relax. Don't Panic. Yet.

Please post a complete boot log.

Also, you might want to try the following:

1) - get to shell
2) swapon /swapfile
3) umount /drive0
4) umount /drive1 *
5) fsck -fay /
6) fsck -fay /dev/hda4
7) fsck -fay /dev/hdc4 *
8) swapoff
9) - reboot

* - if two drive model.

Hmm, it looks like fsck doesn't pass the -b parameter through to e2fsck. Try running e2fsck directly:

e2fsck -b 8193 /dev/hda4

If that doesn't work, ask somebody else for ideas, as I'm out of them...

e2fsck -b 8193 /dev/hda4

Does mke2fs always put a backup superblock at 8193? Last I heard, its algorithm was pretty wyrd (all powers of 3 and 5, times some large factor that varies with the size of the drive). There isn't even a "mke2fs --dry-run" that tells you where it's putting them.

Peter

In reply to:

---

Does mke2fs always put a backup superblock at 8193?

---

Dunno - I admit to being on guesswork here.

Here's what the e2fsck manpage on my workstation says:

-b superblock

Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used when the primary superblock has been corrupted. The location of the backup superblock is dependent on the filesystem's blocksize. For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768.

Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the superblocks were created. The -b option to mke2fs, which specifies blocksize of the filesystem must be specified in order for the superblock locations that are printed out to be accurate.

If an alternative superblock is specified and the filesystem is not opened read-only, e2fsck will make sure that the primary superblock is updated appropriately upon completion of the filesystem check.

In reply to:

---

There isn't even a "mke2fs --dry-run" that tells you where it's putting them.

---

"man mke2fs" says:

-n causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem.

Does that not tell you where the superblocks are going? What if you also use -v?

Also,looking at the mke2fs manpage, it mentions rebuilding the superblock if you know the right parameters, using the -S option. Anyone know what incantation to use this on the Empeg?

For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768.

OK, so all those numbers are worth a try for e2fsck -b number.

-n causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem.

This is exactly what's needed, but didn't IIRC exist in the e2fsprogs 1.18 that car players are built with.

Peter

Ok here's the boot log that Paul requested. This is all new to me so bare with me if I get things incorrect.

Ok here are the results from what Paul suggested to do:

In reply to:

---

empeg:/empeg/bin# swapon /swapfile
Adding Swap: 16596k swap-space (priority -1)
empeg:/empeg/bin# umount /drive0
umount: /drive0: not mounted
empeg:/empeg/bin# fsck -fay /
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda5 is mounted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda5: 1510/4096 files (0.5% non-contiguous), 9427/16384 blocks
empeg:/empeg/bin# fsck -fay /dev/hda4
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
Group descriptors look bad... trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

empeg:/empeg/bin# swapoff
usage: swapoff [-hV]
swapoff -a [-v]
swapoff [-v] [-p priority] special ...
swapoff [-s]

---

Here's the result from what Toby suggested:

empeg:/empeg/bin# e2fsck -b 8193 /dev/hda4
bash: e2fsck: command not found

Oops - my bad! On the empeg, it's called fsck.ext2, not e2fsck. Sorry! Just change the name, and try again.

here's the result:

empeg:/empeg/bin# fsck.ext2 -b 8193 /dev/hda4
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

empeg:/empeg/bin#

Well, that's me out of ideas, then. Sorry.

Greetings!

I tried opening the log file, but it gave a 404 error. I remember seeing a similar superblock error when I was trying to fsck and was using the wrong device name.

A possibility - try reloading the default software. Use the upgrade empeg and the stock developer version. This will not do anything to the music partitions, but will reset your system software to a factory state. Also, are you still running hijack?

Maybe this will help someone. Here's the beginning of the what's displayed at HyperTerminal startup:

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.14-rmk5-np17-empeg50 ([email protected]) (gcc versi
on 2.95.3 20010315 (release)) #7 Fri Feb 8 18:45:38 GMT 2002
Processor: Intel StrongARM-1100 revision 11
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 10101453)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15024k/16M available (964k code, 20k reserved, 372k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0005d80).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: IBM-DJSA-220, 19077MB w/1874kB Cache, CHS=38760/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman ([email protected])

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:22:05:a
d
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...•Ô•j½Õ¹Ñ•‘�ɽ½Ñ�¡•áÑÉ�™¥±•ÍåÍÑ•µ¥�É•…‘½¹±å¹)5ÿchan
ge_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initempeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
EXT2-fs error (device ide0(3,4)): ext2_check_descriptors: Block bitmap for group
0 not in group (block 1396520500)!
Remounting filesystem read-only
EXT2-fs: group descriptors corrupted !
Tried to mount /dev/hda4 as ext2 but got error 22
Error mounting partitions (possibly already mounted)
Remounting first music partition read-only
No primary hard disk
Remounting second music partition read-only
No secondary hard disk
Press 'q' now to go into development mode. You Have Zero Seconds To ComplùStarti
ng player
player.cpp : 385:empeg-car 2.00-beta11 2002/02/08.
! tags.cpp : 61:Failed to open tags (0xc0041002).
Prolux 4 empeg car - 2.1434 Feb 7 2002
Vcb: 0x4086d000

Greetings!

Hmm... okay... the boot went through okay... filesystem...

What bothers me is that the fsck -fay looks like it attempted to use an alternative superblock and failed. Although, I just tested this on my empeg. The superblock error you are receiving is the NORMAL error if the command string contains an incorrect device. I remember seeing it before....

Hold...

Edit:

Never mind. The first lines for finding the bad descriptor are new. The superblock paragraph is common. Are you at the factory installation at this point?

I've never run Hijack. So should I uninstall 2.0b11 and reinstall 1.03? If so, is there a procedure to uninstall v2.0b11 from the player or that happens automatically when I install v1.03?

Also attatching log file again.

go here for the log file: http://home.socal.rr.com/astroturf/EMPLODE.nfo

I changed the .log to .nfo

If you are on 2.0b11, that is fine. Hijack was the add on I was thinking of.

Have you contacted support yet? I am running out of ideas (that will save your data). You may also want to drop a note to Mark Lord. If anyone can help diagnose fs problems...

Incorrect device... (thinks)

I don't see how it could happen, but is /dev/ corrupted? What does "ls -l /dev/hda*" give?

I get

empeg:/empeg/bin# ls -l /dev/hda*

brw-------    1 0        0          3,   0 Apr 18  1999 /dev/hda

brw-------    1 0        0          3,   1 Apr 18  1999 /dev/hda1

brw-------    1 0        0          3,   2 Apr 18  1999 /dev/hda2

brw-------    1 0        0          3,   3 Apr 18  1999 /dev/hda3

brw-------    1 0        0          3,   4 Apr 18  1999 /dev/hda4

brw-------    1 0        0          3,   5 Apr 18  1999 /dev/hda5

brw-------    1 0        0          3,   6 Apr 18  1999 /dev/hda6

brw-------    1 0        0          3,   7 Apr 18  1999 /dev/hda7

brw-------    1 0        0          3,   8 Apr 18  1999 /dev/hda8

brw-------    1 0        0          3,   9 Apr 18  1999 /dev/hda9

If you don't see this, then something's wrong.

EDIT: What worries me more is that the partition table has gone off into a wibbly wobbly world of its own, though again I don't see how losing the PC during a sync could cause that.

No I haven't contacted support yet. I thought I'd give you guys a crack at it first (I know how you guys like a good challenge). I'll give M.Lord a holler and contact support in a few minutes.

This:

empeg:/empeg/bin# ls -l /dev/hda*
brw------- 1 0 0 3, 0 Apr 18 1999 /dev/hda
brw------- 1 0 0 3, 1 Apr 18 1999 /dev/hda1
brw------- 1 0 0 3, 2 Apr 18 1999 /dev/hda2
brw------- 1 0 0 3, 3 Apr 18 1999 /dev/hda3
brw------- 1 0 0 3, 4 Apr 18 1999 /dev/hda4
brw------- 1 0 0 3, 5 Apr 18 1999 /dev/hda5
brw------- 1 0 0 3, 6 Apr 18 1999 /dev/hda6
brw------- 1 0 0 3, 7 Apr 18 1999 /dev/hda7
brw------- 1 0 0 3, 8 Apr 18 1999 /dev/hda8
brw------- 1 0 0 3, 9 Apr 18 1999 /dev/hda9
empeg:/empeg/bin#

Can you try "fsck.ext2 -b 32768 /dev/hda4" ?

I thought that mke2fs defaulted to 4k blocks. It certainly doesn't make sense for 1k blocks to be used for music partitions anyway. If anything they're going to be larger blocksizes.

Hopefully you've done it Genixia. Here's the result:

empeg:/empeg/bin# fsck.ext2 -b 32768 /dev/hda4
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
/dev/hda4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'database' in /var (4097) has deleted/unused inode 4098. Clear<y>?

should I enter "Y"?

Personally, I would hit 'y', but I'm a risk taker. The fact that I've never seen e2fsck get anything wrong helps too...

IIRC, I seem to remember reading that the /var parition could be wiped at will - and that anything important gets recreated. In particular, the database gets rebuilt everytime you sync the empeg anyway. But you might want to check this information first.

Anyone else want to chime in?

Yeah I think you're right because I read this last night:

"I had my databases and stuff somehow corrupted and all you need to do to get them back is delete the files /empeg/var/playlists, /empeg/var/tags, and /empeg/var/database and then re-sync. All those files will be rebuilt and it should have gotten you back your original playlists." -Yn0t_

taken from here:http://empeg.comms.net/php/showthreaded.php?Cat=&Board=empeg_general&Number=59084&Search=true&Forum=empeg_general&Words=%2Fempeg%2Fvar&Match=And&Searchpage=0&Limit=25&Old=allposts&Main=59058

I tried to delete those earlier but Empeg couldn't find them. Documented here: http://empeg.comms.net/php/showflat.php?Cat=&Board=empeg_general&Number=86748&page=0&view=collapsed&sb=5&o=0&fpart=

I'm just waiting for one more person to say "Go For It!" Only because you didn't seem too sure of the consequences. And because I have no idea what I'm doing.

Well, removing the inode entry is equivalent to deleting it anyway, which you've already tried..so I say go for it with that one, and also tags and playlist.

Ultimately as I understand it, e2fsck is telling you that you a have an inode pointing to a physically non-existant file. Whether the inode is there or not doesn't really matter at this point - the file is missing.

Ok I went for it. Here's the result:

empeg:/empeg/bin# fsck.ext2 -b 32768 /dev/hda4
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
/dev/hda4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'database' in /var (4097) has deleted/unused inode 4098. Clear<y>? yes

Entry 'playlists' in /var (4097) has deleted/unused inode 4099. Clear<y>? yes

Entry 'tags' in /var (4097) has deleted/unused inode 4100. Clear<y>? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -3112963 -3112964 -3115019 -3115020 -3118394 -3118395
-3118396 -3118397 -3118398 -3118399 -3172820 -3172821 -3172822 -3172823 -317282
4 -3172825 -3172826 -3172827 -3172828 -3172829 -3172830 -3172831 -3172832 -31728
33 -3172834 -3172835 -3172836 -3172837 -3172838 -3172839 -3172840 -3172841 -3172
842 -3172843 -3172844 -3172845 -3172846 -3172847 -3172848 -3172849 -3172850 -317
2851 -3172852 -3172853 -3172854 -3172855 -3172856 -3172857 -3172858 -3172859 -31
72860 -3172861 -3172862 -3172863 -3172864 -3172865 -3172868 -3172869 -3172876
Fix<y>? yes

Free blocks count wrong for group #44 (15293, counted=0).
Fix<y>? yes

Free blocks count wrong for group #47 (2, counted=0).
Fix<y>? yes

Free blocks count wrong for group #48 (8553, counted=0).
Fix<y>? yes

Free blocks count wrong for group #49 (13701, counted=0).
Fix<y>? yes

Free blocks count wrong for group #51 (4764, counted=0).
Fix<y>? yes

Free blocks count wrong for group #65 (1, counted=0).
Fix<y>? yes

Free blocks count wrong for group #69 (1, counted=0).
Fix<y>? yes

Free blocks count wrong for group #71 (1, counted=0).
Fix<y>? yes

Free blocks count wrong for group #88 (1, counted=0).
Fix<y>? yes

Free blocks count wrong for group #94 (24949, counted=0).
Fix<y>? yes

Free blocks count wrong for group #95 (32734, counted=10).
Fix<y>? yes

Free blocks count wrong for group #96 (32734, counted=5679).
Fix<y>? yes

Free blocks count wrong (1880885, counted=1753840).
Fix<y>? yes

Inode bitmap differences: -4098 -4099 -4100
Fix<y>? yes

Free inodes count wrong for group #3 (36, counted=0).
Fix<y>? yes

Free inodes count wrong for group #4 (1019, counted=1022).
Fix<y>? yes

Free inodes count wrong for group #9 (935, counted=878).
Fix<y>? yes

Free inodes count wrong (149435, counted=149345).
Fix<y>? yes


/dev/hda4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda4: 3231/152576 files (5.9% non-contiguous), 3109130/4862970 blocks

Now what?

Well Genixia WINS!!! Great job! Everything back to normal. Everything was rebuilt and I did a synch with Emplode which worked perfectly. A big thanks to everyone that helped out, especially to you Genixia.

I think that the credit should go to the designers and coders of ext2fs and it's related tools.

Question remains: What was the cause and how to prevent it from happening again.

Oversized config.ini? Lack of jiffies-fix in the kernel? What?

I hope it was the jiffies so that we could get the latest alpha sent to beta! Just like the cut&paste thing got us beta11 real quick!

How can I check to see if the Config.ini is "oversized"?

Naah. My theory:
The drives were put into r/w by emplode. Win98 then crashed, leaving the drives in r/w. When win98 gets rebooted, emplode cannot connect to the empeg because the empeg already has a sync session in progress. empeg gets powered-down with the discs still mounted r/w, and the corruption occurs in the main superblock, necessitating the use of an alternative superblock to complete e2fsck.

This is probably worth FAQing. ie, the part that if you see a bad superblock message that causes fsck to fail then to specify -b 32768. Although input from the empeg guys should probably be sought.

If this bad superblock thing is true, would the instructions be something that can be added logically to the existing FAQ entry on FSCK? Could I get an accurate syntax and a consensus on the proper directions?

No one answered your question about the config.ini. Here is the FAQ entry on it. Basically, it is only a concern if you have played with the "favorite visuals" feature in emplode...

Thanks. I failed to say that after all was fixed, the Visual Favorites did get deleted and I had to reprogram it. Now come to think of it I might have synced more than once in a single session, something that I forgot not to do with v2.0b11. When's the next beta coming out? j/k

Well, I'm kinda late tuning in (might have saved some time, but igenixia figured it out, well done!), but for the FAQ just simply say,

If you see this:

   fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4



then do this:

   fsck.ext2 -fay -b 32768 /dev/hda4

Cheers

EDIT: added -fay to the above

Do the drives need to be mounted read-write, read-only...?

After it's done... Do I have to set it back...?

Drives should NOT be mounted read-write (they won't be, either, unless the user mounted them him/her self). Read-only is okay; or not mounted at all is good, too.

Afterwards, just reboot the player (cycle the power).

Cheers

The drives were put into r/w by emplode. Win98 then crashed, leaving the drives in r/w. When win98 gets rebooted, emplode cannot connect to the empeg because the empeg already has a sync session in progress. empeg gets powered-down with the discs still mounted r/w, and the corruption occurs in the main superblock, necessitating the use of an alternative superblock to complete e2fsck.

That would be my guess too.

Interestingly, there is a failsafe in the player that can sometimes stop this happening. If the PC or Emplode crashes, but the player does not, the player eventually (2 minutes later) decides that Emplode isn't coming back, and remounts the discs read-only by itself.

So the message is (and I admit here it's our fault for not getting the message out more), if your PC has crashed while the Empeg has the "synchronising" screen up, wait for the sychronising screen to go away before powering off the Empeg. Any playlists you were editing will probably still be lost, but at least your filesystem will not get borked.

Peter

Drives should NOT be mounted read-write (they won't be, either, unless the user mounted them him/her self). Read-only is okay; or not mounted at all is good, too.

Afterwards, just reboot the player (cycle the power).

Indeed. And the rebooting bit is important: you can easily scrag your filesystem if you mount it read-only for fsck, then fsck fixes something, then you remount it read-write and do stuff to it. So always either (a) unmount the filesystem to fsck it, or (b) reboot afterwards if fsck made any modifications. For music partitions (a) is easier, but obviously for the root partition (b) is the only way.

Failure to do either (a) or (b) was the bug in the only known alpha release of the player ever to have hosed someone's music partition.

Peter

Okay, additions to FAQ entry made, per the comments in this thread.

Well it happened again today. Recieved the same error as the one mentioned in the first post. Windows did not crash this time and I have Hijack installed. Here's the Hyper Terminal login info:


NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0005d80).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: IBM-DJSA-220, 19077MB w/1874kB Cache, CHS=38760/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman ([email protected])

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:22:05:a
d
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...•Ô•j½Õ¹Ñ•‘�ɽ½Ñ�¡•áÑÉ�™¥±•ÍåÍÑ•µ¥�É•…‘½¹±å¹)5ÿchan
ge_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initempeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
EXT2-fs error (device ide0(3,4)): ext2_check_descriptors: Block bitmap for group
0 not in group (block 1396520500)!
Remounting filesystem read-only
EXT2-fs: group descriptors corrupted !
Tried to mount /dev/hda4 as ext2 but got error 22
Error mounting partitions (possibly already mounted)
Remounting first music partition read-only
No primary hard disk
Remounting second music partition read-only
No secondary hard disk
Press 'q' now to go into development mode. You Have Zero Seconds To ComplùStarti
ng player
player.cpp : 385:empeg-car 2.00-beta11 2002/02/08.
! tags.cpp : 61:Failed to open tags (0xc0041002).
Prolux 4 empeg car - 2.1434 Feb 7 2002
Vcb: 0x4086d000
q
Restored terminal settings
Remounting first music partition read-only
No primary hard disk
Remounting second music partition read-only
No secondary hard disk
Player exited normally: 0
Switching to shell-player loop
Starting bash.
empeg:/empeg/bin# e2fsck -b 8193 /dev/hda4
bash: e2fsck: command not found
empeg:/empeg/bin# fsck.ext2 -b 8193 /dev/hda4


Went ahead and typed "fsck.ext2 -b 32768 /dev/hda4" to fix it. Works fine now but I see these errors in the Hyper Terminal:


..."Partition check:
hda:hda: set_geom(16383,16,63)
hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...•Ô•j½Õ¹Ñ•‘�ɽ½Ñ�¡•áÑÉ�™¥±•ÍåÍÑ•µ¥�É•…‘½¹±å¹)5 chan
ge_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initempeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
Mounting second music partition
Tried to mount /dev/hdc4 but got error 6
Error mounting partitions (possibly already mounted)
Remounting first music partition read-only
Remounting second music partition read-only
No secondary hard disk
Press 'q' now to go into development mode. You Have Zero Seconds To ComðStarting
player


Any thoughts?

The first yellow error is because it first tries to mount it as a reiser filesystem (journalling - inherited from some other product or if it was planned but not used)
It's benign as the player falls back and mounts it as an ext2 filesystem instead.

The second error is because you have only one drive. It always tries to mount the music partition of the second drive, even when it's not there - also benign.

/Michael

Oh well ok. Thanks.

But I am concerned about this happening a second time within such a short period of time and the fact that no one else seems to have this reoccuring problem. Perhaps it's time to contact support.