Player received "Sigkill Error" on the screen during a synch. Emplode crashed. (don't know which of the two things above precipitated the other. I'm guessing it was sigkill->emplode.

After player reboot, it said No Hard Disk Found Contact Support.

I opened the player and fiddled with the cables. Maybe they just needed reseating.

Player boots fine now and the hard disk is detected. Player software is entered correctly and comes up at "End of Playlist" and it behaves as though it has lost its playlists and has lost its config.ini (no settings there).

Surfing its shell prompt with the serial connection, it seems to think it's got a hard disk, but there's nothing on the important parts (the music partition) and it refuses to list the /drive0 partition. It's behaving as though that partition got corrupted during that failed synch.

I tried a few of the bits in the FAQ including the fsck.ext2 -fay -b 32768 /dev/hda4 thing. It kept giving me strange errors.

Is there any chance I can recover this partition?

Full serial log file attached.

DON'T PANIC !

The music partition is /dev/hda5 not hda4.

-ml

Unless Tony's got custom partitioning, the music partition is definitely hda4.

The partition won't mount, that's why /drive0 is empty. The primary superblock is corrupt, and using the "-b NNNNN" option is the only way to bring the filesystem back.

The question is, what to use for NNNNN, i.e. where to look for the backup superblock. I suggest trying 24576, 24577, 98304, and 98305. (Those numbers are the first and second blocks in the third block group, for the common blocks-per-group values 8192 and 32768.)

Oh, and while you're there, we ought to check that your partition table is sane.

That is,
but stop, and report back here the first time any of those fscks does anything other than come back immediately with the "Bad magic number in super-block while trying to open /dev/hda4" error, don't carry on issuing the other fscks.

Peter

The filesystem appears to be present, but for some reason has a modern flag (eg. the "has journal (ext3)" flag) set on it.

Did you create this filesystem on a PC, in in the empeg?

Or perhaps this is simply more bit corruption in the superblock.

I just experimented here, and this works on one of my empegs:

e2fsck -b 32768 /dev/hda4

I'm reasonably sure it was the regular builder.

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

Well, whatever the name is then. Probably This:

fsck.ext2 -b 32768 /dev/hda4

But in Tony's original serial log, you can see him trying that: "Bad magic number in super-block while trying to open /dev/hda4". Our mission now has become either finding yet another backup superblock, or figuring out why fsck isn't finding the 32768 one where it thinks it should be.

Peter

Trying the commands you gave earlier in the thread, this one...



Seems to have hit something useful.



And now it seems to be taking a long time. Will report back with additional results when it gets past this bit.

That seems to have done something useful. I appear to have my partition back and my playlists back. Thank you so much, you guys.

I have updated the relevant FAQ entry. Let me know if my instructions there are correct.

Looks right to me. Your filesystem was formatted with 8192 blocks per group, which is certainly not the default in modern e2fsprogs for filesystems that big, but of course the builder images will be using a really, really old version.

Peter

Excellent.

I didn't do these commands in the procedure...

swapoff /swapfile
sync

Is that a problem?

The only potential problem would be leaving the swapfile in an inconsistent state for next time (assuming fsck syncs all its own changes, which it jolly well ought to do). If from the shell you do "swapon /swapfile" and then "swapoff /swapfile" and get no errors, everything is fine. And if everything were not fine, the worst that could happen is that you'd need to run mkswap.

Peter

Thanks!