Pumped fine/came back up... upon sync:
"sync process failed during stage 2 with error 0xffffffff8"
??
-mark

...proud to have one of the first Mark I units

Odd, I just did a few serial synchs with 9a and they worked fine. I haven't tried any USB synchs with 9a (not at a usb computer right now), but I was able to synch fine with the last test build before 9a via USB.

Does your synch error only happen on USB or can you get a synch to work with serial? Also, does the synch error happen after a long time or immediately?


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

...I'm pretty sure the upgrade took my music partition with it:( trying to manually mount /dev/hda4 results in..well..nothing..take a look:

empeg:/sbin# ./fsck.ext2 /dev/hda4
e2fsck 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09
Couldn't find ext2 superblock, 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

empeg:/sbin#

(and)
empeg:/etc# mount /dev/hda4 /drive0 -t ext2 -n
VFS: Can't find an ext2 filesystem on dev ide0(3,4).
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems

Likewise, mount /drive0 gives:

empeg:/etc# mount -n /drive0
VFS: Can't find an ext2 filesystem on dev ide0(3,4).
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems
empeg:/etc#


Any ideas? Is there an alternative "superblock" that I can try?
:-( mark

...proud to have one of the first Mark I units

Yikes, you're out of my league. I know nothing about Linux. The only thing I know is that the upgrades are not supposed to harm the music partition, they're only supposed to touch the operating system partition.

Have you tried going back to 8c to see if that fixes the problem?


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

yes, no luck w/ 8c:(

...proud to have one of the first Mark I units

Strange - have you repartitioned your hda at any time in the past? 8c and above (maybe earlier, I can't remember exactly) repartition the disk on startup as there was a new swap partition scheme from that point.

What does the kernel say when it ID's the disk in the boot sequence?

Hugo

The drive has been repartitioned; however, upgrading from 8b to 8c didn't cause any problems; just the latest jump to 9a... Actually when I was playing around w/ fdisk a minute ago, it did complain about the partitions "overlapping" - is it possible that the new swap partition over-wrote my music partition? If so, is my only option to repartition/reload?:(

-mark

...proud to have one of the first Mark I units

A couple of follow-up questions (sigh...)

1) is there a way to save the music/databases on the /drive1? This doesn't automatically load, however doing a manual mount loads this partition... Much of music is irreplacable - so it'd be nice to be able to save the existing files...

2) if it becomes necessary to repartition, what're the proper steps to doing it so that emplode stays happy?
-mark



...proud to have one of the first Mark I units

Well, I just got a synch fail with consumer 9a, too. I had done a successful upload and then a successful delete using serial on my machine at work. Then I took it home, plugged it in with USB, and did a successful upload. The only thing I noticed during the upload was that it spent an unusual amount of time on "Checking disk integrity". But it worked OK after the upload, so I thought all was well. Then I deleted the file I uploaded and tried another synch. It gave me a failure on stage 6 with error 0xFFFFFF92.

After that error, my unit continued to play OK as far as I could tell, although it did the usual pause during boot up when it says "building music databases".

The next time I ran Emplode, it again spent an unusual amount of time on "checking disk integrity" before it downloaded the songs, but now it seems as though it has fixed itself and all is fine. I'm not sure if I should try any more synchs, though.

Mike, if you're reading this, I didn't have that problems with the last interim test build you sent me before 9a. Do you have any suggestions as to what I should check or test? Is it a fluke for me or is it related to the other problem reported on this thread?



-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

Much of music is irreplacable - so it'd be nice to be able to save the existing files...

Oh really?



-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

...if you MUST know...

Part of my music collection is irreplacable because it was STOLEN
and the rest of it is too scratched... most the music i have is copies from friends...

...proud to have one of the first Mark I units

I was just kidding anyway.

I understand your position: I, too, have MP3s of a few albums that were stolen the last time my car got ripped off. I never replaced them because I knew I was getting an Empeg eventually, and would no longer care about the original CDs.

I also have a couple albums where the original album skips, but my ripping software's jitter correction feature has repaired the tracks so that they don't skip when I play them back in MP3 format.

I have gone to the extra trouble of reserving hard disk space on my PC that is the same size as the Empeg, so that if the Empeg goes south, I still have all the MP3s and can re-upload them if necessary. I understand that's not realistic for most folks, though.

I hope you and the Empeg folks can get to the bottom of the problem with the partitions and you can recover your files.


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

...I think I might just put my unit up on Ebay and wait for the mark II if the good folks at Empeg can't help me recover my files... If i need to reload anyways, I can wait a couple of months:(
-mark
(empeg - PLEASE help me save my music:) )

...proud to have one of the first Mark I units

Hmmm - the partitioning changes to 9a don't affect the position of hda4 - the basic partition format that empegs were originally shipped with is:

hda1 - 32mb (with a swapfile as a file in the partition)
hda2 - 32mb
hda3 - 16mb
hda4 - rest of disk

This got updated in beta8c to:

hda1 - container (32mb)
hda5 - root (24mb)
hda6 - swap (8mb)
hda2 - 32mb
hda3 - 16mb
hda4 - rest of disk

I *think* 9a made hda5 16Mb and hda6 16Mb. However, these both still add to 32Mb and so none of the other partitions moved. Also, the only partition "pumped" with new data is hda5, which is 64mb away from your music on the disk - a safe margin :)

This has been quite extensively tested and we're not aware of any problems on disks that havn't been fdisk'ed by the user. What did you do when fdisking?

A (long winded, but possible) way to try and find hda4 is to use fdisk to alter the start cylinder of the partition, one at a time (try going up maybe 8 and down 8 or so, one by one) then rebooting and seeing if the music gets mounted. The partition table is stored at the start of the disk. Obviously, don't write to hda4 and ideally don't run the player, which writes to hda3 (it only writes to the start of hda3, so there should be no overlap, but to be on the safe side....). When you find it, back up your data (to the second drive?), reinstall beta9a, then copy it back.

Hugo

Thanks Hugo, I will have to play around with it when I have more time:(

Could I ask someone for a favor? is it possible to compile this program for the empeg?
-mark
ftp://bmrc.berkeley.edu/pub/linux/rescue/fixdisktable-0.3.tar.gz

...proud to have one of the first Mark I units

Hey Hugo,

Took your advise and FOUND my music partition.. actually it's wierd.. i ended up deleting the partition , and re-creating it using the different parameters; no luck.. re-recreated it using the SAME values that didn't previously work and it worked...

So here's my question now, how can I upgrade to 9a without again losing my partition? Should I just try to upgrade to 9a again and see what happens?
-mark


...proud to have one of the first Mark I units

OK - upgrading to 9a resulted in the same thing: a failed partition. I think this is mainly because of how this drive has been treated; this drive has been upgraded from the original drive to a new drive, and the PC software symantec ghost was used in the upgrade to transfer the partitions, resulting in partitions that were slightly different then what emplode was expecting..

So now I've finally got beta 9a working, and here's what I had to do:

a) upgrade to 9a
b) delete partition 4
c) recreate partition 4 using start cyl. 15 instead of 14..

...So now I'm up and running..My question is though - will the partitions be changed again in a future software revision? Thanks for all your help,
-mark


...proud to have one of the first Mark I units

One last question:

Can I get away with copying all the files under /drive0 to /drive1? (There's just enough space for this...) if so, what're the proper steps, just everything under the /drive0/fids directory? my reasoning is, after doing this I can just re-partition the /drive0 the way that emplode wants it to be, and new songs will just fill up /drive0 from this point on... Let me know if you have any suggestions on this.
-mark


...proud to have one of the first Mark I units

Can I get away with copying all the files under /drive0 to /drive1? (There's just enough space for this...) if so, what're the proper steps, just everything under the /drive0/fids directory? my reasoning is, after doing this I can just re-partition the /drive0 the way that emplode wants it to be, and new songs will just fill up /drive0 from this point on... Let me know if you have any suggestions on this.

That should work. If /drive1 is the original disk as shipped then you could just swap the disks over. We currently don't, and have no plans to write to the partition table of the second disk.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)