I'll be attempting to clone a unit soon and wonder if beta 8 will support this or if I'll still need to downgrade everything to 1.03.

You have a number of alternatives already... JEmplode, on linux via FTP using mirrordir... Doing the copy thing manually using ftp...

Look in the programming section because there have been recent threads with that type of discussion.

Bruno

For Linux-challenged (and empy-100GB-disk-deprived) users (who thus cannot use mirrordir or simply FTP everything in one gulp), if they want to avoid a simple exercise of writing a script that would FTP fid files one by one, I recommend recently mentioned Lazy Bastard's Guide to Cloning your empeg by Roger. It might look intimidating for penguin-phobes, but it is dead-simple to follow literally even if one doesn't understand a single command (and those who do think "why didn't I think of this").

Clone tool and Jemplode are still only point-and-click solutions, but Roger's solution is so elegant and fast (it transfers directly empeg-to-empeg, cutting total traffic in half and avoiding emplode protocol overhead) that I still prefer it over them.

The guide does not cover cloning of partition containing EQ settings, play counts etc.

I think this should be FAQed (don't blast me too hard if it already is, FAQ gets improved faster that I can follow )

Thanks Bonzi. I certainly do meet the user qualifications. Sounds like I need Linux or cygwin to be on my PC. Right?

I'm not sure this is any eaiser than using jemplode, though the transfer process sounds like it could be a lot faster.

Barry

FYI, MirrorDir does 1 file at a time, so you only need as much free space as the largest file you have.

The only downside to Roger's method is that it can't be used to 'keep' two empegs in sync without completely re-cloning. Mirrordir can incrementally copy over just the 'new' files. It does kinda need Linux to work well though - there doesn't appear to be a windows port. Although it *might* work in Cygwin, I haven't tested that.

So it appears that the only reason for using a Linux computer outside the empeg is for extracting the netcal program to upload to your 2 empeg units.

Can someone email the netcat_1.10-12.1.tar.gz file that needs to be extracted? I don't have a Linux machine handy to accomplish this process.

The other question is tar-ing the files to send to the new unit. If I do that, don't I also have to untar on the receiving unit? I don't see that mentioned in the Lazy Bastard guide...

Lastly, has anyone gone through the whole process and made it work? At the end of the web page it says "...hopefully a properly cloned player."

- Thanx
- Jon

So it appears that the only reason for using a Linux computer outside the empeg is for extracting the netcal program to upload to your 2 empeg units.

Yep. I'll put the binaries up on my webpage in a minute...

If I do that, don't I also have to untar on the receiving unit? I don't see that mentioned in the Lazy Bastard guide...

It definitely mentions 'tar' in both stanzas. One of them before the pipe, one after.

Lastly, has anyone gone through the whole process and made it work?

Yep. Me. Worked a treat. I'll go update the page now.

Edit: Updated the page. Included the binaries.

Hm. I don't see any mention of untarring... How does it get untarred on the destination?

I have a 40 gig on my source empeg. It's 90% full... Would the process still work even if I don't have enough room to put the whole drive into a tar file?

- Jon

In reply to:

---

Would the process still work even if I don't have enough room to put the whole drive into a tar file?

---

Yes - you're not making a file; you're sending the output straight to the tar process on the other player.

How does it get untarred on the destination?

dest-empeg:/drive0# nc -l -p 2999 | tar xvfz -

Sets up netcat in listening mode on the destination empeg, and anything it gets is sent through tar for extraction.

The tar file is not stored _anywhere_. It's sent straight over the wire.

Hm. Having a problem untarring the .gz file...

empeg:/# ls -al
total 56
drwxr-xr-x 15 502 220 1024 Feb 4 10:26 .
drwxr-xr-x 15 502 220 1024 Feb 4 10:26 ..
drwxr-xr-x 2 0 0 1024 Dec 22 10:11 bin
drwxr-xr-x 2 0 0 1024 Jul 4 2000 dev
drwxr-xr-x 5 0 0 1024 Aug 23 2000 drive0
drwxr-xr-x 5 0 0 1024 Aug 23 2000 drive1
drwxr-xr-x 4 0 0 1024 Dec 22 10:17 empeg
drwxr-xr-x 3 0 0 1024 Sep 15 1999 etc
drwxr-xr-x 2 0 0 1024 Feb 9 2000 lib
drwxr-xr-x 2 0 0 12288 Dec 22 10:17 lost+found
drwxr-xr-x 2 0 0 1024 Jun 2 1999 mnt
-rw------- 1 0 0 30720 Feb 1 17:54 netcat_1.10-12.1-minimal
.tar.gz
dr-xr-xr-x 17 0 0 0 Feb 4 09:59 proc
lrwxrwxrwx 1 0 0 3 Dec 22 10:17 sbin -> bin
lrwxrwxrwx 1 0 0 10 Dec 22 10:17 swapfile -> ./dev/hda6
drwxr-xr-x 2 0 0 1024 Apr 13 1999 tmp
drwxr-xr-x 4 0 0 1024 Feb 6 2000 usr
drwxr-xr-x 3 0 0 1024 Aug 28 1999 var
empeg:/#
empeg:/# rw
empeg:/# tar xvfz drive0/netcat_1.10-12.1-minimal.tar.gz
tar (child): drive0/netcat_1.10-12.1-minimal.tar.gz: Cannot open: No such file o
r directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors
empeg:/#

I set the empeg as rw, sent the .gz file to the root, ran the tar command, and got the above error... What am I doing wrong?

- Jon

The tar file is in /, but you're asking tar to deal with a file in /drive0. You probably want to mv it to /drive0

Ok, so I tried it this way:

empeg:/# tar xvfz ./netcat_1.10-12.1-minimal.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error exit delayed from previous errors
empeg:/#

Hm. You think the file might be corrupted?

- Jon

Possibly, but first try it without the `z' in the flags for tar. Your browser may have ``conveniently'' un-gzipped it but left the filename the same.

Yeah, IE does that sometimes. It could be down to the server configuration, though. Which is embarrassing, since it's my server. I'll take a look when I get a chance.

It probably is. I think that Apache (or the default config, more likely), is broken in that respect. It tends to send things ending in .gz with an Encoding-Type (or something like that) of gzip (or whatever), and IE is actually doing the right thing.

Oops, I forgot that 'ar' is not a part of empeg minimal version of Debian. I see Roger took care of that, though.

If you *do* make mirrordir work on cygwin (or otherwise under Windows), please let us know!

Roger, perhaps you could also put directions for cloning the partition with EQ setings, play counts and other transient data (if that is safe) on your 'Lazy bastard's...' page. I suppose dd piped to netcat will do, but I would prefer a word from the authority

>MirrorDir does 1 file at a time, so you only need
>as much free space as the largest file you have.

Nope, not even that much.. mirrordir just relays the packets
from one unit to the other, using memory as a buffer.

Cheers

dd should work, I dd'ed my /dev/hda2 to a file on my old unit, and dd'ed it back on the new unit after FTPing the file over. Worked quite well.