Special Report: Troubleshooting Mac OS X 10.3 (Panther)
Special Report: Troubleshooting Mac OS X 10.3 (Panther)
- Upgrade Procedure Recommendations
- The FireWire debacle
- The dangers of case-sensitive HFS+
- Problems with installation: Stuck on Disc 2; bad discs; disconnecting devices
- Virtual memory use
- Panther access changes go to far?
- FileVault and losing data
- Fixing Scanner Problems
- Screen calibration issues
- Fixing fax problems
- Compatibility: Quicken; DiskWarrior; StuffIt; Virtual PC; g4port; CopyPaste; PhotoPaint; Palm; more
- Solving printer problems
- Graphics card problems; solutions
- Music and Audio issues compilation
- Wake-from-sleep issues
- Fast User Switching fixes
- "Where is It?" questions
- Macromedia applications and authorization
- Misc. Issues: Login problems; Registration; Firewall issues; more
- New networking scheme confusing for some users
- Slow Photoshop launch times
{mfi-specialreport-top}
Upgrade Procedure Recommendations
First, keep in mind that Panther is a major upgrade to Mac OS X, with significant changes to both the visible feature set and the underlying code. As such, many third-party utilities and applications -- especially system add-ons -- will need to be updated by their developers to ensure compatibility. Be sure to check with the developers of your frequently used software to ensure that you have Panther-compatible versions. If you have third-party system add-ons -- preference panes, menu utilities, contextual menu plug-ins, Services, etc. -- that are not compatible with Panther, be sure to disable them by removing them from the appropriate folder inside /Library or ~/Library. Likewise, if a particular application isn't compatible, be sure to remove it from your Login Items preferences, if applicable, so that it doesn't launch at login. If you're not sure about specific software titles or add-ons, disable them until after the upgrade, and then try enabling them one at a time to test them for compatibility.
Second, although you should be backing up important data regularly anyway, it's especially important to back up such data, or even your entire hard drive, before undertaking any kind of major system upgrade. If for some reason you encounter serious problems, it's a lot easier to simply restore your system from backup than to try to rebuild it from scratch.
Finally, if you want to avoid many problems, be a conscientious upgrader; although there are always going to be issues with updates and upgrades, many of the reports we receive at MacFixIt after minor or major system updates cover issues that are actually problems with the user's own system. For example, minor disk and/or permissions corruption can prevent an update from installing properly, and sometimes changes from an update can reveal existing issues that were previously unidentified. By taking a few precautions -- such as making sure your hard drive is in good shape -- you can often avoid many of these issues.
Below is a set of procedures we recommend. Although it would be nice if there were no "maintenance" needed when installing an update, our experience is that such maintenance can, and does, make the update process go more smoothly, and in fact has allowed us to avoid many minor problems. To be fair, these procedures will take a bit of time; however, they take less time than dealing with some of the issues they can help you avoid.
-
1. Before installing Panther, check your startup drive for damage, and repair it if necessary. The easiest way to do this is to boot from the OS X Install CD and run Disk Utility (from the Installer menu). Click the First Aid tab, select your hard drive in the drive/volume list, and click "Repair Disk." (If you know how, you can instead start your Mac in single-user mode and use fsck, as this runs the same repair routines.) If you have a third-party disk utility such as Alsoft's DiskWarrior, you can also run that for good measure.
2. Before installing Panther, boot from your hard drive again and repair permissions on your boot volume. To do this, launch Disk Utility (located in /Applications/Utilities), click the First Aid tab, select your hard drive in the drive/volume list, and then click "Repair Disk Permissions." (It's important that you do this while booted from your hard drive, rather than from the OS X install CD or another volume, in order to perform the "correct" repairs.)
3. Install Panther. (See the tip below, "More info for Panther upgraders," for more information about installation options.)
4. After installing Panther and then booting from your hard drive (you should now be starting up into Panther!), again repair permissions via Disk Utility as described in Step 2. This will ensure that any system-level permissions that may have been corrupted or changed incorrectly -- installers are notorious for this -- are reset to the correct values.
By following the above procedures, you're not assured a problem-free upgrade, but you'll certainly have a "healthier" installation, which may help you avoid many of the issues that befall haphazard upgraders.
More info for Panther upgraders The publishers of the well-known Mac newsletter TidBITS have announced a new ebook, Take Control of Upgrading to Panther, by Joe Kissell, that provides a much more comprehensive look at upgrading to Panther, including a discussion of the many different options offered by the Panther installer.
Apple also has a Knowledge Base article that focuses on troubleshooting software updates and installations.
{mfi-specialreport-box}
The problems caused with FireWire among Mac OS X 10.3 upgraders have resulted in loss of critical data, the inability to mount drives, intensive investigation by drive manufacturers, and a second look at the reliability and robustness of FireWire as a storage standard. Apple's official maintains that the "identified" issue involves "external FireWire hard drives using the Oxford 922 bridge chip-set with firmware version 1.02." However, the statement now includes the following paragraph:"Update 11/4/2003: Apple and Oxford Semiconductor have confirmed that firmware version 1.05 resolves the data loss issue experienced by some FW800 users. FireWire disk drive manufacturers have begun posting firmware updates. [list of updaters below] Only use the updater provided by the maker of your drive and follow the installation instructions carefully. If your drive manufacturer is not listed, contact them for more information."
List of manufacturers providing firmware updates As part of the above web page, Apple has listed the following drive manufacturers as those who have provided firmware updates for affected drives:
- Century Global
Club Mac Ezquest
Firewire Depot
Firewire Direct
Glyph
Lacie
Macpower
Other World Computing
TransIntl
Wiebetech
Comments and information from LaCie On Wednesday, we spoke with LaCie representative Mike Mihalik about the FireWire issue. LaCie's drives are among those affected by Apple's "official" bug (Panther/FireWire 800/Oxford 922 chipset), and LaCie was among the first vendors to provide a firmware upgrade for those drives. During our conversation, Mike provided a good deal of helpful and interesting information about the current FireWire issues.
- FireWire 800 vs. FireWire 400 drives We have previously expressed concerns, based on numerous reports of problems with FireWire 400 drives and Panther, that this issue may not be restricted to FireWire 800/Oxford 922 drives (or, at the very least, that a different issue is affecting some FireWire 400 drives). We also reported on a claim by Oxford Semiconductor that it would be "impossible" for this official bug to affect Oxford 911 chipsets. LaCie confirms Oxford's position, stating that the circumstances and technical details surrounding the bug that Apple has acknowledged relate to specific ways in which FireWire 800/Oxford 922 drives communicate with the operating system. In other words, since FireWire 400 drives, and drives using the Oxford 911 chipset, don't communicate with connected computers in exactly the same manner as FireWire 800/Oxford 922 drives, this particular bug cannot affect them.
This does not rule out the possibility that there may be issues affecting other drives. However, it means that if other drives are indeed having problems with Panther, they are having problems for different reasons.
- Technical background Whenever a drive is used by a computer, it communicates its current state (reading, writing, sleeping, etc.) to the computer, and the computer likewise communicates with the drive (telling it to read or write data, spin down, eject, etc.). Evidently, when this bug strikes, it is caused by the communication timing between the drive and the computer, particularly when the operating system tells the drive to "eject." The drive executes its unmount/eject procedure, but the OS may not be "listening" when the drive reports its status. The result is a miscommunication that results in incorrect data being written to the drive.
In terms of what is happening to the drive itself, it appears as though the blocks at the beginning of the drive are being overwritten by a string of zeros. This can have a number of effects. First, if your drive is fairly new and/or larger, the volume directory will often be contained in a contiguous span of blocks at the beginning of the drive, and most files will be stored contiguously elsewhere. In this scenario, the overwriting of zeros at the beginning of the drive means the directory will be lost, but your data may be untouched. This is why many users are having success using Prosoft's Data Rescue X to recover their data, as covered in yesterday's report. On the other hand, when a drive is smaller and well used, files, folders, and directory information are fragmented across the drive. In these situations, only part of the drive directory will be damaged, but you may find that portions of your data are also unrecoverable. Finally, if you've ever partitioned your drive, the drive's partition map is also located at the beginning of the drive, so it will most likely be destroyed, meaning that the drive will no longer appear to be partitioned. However, there is an upside to this situation: since both the data and the volume directories for partitions besides for the first one are stored away from the beginning of the drive, they should remain intact, so utilities like Data Rescue may actually be more successful in recovering data off of those partitions than if the drive consisted of a single partition.
One interesting note: we have previously discussed the FireWire 400 drive lost by a MacFixIt editor, which was eventually sent to DriveSavers for successful data recovery. Since DriveSavers returns drives in exactly the state in which they received them -- they recover data to other media and return the bad drive untouched -- we installed the drive in a Mac running OS 9 and ran Sedit, a block-level drive editor, to view the drive's blocks. We found that the beginning of the drive had been overwritten with zeros.
- Why different drives behave differently One thing that is clear about FireWire drive problems is that not everyone is affected, and when people are affected, they aren't necessarily affected in the exact same way. For example, just because a particular drive uses the Oxford 922 chipset doesn't mean it will fall victim to (or avoid) the same problem as another drive using the same chipset. The reason for this is that the chipset is just part of the drive's FireWire interface. The entire interface consists of the bridge design (which converts the connection type provided by the drive -- IDE, for example -- to FireWire), the FireWire chipset itself, and the firmware currently in use by the chipset. Different vendors use different combinations of bridge design, chipset, and firmware, so without knowing each particular part of this interface, there's no way to predict how a drive will react to potential FireWire issues. In fact, even two drives using the same chipset and chipset firmware might behave differently, because the hardware itself may be slightly different. (This also makes testing for such issues fairly difficult because of the myriad combinations that are possible.)
On the other hand, because LaCie knows the specific interface combinations used in all their drives, and they also know exactly what sequences of commands are causing this issue, they are confident in saying that their FireWire 400 drives, and their FireWire 800 drives that have been updated using the firmware updaters they have provided, cannot be affected by this issue.
- Using firmware updates on unsupported drives A number of MacFixIt readers have reported success in using a firmware updater from LaCie or another vendor to update the firmware on a drive not manufactured by that vendor. Mike warned against taking this action, for the same reasons that drives often behave differently: there's no guarantee that the two drives have the same bridge/chipset/design combination, so you have no way of knowing if the firmware updater will fix the problem, make it worse, or possibly even damage the drive. For example, when LaCie provides a firmware updater, that updater is written for, and tested on, LaCie drives only. Using it on other vendor's drives may provide unexpected results. (In fact, the most recent LaCie firmware updaters will only work on LaCie drives, in order to prevent such potential problems.)
- In-house experiences Interestingly enough, LaCie engineers haven't had a single failure while testing drives for this bug under normal circumstances, even when testing the specific combination of factors that have been implicated by Apple. They know exactly what sequence of commands triggers the failure, and have been able to "fail" a drive by issuing those commands via special drive-level instructions, but they haven't actually had a drive fail during normal use. This further supports the assertion that although the issue has been isolated, it's not necessarily repeatable or guaranteed to occur.
We want to thank Mike for taking the time to speak with us; we're sure MacFixIt readers will find this information both interesting and useful.
Old QPS statement As an interesting side note related to an issue we brought up yesterday -- that users have reported problems with OS X and FireWire drives for some time -- MacFixIt reader Richard Bastiaans directed us to a two-year-old statement on the QPS site regarding the use of Que FireWire hard drives with OS X:
Can I use my QUE firewire hard drive drive on OS X?
We do not yet support these drives on OS X because there are still some communication issues with the operating system. However, many of our customers are using the drive without problems on OS 10.1.3. If you are going to use the drive on 10.1.3, then format the drive using the disc utility in OS X.
MacFixIt Recommendations We've previously provided a few recommendations for dealing with, and avoiding, these issues until we can conclude it's "safe" to use FireWire drives normally. Below is a summary of those recommendations.
Recovery discounts Both Prosoft and DriveSavers have offered MacFixIt readers discounts on their products and services. Prosoft is offering $10 off of the purchase of Data Rescue X by ordering directly from Prosoft and entering coupon code PAN911 at checkout. DriveSavers is offering a 20% discount on their data recovery services for those users who have been affected by these Panther/FireWire issues.
FREQUENTLY ASKED QUESTIONS Below are a number of questions we have been receiving about this issue. We have tried to answer them to the best of our knowledge at this time; however, we continue to research these issues and will provide more information as it comes in.
Does the issue occur for everyone using the "affected" drives? As we have mentioned a number of times over the past week, the problem is clearly not being experienced by everyone. We continue to receive positive reports from readers who have been using their FireWire drives since Panther was released -- some of them drives that are indeed supposed to be affected, according to Apple and drive vendors -- with no ill effects. That being said, if your drive is "officially" at risk, we urge you to visit the manufacturer's Web site to see if a firmware update is available. There's no reason to play with fire if a fix is available to you.
Does the problem happen immediately or over time? A number of readers have asked whether or not drive corruption occurs immediately. In almost all reported cases, the drive corruption occurs when the Panther computer is restarted with the FireWire drive connected and mounted. Sometimes -- as in the case of one of our own drives here at MacFixIt -- this corruption occurs on the first restart with the drive connected after installing Panther. However, according to reports we have received, as well as messages posted to Apple's Discussions forums, this isn't always the case. Some users have reported that their drive appears to work fine through several restarts, but then a later restart renders the drive unusable. Until we know more about the specific contributing factor(s), we continue to recommend that FireWire drives be unmounted and disconnected before restarting your Panther Mac. There's no sense in playing Russian Roulette with your data.
Does the problem occur when connecting two Macs via Target Disk Mode? A common question over the past week has been whether or not this bug affects Macs themselves when one of the Macs is acting as an external FireWire drive via Target Disk Mode. We haven't experienced such a problem here at MacFixIt, but we have received a few isolated reports of Target Disk Mode issues. Reader Brian Sullivan writes:
"Last week I attached a Clamshell iBook to a new 12' PB via Firewire. (Held down 'T' while booting the iBook.) The goal was to copy the entire iBook hard drive to the new Powerbook. Once the transfer was completed successfully, I was unable to unmount/eject the iBook. After many attempts, we finally shut down the iBook. The result: the data on the iBook hard drive is lost, and the drive needs to be reformatted. Fortunately, the transfer worked, so we lost no data. But it was a pretty scary."
Unfortunately, with the small number of reports we've received on this particular issue, we have no way of knowing if these problems are related to the Panther/FireWire bug being discussed. In addition, the sequence of events in the above report does not seem to match up with those most commonly reported with the "official" Panther/FireWire bug. Finally, we currently don't know what chipset Apple uses for the FireWire ports in their systems; it's even possible that different chipsets could be used for different models. So, again, we recommend simply avoiding restarting your Panther Mac with FireWire drives (including Target Disk Mode Macs) connected.
Is the problem related to the hard drives themselves, or the FireWire enclosures? As far as we've been able to determine, the problem is not related to the actual hard drive used in the affected FireWire drives. Rather, the issue simply has to do with the fact that the drive is housed in a FireWire enclosure. Identical drive enclosures with different drives inside appear to be equally susceptible to damage.
Is the problem related to...? We continue to receive theories from readers about what the problem "really" is. As an FYI, based on reader reports and other research, the issue does not appear to be related to: whether the drive was formatted in Jaguar or Panther; whether or not the drive was connected while installing Panther; whether or not journaling was enabled on the drive; whether Panther was installed clean, via the update method, or via the Archive and Install method; or whether the drive was self-powered or bus-powered. The only common factor we have been able to identify is that the affected drives were connected to the computer when it was restarted.
Is the problem really limited to FireWire 800/Oxford 922 drives? Apple's official position is that this problem only affects FireWire 800 drives using the Oxford 922 chipset. Oxford, the makers of the chipset, initially questioned this assertion. However, David Schloss, Technology Editor at Photo District News, recently interviewed James Lewis, President of Oxford Semiconductor, who stated, "I can categorically tell you that it's impossible for [the Oxford 911 chipset] to exhibit the same failure mechanism. So you have a different problem that is unrelated to the sole problem relating to earlier version of firmware." (Ironically, David's own FireWire hard drive, lost to what appears to be a Panther/FireWire issue, is a FireWire 400 drive from ComputerGeeks.com that uses the Oxford 911 chipset. This is the same drive a MacFixIt staffer lost to Panther, as described below.)
At the same time, reader Charles Teton forwarded a response he got from LaCie, indicating that they are still actively testing FireWire 400 drives and haven't ruled out the possibility that other drives are affected:
"Yes, we are testing with multiple Oxford based FW400 and FW800 drives on several Mac platforms; with built-in FW400 and FW800 interfaces, as well as FW400 and FW800 add-on cards; both PCI and PC Card. It takes a while to go thru these iterations. The good news is that we can look inside and see what is going on if/when something goes wrong."
We have received a significant number of reports of FireWire "drive deaths" with Panther involving drives that were not FireWire 800/Oxford 922 drives. Apple's Discussions forums and numerous other sites around the Web are also populated with such reports. We've also personally lost FireWire 400 drives since installing Panther (see below). Taken as a whole, it would seem to be a stunning coincidence if all of these reports were completely unrelated. What we suspect is that either (a) this bug isn't limited to FW800/Oxford 922 drives; or (b) there are other problems with Panther and FireWire drives that simply haven't yet been isolated and identified.
Whichever may be the case, because of these suspicions, we continue to recommend caution when using FireWire drives with Panther, regardless of the connection speed (400 vs. 800) or the chipset used.
Is the drive permanently damaged? No. Although the drives affected by this bug are "unrecognizable" afterwards, the problem is not with the actual drive's hardware; rather, it is with the drive's directory. After reformatting the drive, it should work fine. (See below about recovering data before reformatting.)
What is technically happening to the drive? Right now, no one is saying. However, from talking with drive recovery and disk utility vendors, it appears that at some point during the shutdown/startup/restart process -- either when the drive is unmounted, when it is mounted, and/or when it is checked for file system problems -- the drive's directory is getting severely corrupted. So much so that drive utilities are generally unable to repair it. We continue to investigate this issue, and hope to have more information soon.
Is my data recoverable? Although readers have reported varying degrees of success in recovering data from affected drives, some have been completely out of luck. Those that have been successful have used techniques such as connecting the drives to Macs running Jaguar or OS 9, or installing drives internally instead of connecting them via FireWire. Others report some success with Prosoft's Data Rescue X; on our own drive that was lost (see below), we were able to use Prosoft's Data Rescue X to recover some files, but not all. Some users even report that after being unable to recover data on the damaged drive using Data Rescue X, they used Disk Utility to erase the drive -- NOT using any special options, such as zeroing data -- after which Data Rescue X was successful at retrieving at least some data. Since "erasing" a drive in Disk Utility doesn't really erase it, but instead just deletes the drive directory and creates a new one, the data should be mostly untouched. However, we recommend against this procedure except as a last resort.
We asked John Christopher, a Data Recovery Engineer at DriveSavers -- the company has worked with a few drives damaged by this problem -- about the possibility of data recovery using commercial utilities. His reply:
"I would say there is likely a chance of recovery with commercial utilities. However the dangerous part comes when these tools are used incorrectly. Any disk utility that can perform a fix-it routine may damage whatever directory remnants are on the drive and could complicate further recovery attempts. The safest path to take is to attempt to recover the data to a secondary hard drive." Who is to blame? This is of course the big question. We've heard from both sides -- Apple and drive manufacturers -- and many readers have chimed in with their own opinions, as well. Apple claims that the problem is due to the firmware on affected drives -- Apple invented FireWire, so they should know the official specifications, right? It's been argued that these FireWire chipsets weren't 100% compliant, but that previous versions of the Mac OS (and Mac OS 9, for that matter) were simply less sensitive to out-of-spec hardware. So perhaps Panther requires "more compliant" FireWire devices. This isn't an unreasonable idea, as we've seen a similar issue crop up with Panther and RAM.
At the same time, some drive manufacturers claim that the issue is clearly with Panther. After all, Apple has proven that they can provide an operating system that works fine with all of these drives -- they did it with earlier versions of Mac OS X, and even with many of the Panther betas. Shouldn't Apple simply "fix" Panther so that it works with all drives?
The truth may be that both sides are partly at fault, but until we get more facts, we aren't going to "blame" either side. What matters is that a significant number of users have been adversely affected, and who is to blame is clearly less important to these users than who is going to help them. For those users who have drives made by vendors who have provided firmware fixes, this discussion is somewhat academic?they've already been provided with a firmware update that "fixes" their drive. However, what about users who have drives from other manufacturers? What about users who "built" their own FireWire drives using a bare drive and a third-party FireWire enclosure? Apple may or may not be correct in asserting that the problem is with the drives and not with OS X -- we don't really know -- but it doesn't seem realistic to expect every hard drive vendor, and the makers of generic enclosures, to provide firmware updates for those drives and enclosures, meaning that a lot of users are going to be left wondering if it's ever safe to use their FireWire drives again.
For these reasons, we continue to hope that Apple provides an update to Panther that "fixes" this problem, regardless of who is actually at fault. If it turns out the problem really was with the drives, and not with Panther, then Apple looks even better for taking care of their users.
Reports of problems with earlier versions of Mac OS X One consequence of the Panther/FireWire problem being so public over the past week is that MacFixIt has been receiving a significant number of reports of similar problems, including data loss, with FireWire drives under OS X 10.0.x, 10.1.x, and 10.2.x. Such issues appear to be unrelated to the current Panther problem, but they do make us wonder if FireWire support in OS X isn't quite as mature as we had always assumed.
MacFixIt experiences As we previously mentioned, a drive used by a MacFixIt Editor -- a 120GB Western Digital hard drive inside a FireWire 400 enclosure using an Oxford 911 chipset -- was damaged by what appears to be the exact same sequence of events as the publicly acknowledged Panther/FireWire bug: the drive mounted and functioned properly when connected to the computer running Panther, but after a restart, it was unreadable. The machine in question was a day-old Power Mac G5 Dual 2GHz with a brand new installation of Panther. (The drive was connected to the G5's FireWire 400 port.) Panther's Disk Utility could not repair the drive. We connected the drive to a Mac running OS X 10.2 Jaguar, and ran Alsoft's DiskWarrior on it; DiskWarrior was forced to scavenge the drive to rebuild the directory, but the resulting directory was missing over 90% of the files that were on the drive before the incident (so we elected to leave the drive untouched). We even removed the drive from its FireWire case and installed it internally in a Mac running Jaguar and OS 9; neither OS could access the drive's contents.
Out of curiousity, we performed an experiment this week using another of our own drives, a SmartDisk FireFly 5GB portable FireWire 400 drive. We connected the drive to the G5, and it mounted and functioned properly. We ran Disk Utility and Disk Warrior on it, and it appeared to be healthy. Finally, we used Panther's Disk Utility to erase the drive to make sure we could rule out drive problems if something happened. After erasing, the drive again worked fine, as we were able to unmount it, disconnect it, reconnect and mount it, and copy and delete data from it. We then restarted the G5 with the drive connected. After the restart, the drive no longer functioned; OS X gave the same "unrecognizable" error, with the options to Initialize, Ignore, or Eject, as the previous "lost" drive. Perhaps this isn't the same exact issue as the one Apple has publicly acknowledged; however, even if that's the case, this clearly wasn't "expected" behavior.
128 GB limit Apparently under the same umbrella of Panther FireWire issues, some users are reporting that 160 GB and 200 GB drives are being limited to 128 GB. MacFixIt reader Jochen writes:
"Just recently I installed a 160 GB hard drive. Under Mac OS 9.2.2 I received only 128 GB. Under Mac OS X 10.1.5 it was 149 GB (normal). Under Mac OS X 10.3 it was again 128 GB."
The only FireWire expansion cards that can properly recognize drives with more than 128 GB are those based on the ATA-6 specification. ATA-5 based FireWire cards will not be able to recognize more than 128 GB of one volume. Since the ATA-6 functionality requires new drivers, it stands to reason that with installation of Panther, some part of the specific FireWire driver - or some link to the firmware - was affected.
Some readers have reported that they are once again able to address more than 128 GB of disk size by installing the recently released firmware updates from LaCie and WiebeTech.
Speed boost from LaCie firmware update The firmware update from LaCie may do more than prevent problems with drive corruption and data loss. We are beginning to receive reports that the update improves performance even on systems that weren't affected by any problems during the Panther update. MacFixIt reader Dominic Dunlop writes:
"Even though I was not having any problems, I updated the firmware on my LaCie FireWire 400 'Big Disk' using the Mac OS 9 updater . I didn't need to do this as the FireWire 400 models do not have issues with Mac OS 10.3, but the upgrade promised 'performance improvements,' and I'm a sucker for a sales line like that. Anyway, after some mucking about resolving an extensions conflict with the LaCie-supplied version of SilverLining (I never did work out what the culprit was -- ah, the joys of Mac OS Classic), the upgrade went through exactly as described in the Readme document, and everything is (still) fine. What's more, there is indeed an improvement in read speed -- from about 25MB/sec to about 30 (that's reading the UNIX raw disk device in large chunks -- file reads are inevitably slower)."
The dangers of case-sensitive HFS+
Many users will remember that hard drive "journaling," now standard on Panther installations, was originally introduced in OS X 10.2 (Jaguar) as a "Mac OS X Server-only" feature; however, since the code-base of OS X and OS X Server are to a large extent identical, some users realized that they could enable journaling in the standard version of Jaguar via a simple Terminal command. This eventually led to the ability to enable journaling via a number of third-party utilities. Although a few disk utilities had trouble repairing journaled drives until they were updated, in general no serious harm was done by this type of experimentation.We bring this issue up now because of a volume formatting option that has made its debut in Panther, officially only in OS X Server: Case-sensitive HFS. Although currently only Mac OS X 10.3 (Panther) Server allows administrators to easily format volumes using this new volume format, its mere existence is sure to spur some Mac users to try to find a way to enable it on their own computers. (It's actually possible to enable Case-sensitive HFS in Panther client via Terminal, but it requires you to completely erase your drive, which is a more effective deterrent than existed for journaling.) For those tempted to do so, we suggest that you avoid that temptation, at least until Apple and third-party vendors officially support it. Read on for the reasons why.
Mac OS file systems (HFS Standard and HFS Plus, aka HFS Extended) have traditionally been "case-insensitive" file systems. In other words, they do not recognize differences in case when it comes to filenames and filepaths. As far as HFS Standard and Plus are concerned, files named Text.txt and TEXT.TXT have the exact same name, and you can't have two such files in the same folder/directory. However, many Unix file systems, such as UFS, are case-sensitive. To these file systems, these two files -- Text.txt and TEXT.TXT -- have different names, and can co-exist in the same directory. Under a case-sensitive file system, the only way files are considered to have the same name is if every single character in the names match, including the case.
In order to improve OS X's ability to interact with other Unix systems, Panther includes Case-sensitive HFS as a potential file system. However, implementing a case-sensitive file system in OS X has some significant hurdles, the most compelling being that many current Mac OS applications that work with files will need to be updated to provide case-sensitivity themselves. This especially the case for backup and disk repair utilities. For example, using the two example files above, most backup applications will assume that they are the same file, and only back one up. (Dantz has already posted a warning to this effect in a Retrospect support document, stating, "Retrospect 5.1 does not recognize case-sensitive file names. If 'file' and 'FILE' exist in the same directory, only one will be backed up.") Likewise, most current Mac OS X disk utilities would see the two example files as two files with the same name, causing a number of problems when trying to repair/rebuild/reconcile drives and drive directories.
In other words, Case-sensitive HFS is not (yet) for the masses. We're sure there will be a curious type (or forty) who will be determined to figure out how to enable it on the standard OS X client. If such a procedure becomes available, we urge you to remember the old saying: just because you can doesn't mean you should.
Problems with installation: Stuck on Disc 2; bad discs; disconnecting devices
It appears that some Mac OS X 10.3 packages include a bad second Installer disc, evidenced by dozens of reports that installation failed somewhere on CD 2.
Quitting installation after the first CD will leave out some components like extra language support. Greg Davidson writes:
"I upgraded from Mac OS X 10.2.6 on my PowerBook G3 500, 512MB, stock otherwise. The installation failed somewhere during the language packs on Install CD 2 (didn't see exactly where since I was trying to get my daughter ready for bed). I acknowledged the error and it dropped out of the installer. I rebooted manually and it booted fine into Mac OS X 10.3 and everything seems to work properly. I've tested the programs and rebooted several times without problem. I assume that the failed installation only resulted in my PowerBook not having some foreign language files, which I can live without."
Other readers have reported that installation fails during the transition from disc 1 and disc 2. Les Dodson writes "During the installation of Panther, it will proceed normally through the installation of Disk One, and reboot. After you get through to the continuation screen, one of two things has happened: The install quits unexpectedly or; The installer keep requesting Disc 2, when it's already present in the drive."
As a workaround for this problem, you can force the installer to quit (when it keeps requesting disc 2), bringing you to the Finder where you can mount and install the second disc data manually.
Installation problems? Try removing all third party devices/RAM Though it might be a lengthy task for some set-ups, some readers have reported that constant problems with installing Panther or properly starting up after installation were resolved by removing all PCI cards, extra RAM, FireWire/USB devices, and other components. Pinpointing which exact component (in some instances more than one) is wreaking havoc can be near impossible.
In many cases, all or most of these devices can be re-introduced after Mac OS X 10.3 has successfully completed installation, but for some reason cause problems when connected during installation.
In addition to disconnecting external devices and removing non-native RAM, some readers have reported success eliminating problems by turning off any applications that are triggered at startup, including some menu and interface enhancements.
A few readers have reported issues with Panther's memory use, which appears to generate a significantly larger number of virtual memory swap files than Jaguar did. (We've also seen similar reports on other sites around the Web and in Apple's Discussions forums.) Reader David Peever writes:"There appears to be a serious problem with the way that virtual memory/swap files eats up hard disk space in Panther. This results in alerts advising that the hard disk is full ? the only way to clear the temporary files is to restart the machine. This is a crazy situation with what is supposed to be an advanced operating system requiring regular restarts. The problems have affected an iBook G3 600Mhz with 384MB RAM and a 600MHz iMac with 384MB RAM."
In our experience, Panther itself requires more memory than Jaguar did, and 384MB of RAM is simply not enough for good performance, despite Apple's "minimum system requirements" of 256MB. If you have less than 512MB of RAM, you'll probably see significantly more virtual memory swap files -- and therefore less free drive space -- than you would have seen under Jaguar. In fact, it wasn't until we upgraded our own computers to 640MB or more that we saw noticeable performance improvements. (To be fair, we work with a large number of applications, some of them RAM-hungry, open at the same time.)
Panther access changes go to far?
In Jaguar, one of the most common criticisms was that users couldn't move or delete files because they didn't have permission/access. In Panther, Apple has attempted to address this issue by allowing administrative users to authenticate -- by providng their admin-level username and password -- in order to perform such actions. However, we've received reports of systems that have been rendered unusable by users experimenting with this new feature. A post in an Apple Discussions forum best explains the risk:"On a whim [I] thought to myself, 'Oh, it can't be that easy to hose the System/Library directory, can it?' Tried it in 10.2.8 and couldn't do it [when] logged in with Admin privilegs. On the 10.3 box, logged in...as an Admin, hit Command-Delete on the /System/Library directory and *POOF* it went to the trash can. Couldn't retrieve the folder from the trash. A reboot resulting in a screen full of kernel panic warnings and other text, ending with 'panic: we are hanging here.' The system is totally hosed and I'm reinstalling as I type this."
Granted, the user could have booted into single-user mode, mounted the drive, and then used a few Unix commands to restore the /System/Library directory to its proper location. However, most users would not know how to do this.
We haven't tried to verify this procedure -- the ability to move the entire /System/Library directory to the Trash -- on our own system, for obvious reasons; however, based on the experiments we have tried with important system-level files, it appears to be possible. If so, one could argue that Apple went too far in trying to make OS X "more convenient" when it comes to deleting files. Some might point out that in OS 9, users could move the System Folder to the Trash. But we didn't consider that a good thing, either.
Panther problems? Drop us an email at Late-breakers@macfixit.com.
Data loss? especiallywith user settings and Keychain data - can occurr when using FileVault's "reclaim disk space" feature.
Alex Johnson writes "Behavior includes a complete reset of Finder preferences - including Dock, default icon and column views, empty Trash warning, etc. - to the 'out-of-the-box' settings. Also corruption of the iTunes Database, iCal calendars, Keychain preferences, .dmg files reporting errors and images not mounting.
"The best guess is that this is caused by using FileVault, and allowing it to reclaim unused space. This is not a one-time problem - changes to preferences do not 'stick' while FileVault is on, whether or not unused space is reclaimed. Users - including myself - have found that this problem disappears if FileVault is turned off, which is what we have done - though this can take more than one try to accomplish; FileVault reported an error the first time I tried (no additional data was lost). On the second attempt I managed to turn FileVault off and my system is now working perfectly. This is an annoying bug to be sure, but the combination of encryption and a loss of data is a also worrying one."
Generally the FileVault "recovery" message will appear at logout. You can simply choose not to recover the disk space, until it is determined why File Vault is erasing these settings.
Ther is a problem with the Epson 3200 scanner under Mac OS X 10.3. The problem involves Apple's Image Capture jumping in line ahead of the SilverFast SE software. MacFixIt reader David Story offers a workaround:
"In order to make the SilverFast SE software run and bypass Apple's Image Capture and recognize the Epson Scanner on the Firewire port, I stuffed the Epson Monitor which normally sits in the Application folder (to deactivate it) and I removed the Epson Scanner which normally sits in the Library/Image Capture/Devices folder. I placed both of these temporarily in the Application folder to put back at a later date when Epson fixes their software. If you do not stuff the Epson Monitor, merely removing the Epson Scanner will not work.
"If you do not take the above steps but still wish to use the scanner, you must always run the Activity Monitor in the Utility Folder and kill all Epson threads before running any software, either the Epson Scan or Silverfast SE (after each startup). This is a nuisance to have to complete after each boot up and prior to scanning though."
One MacFixIt reader reports that none of these workaround helped, but a "shotgun" approach did: he deleted every file that included "Epson Scan" and "Epson TWAIN," and then reinstalled the Epson software for his scanner. Reader Don Bjornsen reports an issue with OS X 10.3 and display calibration, referring us to a thread on Apple's forums. A number of users are finding that after installing OS X 10.3 on an iBook, the screen is "washed out." However, when they attempt to use the Displays pane of System Preferences to calibrate their screen, they get an error that OS X "Cannot calibrate the display. The factory profile for the display cannot be found." Several users report that copying the missing profile from another computer doesn't work. Although no one has yet found a permanent solution to the problem, one participant provided a workaround using the Classic Environment:- 1. Start Classic.
- 2. Open the OS 9 Monitors control panel (located in /System Folder/Control Panels).
- 3. Select your computer model (in this case, your iBook) from the list of profiles.
This temporarily adjusts the screen; however, your screen will reset to its previous washed out state if you log out or shut down/restart. If you're affected by this bug, another solution is to use the shareware SuperCal to calibrate the screen.
Rob Yager offers a series of workarounds for those having problems with Mac OS X 10.3's ability to forward the faxes it receives by email to addresses you specify. The service makes use of postfix - an mail sending application built into Mac OS X, and in some cases, some items are not installed correctly.
1. The service makes use of some special users that need to be configured. In many installations, the script to do that isn't run. A way to fix that is to type the following in Terminal: sudo /Library/Receipts/Essentials.pkg/Contents/Resources/CreateSystemUsers
The only space is between sudo and /Library. You'll need to enter your administrator password
2. After you have done this, it is probably an idea to repair permissions using DiskUtility
3. Edit /usr/libexec/fax/faxnotify using your favorite UNIX editor to replace the line that reads
stdout, stdin = os.popen2('/usr/bin/mail ' + quote(recipients) with stdout, stdin = os.popen2('/usr/sbin/sendmail -oi -t')
This removes some unwanted space between the last of the headers and the MIME boundary line in the message. If you don't do this, the received message will not recognize the attachment it contains which is the fax.
4. You may need to edit /etc/hostconfig If there is a line which says
MAILSERVER=-NO- change it to MAILSERVER=-AUTOMATIC-
This will allow postfix to start when your computer has processed the fax and delivers it to postfix to forward on.
5. Restart and test
HP statement on all-in-one support We previously noted lack of full functionality with Hewlett Packard's all-in-one print/scan/fax devices under Mac OS X 10.3. The company has now made an official statement on the issue:
"Many current HP products have 'Print Only" drivers built into the new OS 10.3 (see table). To maintain full functionality of your HP All-in-One products, please wait for the 10.3 HP software driver that will be available with the next few weeks. "
Compatibility: Quicken; DiskWarrior; StuffIt; Virtual PC; g4port; CopyPaste; PhotoPaint; Palm; moreQuicken 2004 Several readers have reported problems, confirmed by Intuit technical support, with Quicken 2004 after upgrading to Mac OS X 10.3. Some users have Quicken 2004 successfully launch just twice, then never again. For some it fails immediately. The Crash Report consistently shows a KERN_PROTECTION_FAILURE with some Macs displaying this problem.
Intuit Technical Support indicates that they are receiving reports of this, and the company's team is currently testing Panther compatibility.
This problem is not universal, but readers who are experiencing the problem report that using the Finder's search command to delete all files related to the string "Quicken," then re-installing the software can result in proper operation.
Another workaround working for some readers involves deleting the 3 files "com.intuit.quicken.plist", "Quicken 2004 Preferences", and "Quicken" (which is a folder) from your ~/Library/Preferences folder. In this case, re-launching the application after deleting the files is all that is required.
Outlook Express If you are experiencing problems Outlook Express after upgrading to Mac OS X 10.3, you may want to try doing an erase and install of Panther, rather than an Archive and Install. Several readers who have started with a fresh disk are having no trouble.
Using synchronization with Microsoft Exchange Several readers have have had trouble performing synchronization with Microsoft Exchange address book via the Address Book application's preferences. The Exchange address book icon does not appear in the iSync devices window.
Peter MacLaren writes "It is noteworthy that the Panther package includes iSync 1.2, which is not installed if you already have iSync 1.3 installed."
DiskWarrior 3.0 and Mac OS X v. 10.3 A statement posted to Alsoft's Web site states: "DiskWarrior 3.0 will not run while started up under Mac OS X v. 10.3 (Panther). DiskWarrior 3.0 can be used to safely rebuild the directory of a disk (including a disk with file journaling and/or FileVault enabled) with Mac OS X v. 10.3 by starting up from your current DiskWarrior 3.0 CD. An update allowing DiskWarrior to run while started from Mac OS X v. 10.3 is forthcoming; we currently estimate that the update will be available in mid-November. This update will be able to start up all machines available at the time of its release, including PowerMac G5 machines, PowerBook models updated September 2003, eMac models updated October 2003, and the iBook G4."
StuffIt Engine not recognized Several readers have reported that StuffIt Deluxe 8.0 becomes unusable after upgrading to Mac OS X 10.3. Most users affected by the problem have been able to fix it by re-installing Stuffit Deluxe 8.0.1.If you haven't installed Mac OS X 10.3 yet, you may be able to avoid the problem altogether by choosing a Custom install and de-selecting StuffIt.
Virtual PC 6.1 Printing While most readers have reported no major problems in Virtual PC 6.1 after upgrading to Mac OS X 10.3, there are a few reports of minor annoyances.
Luca Giroux reports that after upgrading to Panther, Virtual PC 6.1 with Win95 or Win2000 will not print using emulation printing. We've corroborated this with other readers, and it appears to be due to Panther's change in printing architecture.
Tom Beardmore writes "After installing Mac OS X 10.3 (Panther), I found that when I run Virtual PC 6.1, I cannot click out of the Virtual PC window and into any other application that is still running in the background. However, by toggling through the open applications using the Command-Tab keyboard sequences, I can manage to get back into the desired application."
Griffin g4port Earlier reports of problems with the g4port have been met with the following response from Griffin "We are aware of this and we are working on a driver update."
In the meantime, MacFixIt reader Nicholas Riley notes that the Stealth Serial Port driver works fine with the g4Port under Mac OS X 10.3.
CopyPaste workaround We previously reported that CopyPaste X 1.6 causes the "c" key to malfunction in Mac OS X 10.3. The software's author has now provided a temporary workaround until a software fix can be supplied:
"While running CopyPaste with OS X 10.3, the lowercase 'c' will not type. I have to hold it down with effort in order to get it to type. Quit CopyPaste and the problem goes away.
"The problem is a conflict with the use of the Command key preference that CopyPaste relies on - it is this that disables your 'c.' Start CopyPaste and immediately go to the Preferences Menu .If you change the first popup preference to not use the Command key, it will enable the 'c' to work. The next two settings must have a selection other than 'no clip archive.' Be careful not to select a shortcut that conflicts with other application shortcuts if you have had no clip archive selected previously. For example Command-shift-V will conflict with an Entourage shortcut to paste as quotation."
Corel PhotoPaint Some users have reported problems starting up Corel PhotoPaint and some other Corel applications after upgrading to Mac OS X 10.3. In some cases, this issue can be resolved by holding down the "Shift" key during application launch. You will then be presented with a dialog box that asks:
"Overwrite the current workspace with the factory default?"
Clicking yes will result in loss of any custom workspaces, but has resolved the issue for some readers.
SoundSticks lose right channel audio The Harmon Kardon-designed SoundSticks sold by Apple are losing right-channel audio with Mac OS X 10.3 in some cases.
Users who are experiencing this problem have, in many cases, noted that the "Sound" pane of System Preferences displays the message "'The selected device has no output controls."
Some have had success un-plugging the SoundSticks from their USB hub or display's USB port and plugging them, instead, directly into their Mac.
Extensis gives word on Suitcase/Font Reserve Extensis has issued a statement on Suitcase X1 and Font Reserve functionality within Mac OS X 10.3 "Currently neither Font Reserve nor Suitcase are fully compatible with Panther. Suitcse too has some efficiency issues (activation/deactivation is quite slow), there will be an update soon to address this. In Tech Support, we have not been told anything as to when a Font Reserve update may be available."
So it appears that Suitcase X1 will soon be updated for Panther compatibility, while Font Reserve (which is also causing problems with Photoshop) may never see a compatibility fix.
Palm confirms that Desktop Software 4.1 problem MacFixIt reader Kate has confirmed with Palm technical support that the Palm Desktop Software 4.1 software will have problems Mac OS X 10.3 (Panther):
"The Palm Desktop software is not currently compatible with the Mac OS 10.3. Palm Engineers are aware of this issue and are working on an upgrade. Currently, there is no fix available for the issue, I suggest you to keep checking the following Palm web site for updates: http://www.palmone.com/us/support/downloads/"
Joshua Ochs reports a workaround for problems using HotSync, which are apparently the root of the incompatibility statement from Palm.
""It appears that the Palm Desktop installer is choking on installing the HotSync libraries. It further appears these can be copied over from Jaguar (or, if you're upgrading, then they'll already be in place). The critical files are in /Library/Application Support/Palm Hotsync and /Library/CFMSupport/Hotsync Libraries.
"I have not verified that a Hotsync will actually take place (as I have not finished upgrading), but this does resolve the problem of Hotsync Manager and others not launching with shared library errors.
Some readers have reported no problems running HotSync from a fresh installation of the Palm Desktop 4.1 software.
Default Folder X workarounds As we reported yesterday, if you have Default Folder X 1.8 (or earlier) installed, you will not be able to run any applications after installing Panther if Default Folder X is running. We've now received two solutions from Jon Gotow at St. Clair Software:
A) Before upgrading to Mac OS X Panther, download and install Default Folder X 1.9.1, which is fully compatible with Panther. It is available from: http://www.stclairsoft.com/DefaultFolderX/release.html.
B) If you have already installed Panther, you must log in without launching Default Folder X. To do this, follow these steps:- If you have your computer set to automatically log in after starting up, hold down the shift key as soon as the Mac OS X progress bar appears during startup. You will then be prompted to log in rather than being logged in automatically.
- Enter your password and then hold the shift key down while logging in. Keep the Shift key held down until you see the menu bar. This will disable all applications that normally run at log-in time.
- Once you have logged in without Default Folder X running, immediately open System Preferences, select Default Folder X, and turn off its "Launch at Login" option. You can then proceed to download and install the new version of Default Folder X from the URL above.
St. Clair Software has set up a special e-mail address to route Mac OS X 10.3 issues: panther@stclairsoft.com.
Sorenson Pro 3 codec Several reports indicate that the Sorenson Pro 3 codec will not work under Mac OS X 10.3 with QuickTime 6.4. Readers inquiring about the problem are receiving the following response from Sorenson:"We have been made aware of the problem and although our product should work we are just going to release an update to our codec. You should find the update on our website within a few weeks."
If you need the Pro 3 codec functionality, it will still work in the Classic environment.
Resources