Follow-up:
OK, I think I'm onto something. One thing that safe mode does is restrict the kext loadup. I used Kext Wizard to export a list of all loaded kexts for both normal boot and safe boot, then cross-compared to obtain an "unsafe" list of kexts:
Code:
4. Loaded Kexts:
FILESYSTEM
***** com.apple.filesystems.ntfs 3.10 /System/Library/Extensions/ntfs.kext x86_64
***** com.apple.filesystems.msdosfs 1.8 /System/Library/Extensions/msdosfs.kext x86_64
***** com.apple.filesystems.smbfs 1.8 /System/Library/Extensions/smbfs.kext x86_64
MISC
***** com.apple.GeForce 8.0.0 /System/Library/Extensions/GeForce.kext x86_64
***** com.apple.kext.OSvKernDSPLib 1.6 /System/Library/Extensions/OSvKernDSPLib.kext x86_64
***** com.apple.driver.AppleSMBusController 1.0.10d0 /System/Library/Extensions/AppleSMBusController.kext x86_64
***** com.apple.driver.AppleMCCSControl 1.0.33 /System/Library/Extensions/AppleMCCSControl.kext x86_64
***** com.apple.driver.AppleUpstreamUserClient 3.5.10 /System/Library/Extensions/AppleUpstreamUserClient.kext x86_64
***** com.iospirit.driver.rbiokithelper 1.18 /System/Library/Extensions/RBIOKitHelper.kext x86_64 i386
***** com.apple.driver.DspFuncLib 2.2.0f3 /System/Library/Extensions/AppleHDA.kext/Contents/Plugins/DspFuncLib.kext x86_64 i386
I/O
***** com.apple.iokit.IOUserEthernet 1.0.0d1 /System/Library/Extensions/IOUserEthernet.kext x86_64
***** com.apple.iokit.IOSerialFamily 10.0.6 /System/Library/Extensions/IOSerialFamily.kext x86_64
***** com.apple.iokit.IOBluetoothSerialManager 4.0.9f33 /System/Library/Extensions/IOBluetoothFamily.kext/Contents/Plugins/IOBluetoothSerialManager.kext x86_64
AUDIO
***** com.apple.iokit.IOHDAFamily 2.2.0f3 /System/Library/Extensions/AppleHDA.kext/Contents/Plugins/IOHDAFamily.kext x86_64 i386
***** com.apple.driver.AppleHDAController 2.2.0f3 /System/Library/Extensions/AppleHDA.kext/Contents/Plugins/AppleHDAController.kext x86_64 i386
***** com.apple.driver.AppleHDA 2.2.0f3 /System/Library/Extensions/AppleHDA.kext x86_64 i386
***** com.rogueamoeba.HermesAudio 3.0.2 /System/Library/Extensions/HermesAudio.kext x86_64 i386 ppc
***** com.Cycling74.driver.Soundflower 1.5.1 /System/Library/Extensions/Soundflower.kext x86_64 i386 ppc
***** com.apple.driver.AudioAUUC 1.60 /System/Library/Extensions/AudioAUUC.kext x86_64
***** com.apple.iokit.IOAudioFamily 1.8.9fc10 /System/Library/Extensions/IOAudioFamily.kext x86_64
(classifications edited in by me)
What immediately stood out were the filesystem kexts - NTFS, MSDOS, and SMBFS. Bingo! One new thing is I have been running a new Win 7 installation on an internal drive, with a backup partition on another internal drive, and an FAT32 swap partition as well. Sounds suspicious, right?
So I first unmount all my NTFS/FAT drives from the finder. No change, sadly. Next I try to unload the filesystem kexts through Kext Wizard, but I get an odd error:
(kernel) Kext com.apple.filesystems.msdosfs not found for unload request.
Failed to unload com.apple.filesystems.msdosfs - (libkern/kext) not found.
What? How can it not be loaded? Argh!
So now I am backing up the relevant kexts, removing them, rebooting, and testing. I'll update back in a bit... or not, if I destroy my OSX. I have a fresh clone though.
EDIT:
SUCCESS! Sort of.
Rebooting without MSDOS (that's FAT) and NTFS filesystem kexts worked! Time machine backed up right away. This also solved two other nagging problems: slightly slower boot times than before my Win 7 installation, and slow SuperDuper app opening speed. Clearly one or more of my NTFS/FAT partitions are not playing well with the OS X filesystem kexts,
even when the partition is not mounted.
My next step, I'm going to add in just the FAT kext and see if that's the culprit. Starting with that one because it's probably the easiest to remedy - delete the partition (it's empty ATM) and re-create it using OS X, not Windows. If that one isn't the culprit, but NTFS is, I'm going to have to do a lot more work to get a usable filesystem going. Fingers crossed...
EDIT2:
FAT kext reloaded and FAT volume mounted, Time Machine still works. SuperDuper gets slightly slowed down opening with it mounted, but just for a moment, nothing like the 20-second delay when an NTFS drive was mounted.
Next up, loading the NTFS back in.
EDIT3:
Well, looks like it's the NTFS volumes that are screwing things up. Adding the NTFS kext back in slows down boot, causes SuperDuper to take 18 seconds to open (an eternity on my otherwise extremely fast machine), and causes Time Machine to say "looking for backup disk."
I tried deleting my Windows 7 Backup partition, which was shared on an internal GPT drive that also had an OS X content partition. This wasn't my only backup (I have an external offsite clone), but it was the logical place for an internal backup. Unfortunately that did not seem to help at all. It
seems as though the Windows volume itself, on a completely separate physical drive (mSATA SSD), is causing OS X to choke. I cannot understand why that would be, but I also cannot think at the moment what to do about it. It causes me some real problems with respect to maintaining a properly-backed-up dual booting machine.
I'll try and figure out a solution. In the meantime, anyone else with this error, check if you also have NTFS drives connected somewhere. They don't have to mounted, apparently, to slow down these programs (TM, SD).
EDIT4:
Interesting. Simply rebooting after having deleted the NTFS partition on my shared internal drive allowed Time Machine to work again (thankfully, this means I don't have to mess with my primary Win7 partition). But SuperDuper still takes the same 18 seconds to load.
