Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Level 1

6 points

Why does my macbook air run fsck every boot

Sadly, I don't think there really is an answer to my question.

Anyway. Some time ago I noticed that my macbook air runs fsck on every boot (which one can see by going to verbose boot mode-cmd-v on boot). This check takes around 10 minutes, which is quite annoying if your computer was rebooted in the middle of giving a talk (that is a different story, though).

So, I tried to track down why this happens.

1. My root system is HFS journalled.

2. First, I booted into rescue mode, and did a check on the disk with DiskUtility. There were indeed some errors to be corrected. They were fixed, and then a second check completed successfully. Still, every boot did fsck.

3. I booted into single user mode, and ran fsck -fy. Now nothing was detected, disk is healthy. Still, every boot did fsck.

4. I tried to track down, who runs fsck? It started after launchd, so possibly that is the right place. I looked through /System/Library/LaunchDaemons - nothing ran fsck.

5. Finally, grep on binaries revealed that launchctl (!!!!) runs fsck.

http://www.opensource.apple.com/source/launchd/launchd-442.26.2/support/launchct l.c revealed that it indeed does.

The relevant code looks like this:

---

if (!is_safeboot()) {

#if 0

/* We have disabled this block for now. We need to revisit this optimization after Leopard. */

if (sfs.f_flags & MNT_JOURNALED) {

goto out;

}

#endif

launchctl_log(LOG_NOTICE, "Running fsck on the boot volume...");

if (fwexec(fsck_tool, &status) != -1) {

---

So, it seems that the "optimization" of not running fsck on every single boot on a journalled filesystem is for now commented out.

So, my conclusion is that for now OSX is designed to run fsck on the boot volume every single boot. Whcih on my system takes 10 minutes.

My questions are:

1. Why?

2. Obviously, currently this can not be disabled. Why?

3. Is it normal that fsck take 10 minutes on an SSD with 250GB?

4. If yes, does boot always take 10 minutes?

MacBook Air, Mac OS X (10.7.5)

Posted on Feb 22, 2013 7:45 AM

29 replies

mlachmann Author

Level 1

6 points

Feb 23, 2013 1:19 PM in response to Linc Davis

I rebooted non-verbose, (but without dirhelper...). It now takes 5 seconds or so 🙂

Here is the relevant part f "all messages:

2/23/13 10:12:57.000 PM bootlog: BOOT_TIME 1361653977 0

2/23/13 10:12:59.000 PM kernel: PMAP: PCID enabled

2/23/13 10:12:59.000 PM kernel: Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64

2/23/13 10:12:59.000 PM kernel: vm_page_bootstrap: 989413 free pages and 50971 wired pages

2/23/13 10:12:59.000 PM kernel: kext submap [0xffffff7f80736000 - 0xffffff8000000000], kernel text [0xffffff8000200000 - 0xffffff8000736000]

2/23/13 10:12:59.000 PM kernel: zone leak detection enabled

2/23/13 10:12:59.000 PM kernel: standard timeslicing quantum is 10000 us

2/23/13 10:12:59.000 PM kernel: mig_table_max_displ = 73

2/23/13 10:12:59.000 PM kernel: TSC Deadline Timer supported and enabled

2/23/13 10:12:59.000 PM kernel: AppleACPICPU: ProcessorId=1 LocalApicId=0 Enabled

2/23/13 10:12:59.000 PM kernel: AppleACPICPU: ProcessorId=2 LocalApicId=2 Enabled

2/23/13 10:12:59.000 PM kernel: AppleACPICPU: ProcessorId=3 LocalApicId=1 Enabled

2/23/13 10:12:59.000 PM kernel: AppleACPICPU: ProcessorId=4 LocalApicId=3 Enabled

system.log:

Feb 23 22:12:57 localhost bootlog[0]: BOOT_TIME 1361653977 0

Feb 23 22:12:58 localhost com.apple.launchd[1]: *** launchd[1] has started up. ***

Feb 23 22:12:58 localhost com.apple.launchd[1] (com.apple.powerd): Unknown value for key POSIXSpawnType: Interactive

Feb 23 22:12:58 localhost com.apple.launchd[1] (com.apple.sandboxd): Unknown value for key POSIXSpawnType: Interactive

Feb 23 22:13:00 localhost UserEventAgent[8]: starting CaptiveNetworkSupport as SystemEventAgent built May 25 2011 12:27:35

Feb 23 22:13:00 localhost UserEventAgent[8]: CaptiveNetworkSupport:CreateInterfaceWatchList:2788 WiFi Devices Found. 🙂

Feb 23 22:13:00 localhost UserEventAgent[8]: CaptiveNetworkSupport:CaptivePublishState:1211 en0 - PreProbe

Feb 23 22:13:00 localhost UserEventAgent[8]: CaptiveNetworkSupport:CaptiveSCRebuildCache:81 Failed to get service order

Feb 23 22:13:00: --- last message repeated 1 time ---

Feb 23 22:13:00 localhost UserEventAgent[8]: CaptiveNetworkSupport:CaptivePublishState:1211 en0 - PreProbe

Feb 23 22:13:00 localhost UserEventAgent[8]: CaptiveNetworkSupport:CaptiveSCRebuildCache:81 Failed to get service order

Feb 23 22:13:00: --- last message repeated 1 time ---

Feb 23 22:13:00 localhost mDNSResponder[9]: mDNSResponder mDNSResponder-320.16 (Jul 19 2012 21:07:07) starting OSXVers 11

Feb 23 22:13:00 localhost airportd[23]: _processDLILEvent: en0 attached (down)

Feb 23 22:13:01 localhost UserEventAgent[8]: CaptiveNetworkSupport:CaptiveSCRebuildCache:81 Failed to get service order

Feb 23 22:13:01: --- last message repeated 1 time ---

Feb 23 22:13:01 localhost UserEventAgent[8]: CaptiveNetworkSupport:CaptivePublishState:1211 en0 - PreProbe

Feb 23 22:13:01 ghostwheel configd[13]: setting hostname to "ghostwheel.local"

Feb 23 22:13:01 ghostwheel configd[13]: network configuration changed.

Feb 23 22:13:01 ghostwheel systemkeychain[24]: done file: /var/run/systemkeychaincheck.done

kernel.log:

Feb 23 22:12:59 localhost kernel[0]: PMAP: PCID enabled

Feb 23 22:12:59 localhost kernel[0]: Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64

Feb 23 22:12:59 localhost kernel[0]: vm_page_bootstrap: 989413 free pages and 50971 wired pages

Feb 23 22:12:59 localhost kernel[0]: kext submap [0xffffff7f80736000 - 0xffffff8000000000], kernel text [0xffffff8000200000 - 0xffffff8000736000]

Feb 23 22:12:59 localhost kernel[0]: zone leak detection enabled

Feb 23 22:12:59 localhost kernel[0]: standard timeslicing quantum is 10000 us

Feb 23 22:12:59 localhost kernel[0]: mig_table_max_displ = 73

Feb 23 22:12:59 localhost kernel[0]: TSC Deadline Timer supported and enabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=1 LocalApicId=0 Enabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=2 LocalApicId=2 Enabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=3 LocalApicId=1 Enabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=4 LocalApicId=3 Enabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=5 LocalApicId=255 Disabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=6 LocalApicId=255 Disabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=7 LocalApicId=255 Disabled

Feb 23 22:12:59 localhost kernel[0]: AppleACPICPU: ProcessorId=8 LocalApicId=255 Disabled

Feb 23 22:12:59 localhost kernel[0]: calling mpo_policy_init for TMSafetyNet

Feb 23 22:12:59 localhost kernel[0]: Security policy loaded: Safety net for Time Machine (TMSafetyNet)

Feb 23 22:12:59 localhost kernel[0]: calling mpo_policy_init for Sandbox

Feb 23 22:12:59 localhost kernel[0]: Security policy loaded: Seatbelt sandbox policy (Sandbox)

Feb 23 22:12:59 localhost kernel[0]: calling mpo_policy_init for Quarantine

Feb 23 22:12:59 localhost kernel[0]: Security policy loaded: Quarantine policy (Quarantine)

Feb 23 22:12:59 localhost kernel[0]: MAC Framework successfully initialized

Feb 23 22:12:59 localhost kernel[0]: using 16384 buffer headers and 10240 cluster IO buffer headers

Feb 23 22:12:59 localhost kernel[0]: IOAPIC: Version 0x20 Vectors 64:87

Feb 23 22:12:59 localhost kernel[0]: ACPI: System State [S0 S3 S4 S5]

Feb 23 22:12:59 localhost kernel[0]: PFM64 (36 cpu) 0xf10000000, 0xf0000000

Feb 23 22:12:59 localhost kernel[0]: [ PCI configuration begin ]

Feb 23 22:12:59 localhost kernel[0]: console relocated to 0xf10000000

Feb 23 22:12:59 localhost kernel[0]: PCI configuration changed (bridge=11 device=1 cardbus=0)

Feb 23 22:12:59 localhost kernel[0]: [ PCI configuration end, bridges 8 devices 13 ]

Feb 23 22:12:59 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 008B

Feb 23 22:12:59 localhost kernel[0]: AppleIntelCPUPowerManagement: (built 16:32:09 Aug 23 2012) initialization complete

Feb 23 22:12:59 localhost kernel[0]: mbinit: done [64 MB total pool size, (42/21) split]

Feb 23 22:12:59 localhost kernel[0]: Pthread support ABORTS when sync kernel primitives misused

Feb 23 22:12:59 localhost kernel[0]: com.apple.AppleFSCompressionTypeZlib kmod start

Feb 23 22:12:59 localhost kernel[0]: com.apple.AppleFSCompressionTypeDataless kmod start

Feb 23 22:12:59 localhost kernel[0]: com.apple.AppleFSCompressionTypeZlib load succeeded

Feb 23 22:12:59 localhost kernel[0]: com.apple.AppleFSCompressionTypeDataless load succeeded

Feb 23 22:12:59 localhost kernel[0]: AppleIntelCPUPowerManagementClient: ready

Feb 23 22:12:59 localhost kernel[0]: BTCOEXIST off

Feb 23 22:12:59 localhost kernel[0]: wl0: Broadcom BCM4353 802.11 Wireless Controller

Feb 23 22:12:59 localhost kernel[0]: 5.106.198.19

Feb 23 22:12:59 localhost kernel[0]: USBMSC Identifier (non-unique): 000000000310 0x5ac 0x8404 0x310

Feb 23 22:12:59 localhost kernel[0]: rooting via boot-uuid from /chosen: 8D40992E-5B3C-3C9F-9E15-A4DEB0DC76C9

Feb 23 22:12:59 localhost kernel[0]: Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResourceMatch</key><string ID="2">boot-uuid-media</string></dict>

Feb 23 22:12:59 localhost kernel[0]: Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/SATA@1F,2/AppleIntelPchS eriesAHCI/PRT0@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOB lockStorageDriver/APPLE SSD SM256C Media/IOGUIDPartitionScheme/Customer@2

Feb 23 22:12:59 localhost kernel[0]: BSD root: disk0s2, major 14, minor 2

Feb 23 22:12:59 localhost kernel[0]: Kernel is LP64

Feb 23 22:12:59 localhost kernel[0]: AppleUSBMultitouchDriver::checkStatus - received Status Packet, Payload 2: device was reinitialized

Feb 23 22:12:59 localhost kernel[0]: [IOBluetoothHCIController::setConfigState] calling registerService

Feb 23 22:12:59 localhost kernel[0]: USBF: 2. 73 IOUSBInterface[0xffffff800adb6800]::joinPMtree - could not find the hub device

Feb 23 22:13:00 localhost kernel[0]: AirPort_Brcm4331: Ethernet address 10:40:f3:8f:21:5c

Feb 23 22:13:00 localhost kernel[0]: IO80211Controller::dataLinkLayerAttachComplete(): adding AppleEFINVRAM notification

Feb 23 22:13:00 localhost kernel[0]: IO80211Interface::efiNVRAMPublished():

Feb 23 22:13:01 localhost kernel[0]: in func createVirtualInterface ifRole = 1

Feb 23 22:13:01 localhost kernel[0]: Created virtif 0xffffff800afe3400 p2p0

Feb 23 22:13:01 ghostwheel kernel[0]: AirPort: Link Down on en0. Reason 1 (Unspecified).

Feb 23 22:13:02 ghostwheel kernel[0]: AVVideoCard::probe()

Feb 23 22:13:02 ghostwheel kernel[0]: Previous Shutdown Cause: 5

Feb 23 22:13:02 ghostwheel kernel[0]: SMC::smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode

Feb 23 22:13:03 ghostwheel kernel[0]: AVVideoCard::start()

Feb 23 22:13:03 ghostwheel kernel[0]: en0: 802.11d country code set to 'GB'.

fsck_hfs.log:

/dev/rdisk0s2: fsck_hfs run at Sat Feb 23 22:13:00 2013

/dev/rdisk0s2: ** /dev/rdisk0s2 (NO WRITE)

/dev/rdisk0s2: ** Root file system

/dev/rdisk0s2: Executing fsck_hfs (version diskdev_cmds-540.1~25).

/dev/rdisk0s3: fsck_hfs run at Sat Feb 23 22:13:01 2013

/dev/rdisk0s3: ** /dev/rdisk0s3 (NO WRITE)

/dev/rdisk0s3: Executing fsck_hfs (version diskdev_cmds-540.1~25).

QUICKCHECK ONLY; FILESYSTEM CLEAN

Any other logs that would be relevant?

Do you want to see a boot WITH dirhelper?

Linc Davis

Level 10

209,547 points

Feb 23, 2013 1:42 PM in response to mlachmann

Do you want to see a boot WITH dirhelper?

If you've isolated the problem to that, then yes. dirhelper(8) creates and maintains the /var/folders hierarchy, which includes per-user cache and temp directories. You might be able to solve the problem, if that's where it lies, by deleting that directory and rebooting. It should be recreated from scratch.

mlachmann Author

Level 1

6 points

Feb 23, 2013 1:53 PM in response to Linc Davis

Yes, it seems that was it! I deleted /var/folders, and reactivated /usr/libexec/dirhelper, and boot is still quick.

Thank you!

Too bad launchctl isn't a bit more verbose in explaining what it does at every step. This would have been so much easier if there was a log message like: running dirheper.....

(And, of course, if all these things weren't hard-coded into lauchctl, but instead given in some config file.....)

Anyway, my problem is solved, I think. Thanks!

Oct 30, 2013 5:08 PM in response to Linc Davis

Thanks Linc! I had exact same problem on my new retina 13" MBP. Of course running Mavericks. I had migrated from my old 2009 Mbp, also running Mavericks. I also thought the delay was from fsck, since that's where it stalled in verbose boot. I used sudo to move the /var/folders to /var/folders_old and rebooted. Problem solved! I assume using the TM backup put some cruft in the folders directory

I was going crazy because the fsck didn't show up in the syslog.

Again, tremendous thanks. I now have to fast boot I expected with the new SSD

Oct 30, 2013 6:29 PM in response to Gene Loefer

Spoke too soon. Problem returned on next reboot. :-((

Oct 31, 2013 11:04 AM in response to mlachmann

I was having the same problem: 8 minute boot time, which went to 10 seconds if I renamed /usr/libexec/dirhelper. This was on a brand-new Retina MacBook Pro that I had migrated to from another Mac. I did a number of tests that revealed the problem only occurred in I logged in to my account before rebooting. If I rebooted without ever leaving the login screen, the boot would be fast.

That let me to suspect that one of my login items was causing the trouble. I searched /var/folders for likely candidates and discovered complete copies of WDDriveUtilityHelper and WDSecurityHelper in one of the /var/folders subdirectories.

I went to System Preferences > Users & Groups > Login Items and removed the two WD helpers from the list. I also manually deleted the two apps from /var/folders. I've done several reboots and logins since, and so far that has fixed the problem.

I hope this helps someone else. Many thanks to those who figured out that dirhelper was involved, or I might have taken a very long time to track this down.

Dec 4, 2013 9:14 AM in response to Stuart Malone1

Stuart, thank you. I had this exact problem, and yours was the exact fix. This is the only resource I found on the Web with a correct diagnosis and solution.

Dec 4, 2013 9:43 AM in response to Stuart Malone1

Stuart Malone1

I went to System Preferences > Users & Groups > Login Items and removed the two WD helpers from the list

Your information seems extremely closely linked to my investigation into fsck in here, NAMELY in accord with any WD software, thanks for the info

https://discussions.apple.com/thread/5475136?start=795&tstart=0

mlachmann

In the code for launchctl, there is a routine called fix_bogus_file_metadata(), which will

complain if /Library/StartupItems is not present, and recreate it. This is called AFTER fsck finished.

thanks for that 😉

Dec 5, 2013 6:29 AM in response to mlachmann

mlachmann wrote:

...

--

fsck_hfs.log:

--

/dev/rdisk0s2: fsck_hfs run at Sat Feb 23 22:13:00 2013

/dev/rdisk0s2: ** /dev/rdisk0s2 (NO WRITE)

/dev/rdisk0s2: ** Root file system

/dev/rdisk0s2: Executing fsck_hfs (version diskdev_cmds-540.1~25).

/dev/rdisk0s3: fsck_hfs run at Sat Feb 23 22:13:01 2013

/dev/rdisk0s3: ** /dev/rdisk0s3 (NO WRITE)

/dev/rdisk0s3: Executing fsck_hfs (version diskdev_cmds-540.1~25).

QUICKCHECK ONLY; FILESYSTEM CLEAN

--
...

I have been trying to diagnose a similar fsck_hfs problem on external drives in another thread. The conditions are that some external drives/partitions appear to fail to mount because of very long fsck_hfs runs (e.g. 8min) that lock the drive/partition until completed. The following links are to posts with more details of my testing.

https://discussions.apple.com/thread/5475136?answerId=23936117022#23936117022

https://discussions.apple.com/thread/5475136?answerId=23963515022#23963515022

I’ve been monitoring the system and fsck_hfs logs on my MBP. As you’ve posted, fsck_hfs is run on every partition of drives when they are mounted. Usually this is very quick and not noticeable. For example here is the most recent boot of my MBP with 3 partitions on the internal drive.

/dev/rdisk0s2: fsck_hfs started at Wed Dec 4 22:48:19 2013

/dev/rdisk0s2: /dev/rdisk0s2: ** /dev/rdisk0s2 (NO WRITE)

/dev/rdisk0s2: ** Root file system

/dev/rdisk0s2: Executing fsck_hfs (version hfs-226.1.1).

/dev/rdisk0s2: fsck_hfs completed at Wed Dec 4 22:48:19 2013

/dev/rdisk0s3: fsck_hfs started at Wed Dec 4 22:48:20 2013

/dev/rdisk0s3: /dev/rdisk0s3: ** /dev/rdisk0s3 (NO WRITE)

/dev/rdisk0s3: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk0s3: fsck_hfs completed at Wed Dec 4 22:48:20 2013

/dev/rdisk0s4: fsck_hfs started at Wed Dec 4 22:48:21 2013

/dev/rdisk0s4: /dev/rdisk0s4: ** /dev/rdisk0s4 (NO WRITE)

/dev/rdisk0s4: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk0s4: fsck_hfs completed at Wed Dec 4 22:48:21 2013

But occasionally the first QUICKCHEK indicates that the file system on the external drive is “dirty” and a much longer fsck_hsf run is initiated e.g. 8min in my case. I have not determined the cause of the “dirty” file system. But there is some indication that it may be related to Spotlight. When I excluded the problematic drive from Spotlight (via the privacy panel) the incidence of long fsck_hfs runs during testing went from frequent (several times a day) to nearly absent (only twice in several days).

Your post does not include the last line of the fsck_hfs runs that would tell how long the fsck_hfs process ran. Did you just clip that info or is it absent in your log?

—-GetRealBro

p.s. I should note that I have NOT lost any data on any external drive. But Disk Utilty has told me numerous times that external drives are so badly damaged that it could not verify or repair them. DU simply incorrectly reports the condition of drives when they are locked by a long fsck_hfs run.

Feb 15, 2014 4:09 PM in response to Stuart Malone1

Thank you so much.

Looked 3 days to solve my problem.

Removing WDDriveUtilityHelper and WDSecurityHelper from "Login items" made my boot much faster.

Now, it`s 19 seconds instead of 146 seconds until the desktop ist visible the first time... 😁

Thanks again.

Jul 6, 2014 5:36 AM in response to Stuart Malone1

Thats it!

Thanks a lot! Fixed with your fix.

Disabled WDsecurityhelper on startup user logon items. Deleted /var/folders. Rebooted, and all is fine.

Thanks,

alexkey

Level 1

0 points

Jul 11, 2014 7:07 AM in response to Stuart Malone1

Stuart,

Thank you for this information. Solved my problem with slow boot immediately.

Excellent post.

Alex.

Mark23

Level 4

994 points

Aug 21, 2014 1:23 AM in response to Linc Davis

Don't delete /var/folders as it will not be recovered.

Entering sudo mv /usr/libexec/dirhelper /usr/libexec/dirhelper.unused as the topic starter mentioned is sufficient.

If you did delete /var/folders the easiest restore is from a time capsule backup. Otherwise start up from the recovery partition by pressing command + R immediately after power on..

nzgreg

Level 1

0 points

Sep 12, 2014 6:00 PM in response to Linc Davis

I'm running OS X 10.9.4 on a MacBook Retina 2012 and hit this problem every time I reboot now. The system stalls on startup forever just after fsck_hfs runs (when this thread says dirhelper runs)... the verbose boot log also says 'pci pause sdxc' at the stall. I have to boot to the recovery partition, run a terminal and delete or rename /var/folders to be able to boot again, as suggested above.

I've run disk utils, verified/fixed disk permissions, verified the disk, run apple hardware tests, and everything else I have found to try to diagnose the cause - so far no problems found. I don't have anything other than iTunesHelper in the login items either. So, I don't know what's causing the problem in /var/folders, but it's happening almost every time I restart.

This thread is also the only mention I've seen of the problem/solution anywhere, so it sounds like a reasonably obscure problem. I'm ready to abandon the OS and install a fresh Yosemite DP to get away from it. Thanks for the tip to get the system booting again - it certainly saved some sanity.

Why does my macbook air run fsck every boot