Partition help!

I need some help. I'm looking for someone who is an expert on Linux partitions, and who's willing to sit on ICQ with me for a while and help me debug a problem I'm having.

Specifically, I need someone who knows all about they way the drives on the empeg are configured, and knows where all the partitions should be and how they should be mounted. Also, they need to be able to walk me through the commands I type at the bash prompt to determine if all the partitions are correct or not, and possibly help me effect repairs.

See, all the files on both drives of my player just disappeared, and I want to find out if it's my fault or not. I created that replacement init so I could run Picker and Displayserver, and I want to make sure that's not what caused it. Also, I want to see if there's a way to rescue the files I've lost.

I've already exchanged some e-mails with Mike about it, and he's just as stumped as I am. Besides, I don't want to take up any more of their time.

Anyway, my ICQ number is 1228275, whoever is up to it.

___________
Tony Fabris

I've had a little help from a couple of folks, and from the looks of it, my partitions are all where they're supposed to be, but the problem is that my Drive0 is blank all of a sudden. Drive1 is OK, but there were only a few songs on that drive.

It happened when Emplode was doing a disk-check operation on the drives during a synch. It was one of the "long" disk-checks. Yes, it was the alpha software, but I don't think that had anything to do with it.

It seems to me like something partially corrupted the music partition on drive0, then when I tried to re-install some .upgrade files and FSCK the disk a few times to try to fix it, those "repairs" somehow destroyed what was left of the file table on my music partition. I don't know how, though, and I'm not sure how to find out.

I'm going to try to get Midnight Commander running, and use it to carefully check the disk to see if it was a hardware problem. If not, I'm going to reformat the drives from scratch and reload all my music. I'm told that even if the Undelete function in Midnight Commander can find the files, it can't find the file NAMES, so it won't be able to magically make my partition come back.

Odd thing is, my EQ settings are all still there. Where are those stored? Wherever that is, it's still OK.

It's possible that I caused this to happen, although I'm not sure how. I added a second drive, and I had a custom init which seemed to work OK for a week before this happened.

Maybe I just have really bad luck with hard disks? I feel really embarassed that I put up a disk-replacement FAQ but I can't even keep my own disks in good health. Somebody please tell me that their disks are fine and it's not my fault and that I'm just unlucky?

___________
Tony Fabris

Now you've got me worried....

I haven't sync'ed my empeg lately, as I haven't loaded any new music, but
when I've played with the scroller, picker etc and rw/rwm'ed the disks, it
has complained about it being time for a fsck...

Oh well, I could do with a reorg of my songs - unfortunately they're no longer
on my desktop harddrive but on CDRs, so it'd be a fair bit of work.

/Michael

The EQ and playlists are stored on the scratch partition, and thats a partition only the player knows how to read. (Not sure the /dev/hda# off the top of my head, and my serial cable is at work).

I'll print out that attachment and show it to some of the Unix people around my cube area and see if they can tell what happened, and if it can be recovered. It really seems odd every fix fsck wanted to do was one number off in one direction or another.

The "off-by-one-ism" is caused by the missing lost+found -- fsck doesn't bother wiring it up correctly once it's put it back -- after all, it's going to be checking these things in a moment, anyway.

For your reference, the disk is (currently) partitioned like this:

1: extended partion, containing partitions 5 and 6.
2: free - not used for anything, atm.
3: dynamic data - EQ settings, etc.
4: music
----
5: root file system
6: swap.



Roger - not necessarily speaking for empeg

Now you've got me worried...

Don't worry, there's no reason to assume you're in any danger. No one else has reported this sort of problem.

Here's what I see as being the possibilities right now:

1) It was a 1.1 alpha bug. In which case, you don't need to worry at all as it'll be fixed before you get your hands on it. I doubt it had anything to do with 1.1 alpha, but if it turns out that it did, then I would feel REALLY embarassed about asking for help on the BBS.

2) It was a hardware problem with my disk drive which manifested itself in an unusual way. Nothing can be done to prevent that, and there's no reason to assume you'd be affected.

3) Something about my custom "picker" init mounted the drives wrong. Does anyone see any reason why that would cause this error when FSCKing? Note: my RWM fiddling caused emplode to do an FSCK on more than one occasion, and this didn't happen until just a couple of days ago. For reference, here is my custom init. Anyone see anything wrong with that?

4) I was running Displayserver. Perhaps it had a memory leak that caused FSCK to screw up? Unlikely, as there are many, many people running Displayserver and no one else has reported this problem.

I can just see the e-mail from Rob now: "Perhaps you should just run a default install of 1.1 while you're alpha testing." Hmm. Not a bad idea.


Oh well, I could do with a reorg of my songs - unfortunately they're no longer on my desktop harddrive but on CDRs, so it'd be a fair bit of work.

Fortunately, I keep all my songs on the desktop hard disk, too, so it's not a huge problem to reload my music. I've done it once before, it's not that big of a deal.

The only hard-to-replace things I lose when I reformat the hard disk are EQ settings (which I've just written down), and the track listings for some of my "mood" playlists. In the case of 1.1Alpha, I also happen to have lost my Wendy Filters, but you guys didn't hear me say that.

___________
Tony Fabris

Hmm, so I seem to have lost the data on partitions 1 and 4, but not 3. I wonder if that has any significance?

I don't think I actually lost the data right off the bat. The data was somehow corrupted and the player software would attempt to boot but then fail with a crash. It was then that I tried doing FSCK's and re-installing the .upgrade files, and I think THAT is when I lost the data on the partitions.

___________
Tony Fabris

I've just mailed Tony a probable solution to backup hist eq-settings :

command to backup:

dd if=/dev/hda3 of=/drive1/backupfile

- copy file /drive1/backupfile to your PC.
- repartition and format disk(s)
- copy file from PC back to /drive1/backupfile

command to restore after repartitioning and formatting :

dd if=/drive1/backupfile of=/dev/hda3

Would this be a feasable option?, or am I overseeing some kernel-thread monitoring/writing into this partition?

Frank van Gestel

Since right now I only have one main EQ preset that I care about, I've simply written it down.

This is very interesting information for posterity, though.

___________
Tony Fabris

1) It was a 1.1 alpha bug

Duh... Forgot about your playing with the alpha...
But I hope it isn't something in 1.1 that caused this - wouldn't want
any more delays there

2) It was a hardware problem with my disk drive

If this is the case then I must say that you've had some bad luck with
your disks

3) Something about my custom "picker" init mounted the drives wrong

Can't say that I can see anything in it that'd cause any problems...

4) I was running Displayserver.

Hmmmmm... did you ever experiece any lock ups or killed processes
during fsck'ing? Only case I can think of that could cause a problem
would be if the system ran out of memory totally and killed of the
fsck... Propably a good idea to stop Displayserver when fsck'ing

Hmmmmm... did you ever experiece any lock ups or killed processes during fsck'ing?

I don't know if there was a problem during the FSCK that seems to have caused it. Would loss of power during an FSCK cause something like this?

___________
Tony Fabris

Imagine the following scenario:

"General, we have to respond to a nuclear strike, NOW!!!!"

"OK, but are you sure we should FIRE..." (power cut)

Wwwwwwhhhhhhhhheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee


*splat*



One of the few remaining Mk1 owners... #00015

Well, I reformatted the drives, and swapped them (now the older, smaller drive is the slave and the larger, newer drive is the master). I couldn't figure out how to un-tar Midnight Commander on the hard disk, the tar command always locked when I tried to run it, so I still don't know if the drive that failed is having hardware trouble or not. Any suggestions on how to surface-test that drive without erasing it?

Good news is that I was just now able to upload 6+ gigs in a single shot without any problems. Niiiice.

___________
Tony Fabris

Would loss of power during an FSCK cause something like this?


I'm definately not sure, but it is (apart from hardware trouble) the only
thing that I can think of right now... But I would have thought that an
interrupted fsck would recover better than that on a second pass - but
fsck does have the power to make bad things to a file system...

BTW, my own fsck went without any problems at all.

/Michael

Would loss of power during an FSCK cause something like this?

If everything disappeared from the partition, this means the root directory of that partition got hosed. Power loss during fsck could well have caused this, especially if the fsck in question was busily repairing earlier damage.

Re-running fsck then rebuilt your root directory, and stuffed all your content in the "lost+found" directory (which works like Unattached Items -- in fact, it's where we got the idea).

However, this process loses all the filenames, and so there's no programmatic way to recover everything out of lost+found again. So the player must sadly then delete anything that turns up in lost+found.

This deleting stuff in lost+found, was new in 1.1 (previous releases would just leave stuff in lost+found, so unless you were a Unix weenie able to retrieve it all, you ended up with a load of disc space taken up by useless files). In the current alpha the deleting is actually too keen and deletes the lost+found directory itself, which is not the Right Thing (and possibly confuses fsck).

Apart from trying to use fsck as little as possible, there's not much we can do to guard against power loss during fsck.

Peter

Incidentally, after my complete re-format, I noticed that the name of the Unattached Items folder was "Lost+Found". I renamed it in emplode. Is this significant?

___________
Tony Fabris

Nah. The default name is stored in a couple of different places. They're not always consistent. It depends on who replaced the playlist - the player, or emplode.




Roger - not necessarily speaking for empeg

I doubt it had anything to do with 1.1 alpha, but if it turns out that it did, then I would feel REALLY embarassed about asking for help on the BBS.

Just as a follow up...

It turns out that I'm not the only 1.1 alpha tester who's experienced this problem, so I am now officially embarassed about asking for help on the BBS.

I'm not trying to air "dirty laundry" about the Alpha or anything, I just wanted to close the book on this thread. The loss of Drive0 was not hardware trouble, and there's no reason to believe that it was related to third-party software. So you don't need to worry: The Empeg folks are working on locating the problem, and you can rest assured that it'll be solved by the time 1.1 goes public.

Thank God for private alpha tests!

___________
Tony Fabris

you can rest assured that it'll be solved by the time 1.1 goes public.

I don't know, it adds a little excitement to life if there's a chance your sync could wipe your entire music partition..

Rob

Yeah, i definitely want a copy of the pre-fixed 1.1 so i can play some Russion-Roulette with my empeg! I need more excitement in my life.


|| loren.cox ||

No Roger, it depends which version of emplode created the playlist. The player never does it. emplode 1.0 calls it "Unattached Items" whereas emplode 1.1 calls it "lost+found". I suspect that emptool calls it "Unattached Items" too.

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

Doh! Looks that way...

    // Does the lost and found node exist?

    Node *lostNode = nodeStore->FindNodeByFid(FID_LOSTANDFOUND);

    if (lostNode == NULL)

    {

	LOG_INFO("There's no lost+found node.");



	NodeTags unattachedTags;

	unattachedTags.SetTag("type", "playlist");

	unattachedTags.SetTag("title", "lost+found");

	lostNode = CompoundNode::Create(nodeStore, FID_LOSTANDFOUND, unattachedTags);

    }

Roger - not necessarily speaking for empeg