Issue solved; no physical errors.
These are what I did:
First I analyzed where the error occurred :
...
** Checking catalog file.
Invalid index key
(4, 20220)
Invalid node structure
(4, 38065)
The volume SSD could not be verified completely.
...
fsck
stops while scanning catalog files. Let's try reading fsck_hfs
user manual by executing man fsck_hfs
for clues.
...
-R flags Rebuilds the requested btree. The following flags are supported:
a Attribute btree
c Catalog btree
e Extents overflow btree
...
Let's try rebuilding catalog btree then. fsck_hfs -Rc /dev/rdisk0s2
Results: fsck
does not stop at catalog file check anymore, and the Invalid index key
error disappeared, revealing more errors ( clues! ).
** Checking extents overflow file.
Incorrect block count for file Cache.db-wal
(It should be 114 instead of 119)
** Checking catalog file.
Missing thread record (id = 30291961)
Incorrect number of thread records
Incorrect number of thread records
** Checking multi-linked files
** Checking catalog hierarchy.
Invalid directory item count
(It should be 221 instead of 244)
Invalid volume file count
(It should be 1318081 instead of 1318117)
** Checking extended attributes file.
Invalid node structure
The volume SSD could not be verified completely.
fsck
now stops when checking extended attributes file. Let's try rebuilding the attributes btree with fsck -Ra /dev/rdisk0s2
.
Result(s): All errors, except Invalid node structure
disappeared after the first repair attempt. It shows several invalid nodes, then attempts the second repair, and rechecks. It still shows some invalid nodes, but even less then before.
However the fsck
stops with a message saying that it stops making repair attempts after 3 check failures. I ran fsck -Ra /dev/rdisk0s2
again. It attempts to repair again, then rechecks. No invalid node structure error shows up!
It now makes Invalid volume free blocks count
, Invalid volume file count
, and Invalid volume directory count
errors, but it doesn't stop yet!
After yet another attempt of repair, fsck
finished without any errors.
Shut down. Boot normally without entering single user mode. And it works!
Problem solved by running fsck
several times, rebuilding catalog btree, and attribute btree several times.
Core Storage
If FileVault 2 is enabled for the OS X startup volume, then EfiLoginUI will present a graphic login dialogue before the start of OS X – seconds after the startup chime.
If the startup key combination is timely, then startup should proceed to single user mode after a user's passphrase has been entered.
Firmware
Whilst I don't know the model of your Mac, I can draw attention to a 2011 topic that was resolved in MacRumors forums:
Wireless keyboards
Apple Wireless Keyboards: Using startup keys
If I recall correctly, one type of Apple wireless keyboard is (or was) known to be problematic … at the moment I can't find a reference – sorry.
Best Answer
I was having the same issue, this is how I fixed it.
As we are not able to get to Single User Recovery Mode by using the key sequence, Command + R + S at startup to run
csrutil disable
, it is not taking you to Single User Mode.Start by booting the computer in standard Single User Mode using Command + S. Once you are at the command-line, run the following command to turn off the dGPU:
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
Then reboot your computer by running:
reboot
The dGPU has been disabled, so we can now access the GUI recovery mode. On reboot hold Command + R, and it will take us to the GUI recovery mode. Once there, click on Utility menu and open Terminal, here we can run the
csrutil
command:csrutil disable
To make the dGPU fix persistent through the next update, make sure to run the nvram command a second time, then reboot by running:
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
followed by:
reboot
Boot into Single User Mode with Command + S to continue with the kext moving procedure. Once done, go back to GUI recovery to enable
csrutil
, then reboot.Once Mac fully boots, run nvram one last time as sudo:
sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
and do multiple reboots to test the machine boots back up properly. I have no issues now.