Several problems all at once :-(

This all seemd to start at the weekend when my PC crashed during an upload. I now get these problems:

1) When powering up the Empeg it gets as far as "Building music databases", makes noises for a while as if it's doing something, but eventually the drives stop and it doesn't go any further. It's gone past that a couple of times, and will happily continue playing the playlist that was loaded before, but going down the menu to Playlists you find there aren't any.

2) When it's playing (as above) EmpegFace & CharcoalGrey's interfaces work fine, apart from the above-mentioned lack of playlists visible.

3) Emplode can see the Empeg and starts to connect, but gets to "Checking media" then says "Waiting" and then crashes.

4) And I can't find my damned serial cable at the moment !

Any ideas ??

Cheers,

Steve.

Any ideas ??

Find (or buy) a damned serial cable! You need to run fsck on the empeg, outside the player.

Agreed. The fact that you are getting a "building" instead of "loading" databases at boot means that your regular database file is corrupt or missing. You need to correct the disk problems, and that is only possible with the developer version and a terminal session.

OK, OK, found the serial cable, applied the developer image, it won't drop to the shell though. Tried booting up with just the 10Gb drive and it works OK - did as per the FAQ and I could see it in Emplode, re-sync, etc, etc.

However, if I boot up with both drives (reardless of which is drive 0), or with just the 40Gb, it whizzes straight past the point where I can get at the shell prompt and ends up stuck at the "Building music databases" screen. Pressing "q" at any point after this part:

"Remounting second music partition read-only
Press 'q' now to go into development mode. You Have Zero Seconds To Comply...
Starting player"

has no effect on the player. The developer image has now been applied independantly to both drives, but it seems to make no difference. When it's trying to start up I get lots of messages like

"Remounting filesystem read-only
EXT2-fs error (device ide0(3,4)): ext2_free_blocks: Freeing blocks not in datazone - block = 4185227054, count = 1"

If I can't get to the shell I'm a bit snookered, aren't I ?

Steve.

You can always press control-c during the boot cycle. That should drop you to shell. Then turn on swap (swapon /swapfile), unmount and check all of your filesystems (umount /drive0; umount /drive1; fsck -fay /; fsck -fay /dev/hda4; fsck -fay /dev/hdc4) and then reboot. You will still get that building databases the first time, but you should be able to go into shell normally then and correct it by hand.

Ahhh !!! Ctrl-C seems to have done the trick, things are happening, I'll report back in a minute :-D

Steve.

OK, so "a minute" turned into several hours. It got through the first FSCK fairly quickly (couple of hours), then gave a message about duplicate blocks and started again. I think it was blocks, this was quite some time ago now. Anyway, here we are, seven and a half hours after it started and it's *still* running. Is this normal ? It seems to be checking through inodes one by one and is currently up to about 260,000.

Steve.

That sounds rather ominous. Did you have any other trouble with the disks that would point to a bad cable or header? Do you have the music backed up (it might be easier / faster to rebuild the drive)?

It got through the first FSCK fairly quickly (couple of hours), then gave a message about duplicate blocks and started again.

This does not sound right. A couple of hours is not "fairly quickly" for a FSCK on typical empeg drives.

Please double check all the steps in the FAQ entry about the building music databases error, in particular paying attention to the part where it says to rule out disk drive hardware trouble because that might be the root cause.

Hi again - thanks for your help on this !

It seems to boot up and run fine if I only use the 10Gb drive, so I've removed that and put it somewhere safe for now. I hope that's not going to cause any problems.

Running from just the 40Gb drive, it *appears* to boot correctly but does not have any playlists available. Looking at the output in Hyperterminal (and bearing in mind I'm not really a computer person) it all seems reasonable apart from this bit:

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: ide0(3,4): couldn't mount because of unsupported optional features.
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

So it's booting up, but still can't find the drive ?? If worst comes to worst I can just rebuild the drive, but I don't have backups for quite a lot of music on there.

TIA,

Steve.

EXT2-fs: ide0(3,4): couldn't mount because of unsupported optional features

It appears to be finding the disk, because it seems to be reading the partition table. The error about No primary hard disk is misleading -- it probably refers to the fact that the partition couldn't be mounted.

As to why the partition couldn't be mounted, I don't know. This is starting to look like some serious corruption.

Can you post the entire boot log from Hyperterminal? Use the Transfer/Capture Text option. This option asks for a text file to save the incoming log as. Once you've given it a name, plug in the player.

Then post it here as an attachment (you might need to ZIP it first).

OK, here we go, file attached.

OK. It appears that the cables and so on are fine:

Probing primary interface...

hda: IC25N040ATCS04-0, ATA DISK drive

(repeats)

ide0 at 0x000-0x007,0x038 on irq 6

hda: IC25N040ATCS04-0, 38154MB w/1768kB Cache, CHS=4864/255/63

It also appears that your partition table is fine.

Partition check:

 hda: hda1 < hda5 hda6 > hda2 hda3 hda4

Your root filesystem is also OK:

VFS: Mounted root (ext2 filesystem) readonly.

Your music partition isn't:

EXT2-fs: ide0(3,4): couldn't mount because of unsupported optional features.

Tried to mount /dev/hda4 as ext2 but got error 22

Can you drop to a shell prompt on the player? Press Ctrl+C once the player's running.

Once you're there, can you run the following:

fdisk -l /dev/hda

(that's a small-L), and post the results?

empeg:/empeg/bin# fdisk -l /dev/hda



Disk /dev/hda: 255 heads, 63 sectors, 4864 cylinders

Units = cylinders of 16065 * 512 bytes



   Device Boot    Start       End    Blocks   Id  System

/dev/hda1             1         5     40131    5  Extended

/dev/hda2             6        10     40162+  83  Linux

/dev/hda3            11        13     24097+  10  OPUS

/dev/hda4            14      4864  38965657+  83  Linux

/dev/hda5             1         3     24034+  83  Linux

/dev/hda6             4         5     16033+  82  Linux swap

empeg:/empeg/bin#  

This is now waaaay over my head but the help is MUCH appreciated !!

Steve.

Well, that looks fine. That leaves us with corruption of the filesystem on the music partition.

Try running the fsck instructions from the FAQ again. If it seems to be taking a long time, then you've probably got irrepairable damage to the disk surface. At that point, we're looking at salvaging what we can.

Salvaging... If you have backups of all of your music and files, it might be easier to rebuild the drives.

I get the following, and I think it might be bad news....

empeg:/empeg/bin# ro

mount: /drive0 not mounted already, or bad option

empeg:/empeg/bin# umount /dev/hda4

umount: /dev/hda4: not found

empeg:/empeg/bin# swapon /swapfile

Adding Swap: 16028k swap-space (priority -1)

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: 1514/4096 files (0.5% non-contiguous), 9457/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.

fsck.ext2: Filesystem revision too high while trying to open /dev/hda4

The filesystem revision is apparently too high for this version of e2fsck.

(Or the filesystem superblock is corrupt)



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>

I don't have backups of a lot of the stuff here so it'd be nice to recover whatever I can, but it's not the end of the world if I lose it.

Steve.

Salvaging... If you have backups of all of your music and files, it might be easier to rebuild the drives.

sundayjumper already covered that:

If worst comes to worst I can just rebuild the drive, but I don't have backups for quite a lot of music on there.

Are you running the ext3 hack?

Edit - Roger: Sorry. I didn't see that. This should be salvageable, though.

That doesn't look good. Your superblock is corrupt. Does anyone know how to work out where the spares are put?

Can you run a mke2fs with the -n option, so that it doesn't actually do anything, but shows you what it would do and where it would place the superblocks???

Edit: From the manpage...

-n causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem. This can be used to determine the location of the backup superblocks for a particular filesystem, so long as the mke2fs parameters that were passed when the filesystem was originally created are used again. (With the -n option added, of course!)

Greetings!

Assuming you used the builder software to build the drive, the command that should have been run to generate the filesystem was: "mke2fs -m 0 -b 1024 -i 131072" according to Roger's manual build page. If you run the same command with a -n switch like this "mke2fs -n -m 0 -b 1024 -i 131072", it should theoretically show you exactly how the drive was built and where the superblock copies are without damaging anything. I am hoping someone who knows this (and is not just guessing and theorizing like I am) will confirm this.

After that, you should be able to take one of the other superblock copies that are displayed by the above command and run an "fsck -b <superblocknumber> -fay /dev/hda4" to use the alternative superblock.

will confirm this

Sounds fair to me. It certainly can't make anything worse (as long as that -n is included!).

I'm sure that an alternative superblock has helped someone before and may be somewhere in the archives...

<Me goes to practice Search-Fu>

Yep. An alternative superblock is at 32768

Incidentally, even if _all_ the superblocks were corrupt, you could still attempt to reinitialise them without formatting the rest of the partition by giving the -S flag to mke2fs. I don't know what sequence of events could cause all the superblocks to corrupt without the data corrupting though.

Sounds fair to me. It certainly can't make anything worse (as long as that -n is included!).

I've a nasty feeling that -n hadn't been invented in the (now very, very, very old) e2fsprogs release that car-players had installed.

Peter

It should just error out with a bad parameter, though. Right?

Hi,

Back again. This looks good, but can somebody translate into plain English please ? :-)

Do I just need to run Paul's "fsck -b <superblocknumber> -fay /dev/hda4" using the 32768 figure that genixia provided ?

Many thanks,

Steve.

Hahahaha. Sorry about that. We were just looking for a way to find out how to learn where the duplicate copies of the superblock were and what to use.

Yes. You should be able to run that command directly.

"fsck -b 32768 -fay /dev/hda4"

Yep.

Oh.....

empeg:/empeg/bin# ro

mount: /drive0 not mounted already, or bad option



empeg:/empeg/bin# umount /dev/hda4

umount: /dev/hda4: not found



empeg:/empeg/bin# swapon /swapfile

Adding Swap: 16028k swap-space (priority -1)



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: 1514/4096 files (0.5% non-contiguous), 9457/16384 blocks



empeg:/empeg/bin# fsck -b 32768 -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.

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>

No good ?

Steve.

No good ?

No, not good. Try each of these alternate numbers:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

These are from the new recommended format scheme, though; the scheme used by the builder might not have put the superblocks in the same place.

Still no good. Every time, I get:

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>

Steve.

Doubleplusungood.

I think it's time for mke2fs with the -S flag as a last ditch effort. Roger, will mke2fs -S /dev/hda4 do it or does he need other flags?

Before the -S, it might be worth it to try the dry run -n. It might be that the superblocks from the default builder are in different locations.

So a "mke2fs -n -m 0 -b 1024 -i 131072" ?

FWIW I'm now not too worried about losing the stuff on there, a lot of it was badly ripped anyway !

Steve.

Yes. You might want to capture this to a log file and post the results here.

Looks like it doesn't recognise the -n flag:

empeg:/empeg/bin# mke2fs -n -m 0 -b 1024 -i 131072



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

Usage: mke2fs [-c|-t|-l filename] [-b block-size] [-f fragment-size]

        [-i bytes-per-inode]  [-N number-of-inodes]

        [-m reserved-blocks-percentage] [-o creator-os] [-g blocks-per-group]

        [-L volume-label] [-M last-mounted-directory] [-O feature[,...]]

        [-r fs-revision] [-R raid_opts] [-s sparse-super-flag]

        [-qvSV] device [blocks-count]

Steve.

Worth a shot. Given that there does not appear to be a non-destructive way to find superblock locations, I do not know what else to tell you. It might be time for that -S switch.

Does anyone else have any ideas???

Does anyone else have any ideas?

Might be worth trying a newer version of fsck. There is a more recent version on my ext3 page.

Just grab the e2fsck binary and ftp it to your player and then follow step 1 (and only step 1) on that page. Then try the fsck again.

-Mike

OK, I tried doing mcomb's suggestion, but I'm not quite sure what happened. I then did the -s whatsit and got this:

empeg:/empeg/bin# mke2fs -S /dev/hda4

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

Filesystem label=

OS type: Linux

Block size=4096 (log=2)

Fragment size=4096 (log=2)

4872896 inodes, 9741414 blocks

487070 blocks (5.00%) reserved for the super user

First data block=0

298 block groups

32768 blocks per group, 32768 fragments per group

16352 inodes per group

Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

        4096000, 7962624

Those last two numbers are new, so I tried the fsck command again with the first of the new numbers but get

fsck: fsck.ext2: not found

I think I've screwed something up.

Steve.

No, I think that error is because you copied the new fsck across.

Can you do ls -l /sbin/e2* and ls -l /sbin/fsck*

empeg:/empeg/bin# ls -l /sbin/e2* and ls -l /sbin/fsck*

ls: and: No such file or directory

ls: ls: No such file or directory

lrwxrwxrwx    1 0        0              11 Jun 10 17:24 /sbin/e2fsck -> /bin/e2f

sck

lrwxrwxrwx    1 0        0              16 Jun 10 17:25 /sbin/e2fsck.ext2 -> /bi

n/e2fsck.ext2

-rwxr-xr-x    1 0        0           66301 Apr  1  2003 /sbin/fsck

lrwxrwxrwx    1 0        0              11 Jun 10 16:40 /sbin/fsck.ext2 -> /bin/

e2fsck

So what's that doing ?

Steve.

Checking what is where...

ls -l /bin/e2*
ls -l /bin/fsck*


Note the path change, bin not sbin this time.

empeg:/empeg/bin# ls -l /bin/e2*

lrwxrwxrwx    1 0        0              11 Jun 10 17:24 /bin/e2fsck -> /bin/e2fsck

lrwxrwxrwx    1 0        0              16 Jun 10 17:25 /bin/e2fsck.ext2 -> /bin/e2fsck.ext2



empeg:/empeg/bin# ls -l /bin/fsck*

-rwxr-xr-x    1 0        0           66301 Apr  1  2003 /bin/fsck

lrwxrwxrwx    1 0        0              11 Jun 10 16:40 /bin/fsck.ext2 -> /bin/e2fsck

There's your problem. Somehow in putting the newer e2fsck tools on the player something got screwed up.

fsck is trying to call fsck.ext2 which symlinks to /bin/e2fsck which in turn symlinks to ... itself. You're missing the e2fsck binary.

Erk. I knew I shouldn't have got up this week. I'm in way over my head now so I think I'll cut my losses and rebuild the drive.

Many thanks to everyone for the help :-)

Steve.