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 (erik@vt.edu)

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.