I have a dual boot system, with Mac OS X and Ubuntu running. I had read somewhere that you need to turn off journaling on Mac's HFS+ filesystem to use it from Linux, so I had religiously done that. Yesterday, I used something from my Mac volume in Linux, hadn't done any writes. Today, when I booted OS X, it just refused to go beyond the initial grey boot time screen. I gave it 20 minutes, then I shut if off. I tried it again, gave it 1hr 30min, my patience called off, and I again shut it off. If something was taking so much time at boot, I was pretty sure there was some pain in the filesystem, and turning journaling off was causing hopelessly long recovery times. But I hadn't expected to wait this long! It was getting ridiculous.
Then, I booted Linux, looked for a possible fix. Found a feasible solution, on Ubuntu forums, it was a bit broken so reproducing it here with fixes. Run the following script as su to fix inconsistent hfs+ volumes. You need build tools and libssl-dev to use this, I had to learn it the hard way.
cd /usr/src
mkdir hfsplus_support
wget http://gentoo.osuosl.org/distfiles/diskdev_cmds-332.14.tar.gz
wget http://www.mythic-beasts.com/resources/appletv/mb_boot_tv/diskdev_cmds-332.14.patch.bz2
tar zxf diskdev_cmds-332.14.tar.gz
bunzip2 -c diskdev_cmds-332.14.patch.bz2 | patch -p0
cd diskdev_cmds-332.14
make -f Makefile.lnx
cp fsck_hfs.tproj/fsck_hfs /sbin/fsck.hfsplus
cd /sbin
ln -s mkfs.hfsplus mkfs.hfs
ln -s fsck.hfsplus fsck.hfsn -s fsck.hfsplus fsck.hfs
Then do a "fsck.hfsplus /dev/your_mac_vol". It will take some time, depending upon how much of the fs is screwed, but much much lesser than OS X's boot time fsck. My volume was repaired in around 10 minutes. Reboot, and your shiny OS X should run like a happy kid after a nap.
I simply can't believe that OS X is incapable of fixing its own stuff. If you read the FAT fs code in Linux kernel, somewhere on the top there are two interesting words "fscking l'users", they need to be replicated somewhere.
5 comments:
Wow! And people curse Windows ;)
Interesting. But please go easy on MacOS fsck. It just could be ( am not saying it is ) that the linux driver wrote some stuff in the journal(though you mounted readonly) that OSx could not read :) and then got screwed up. Ofcourse the linux fsck had to work, since it knew what its driver had possibly fsck'd up :).
Be thankful that you did not lose data :) (during the MacOS fsck :).
Amit < I like how storage people take sides of storage people :) Writing stuff in the journal, which the driver doesn't know about, that too in read-only mode...seems far-fetched to me. As far as the fsck for linux, its the Darwin one with patches. So basically MacOS doesn't eat its own dogfood...
and yes, I didnt lose any data during the fsck ;) , except that my mac is now called localhost instead of "parag sarfare's macbook", which is fine, I'm not possessive :P
Well, it might be that the hfs+ fsck doesn't trust the linux driver. I got interested and found a document related to hfs+ on disk structures.
Under the journal section there is a small note labeled Important: which talks about a lastModifiedVersion field in the volume header which is used by MAC-OS fsck to determine whether to replay the log or use traditional fsck. This field is updated by the last driver which "modified" the f.s. Does the linux driver set that (even in readonly mode)? I haven't checked :).
http://developer.apple.com/technotes/tn/tn1150.html#Journal
Anyways, this is just a very very broad and not-so-informed speculation on my part.
About readonly stuff being journaled. I remember reading something somewhere (not abt HFS+ in particular) :) ... let me see if I pull it out sometime later.
Amit < Interesting, read-only stuff being journaled, is unheard of for me. There might be a good reason if somebody does that, for sure.
Linux driver might very well be playing with the version flag, which may have caused the Mac OS fsck to be invoked in the first place.
Post a Comment