This is a Bad Idea(tm) if not done correctly. Had a customer with an epson printer decide to revert back to 10.3 until epson gets some drivers that work. Unfortunately, A&I fails to replace apps like Safari and Mail with versions that are compatible with 10.3, so you end up with a working OS and very few working (bundled) apps.

Apparently you have to delete all the bundled apps out of /Applications if you are needing to revert from 10.4 back to 10.3, so that the A&I will install new copies of the old versions of the apps.

ALSO, attempting a password reset on a machine that has had tiger installed on it results in about 15 "users" listed, most of which are users Tiger added for internal use only. We also had problems with accounts that had been deleted growing their home folders back after panther was reinstalled. (they came back on their own without the user logging in, and without the user showing up in the login list... very strange indeed!)

Apparently once you go with Tiger, going back to Panther is a bit rocky. Maybe this was a known or expected issue for some of you, but it came as a bit of a surprise to me.

Thanks for the warning V1; good advice. I'm going to move this over to the Tips & Hints forum in a bit where it wont get lost.

Your experience reinforces the necessity of having a Panther backup. Then, you can erase the Tiger drive and clone from the backup to return to the previous system.

Excellent info and points all around. Thanks. Let's hear it for clones on externals always. I have a pristine clone of my Tiger internal, a 10.3.9 clone, and another clone of my Tiger internal for experimentation with point updates.

can somebody send me a link or give me a walkthrough on how to clone panther to my external HD?

Probably best to download Carbon Copy Cloner first; it's operation is pretty straightforward - duplicate start up volume to selected disk. Prior to performing a clone, ensure your permissions have been repaired, hard drive is in good shape and directories are OK.

Disk Utility - Repair Permissions on start up volume
Start up from OS Panther CD and open Disk Utility - run Repair Disk
Directory repairs can be made with a program such as DiskWarrior

I'll add my two cents to Mississauga's advice. I have used Carbon Copy Cloner many times, always successfully by doing the following:

1. Run Disk Warrior and repair permissions on the source (original).
2. Clone with CCC.
3. Repeat step 1, but on the clone. Permissions can and do get mangled in the cloning process and sometimes there are some minor issues that DW fixes.

Would someone knowledgeable about cloning add explanations of:
-- when to check the "ignore permissions" box (GetInfo on an external drive while booted from the internal drive, or vice versa) and when NOT to check that box?
-- when to Repair Permissions on the boot drive working from the boot drive, vs
Repair Permissions on the internal/external while booted from the other, or from a CD?

This is one of those set theory problems with a LOT of combinations possible -- some recommended.

when to Repair Permissions on the boot drive working from the boot drive, vs
Repair Permissions on the internal/external while booted from the other, or from a CD?

When in doubt, repair permissions on the boot drive while working from the boot drive. Actually, it's fine if you do it from another volume as well. The only caveat, as of now, is to use the 10.3.9 version of Disk Utility to repair permissions on Tiger, not a previous version.

I can't answer the question about "ignore permissions" but I'm very interested in an expert opinion.

Selecting "ignore permissions" in a volume's Get Info window causes the system to treat every file and folder on that volume as owned by you. This is true for read AND write.

The write part might elicite a "well, DUH..." but this becomes important when using ditto (with root permission) to copy directories. If you attempt to clone a bootable OS X volume to another volume, and you accidentally have the ignore box checked on EITHER volume, the copy will result in every file on the desitination owned by your user id, which will render it unbootable. Basically, if ignore is checked on the destination, and you "sudo ditto" something to that volume, the files that are created will be set to be owned by you, not merely masquerading as yours while the box is checked. (I'd consider this a bug, but I think someone at Apple considers this "functioning normally")

I'd need several hands to count the number of times one of those checkboxes has torpedoed a volume duplication for me... They tend to (re)check themselves automagically after you format a drive, or when mounting a drive as a firewire volume. The scenario usually goes something like "ok, ready to copy, ignore is unchecked... oh, I need to wipe that first... (erase..) ok ditto away... (an hour later) oh, that sucks, it rechecked itself when I formatted... I get to do that all over again." So far I've only once done it back to back once. THAT had me upset. ("oh drat, I forgot to re-uncheck it... (uncheck) Oh ya, I need to reformat before I can reditto... (reformat) (dittto)... "ARRG!")

You can run a repair permissions on any volume containing mac os 10.1 or later. Being booted up on the drive at the time is OK. If you're booted into 10.1 you will need a stand-alone proggy downloaded from Apple, but for 10.2 and up you use Disk Utility. Don't run a version of Disk Utility that is an entire major version earlier than the volume you're going to be repairing. (example: don't boot up off a 10.3 CD to repair perms on a drive with 10.4 installed on it)

Oh, and mixing the two topics... if you have "ignore permissions" checked on the drive when you try to repair permissions on it, Disk Utility will go APE and try (in vain) to fix everything because the ownership of most of the files on the volume looks wrong. This is usually punctuated by seeing an instant and continuous flood of "fixed" messages scrolling rapidly through Disk Utility's progress window. Just cancel the check, get info, uncheck the ignore box, and go back into DU and re-run the repair. I don't know if this "bug" has been fixed for 10.4. (it really shouldn't allow you to run a repair whilst that box is checked)