Yosemite / DISK UTILITY issue (can't repair)

[Essaux]

Hi all, please move this to the right forum if I have misplaced it.

I'm a long time lurker and I usually can solve my problems by reading other people's topics. But this time I can't find anything on the issue that I've encountered.

I'm doing a disk repair and it tells me to reboot into recovery mode and use disk utility in there to fix the problem.

The problem is, it tells me in there that everything is fine. However, when I do a disk utility in Yosemite again, I get the same error over and over again and it tells me to reboot into recovery where I again cannot fix the problem as it tells me everything is fine...

In normal usermode in Yosemite:

In recovery mode:

I also don't understand why there is a partition inside recovery mode. I didn't partition the drive at all.

I disk repaired Macintosh HD and the Base one and both give me no errors in recovery mode.

Hopefully someone on here can help me fix this problem as I really don't like not being able to get rid off this error message when doing a disk repair.

Thanks in advance.

 

[Potatochobit]

I hope you backed up your data or use time machine
do a complete reformat is your best option
if it happens again, you need a new hard drive
btw, you seem to be checking macOSX in that screen shot, not the whole hard drive

 

[Essaux]

I hope you backed up your data or use time machine
do a complete reformat is your best option
if it happens again, you need a new hard drive
btw, you seem to be checking macOSX in that screen shot, not the whole hard drive

Thanks for your reply.

1) I did back-up / use time machine. So in a worst case scenario I can revert back to Mavericks.

However, what I don't understand is why this happened. I did a disk repair before upgrading to Yosemite and everything was fine in Mavericks. Now in Yosemite it isn't....

2) Correct, I did check that one, but I also checked Macintosh HD and both are giving me no errors = fine.

I don't get the error message in Recovery Mode. Thus: I can't fix it?

 

[campyguy]

Your drive has been converted (literally) into a Core Storage Volume (a Logical Group is what you're seeing). There's been some discussion about this "issue" in another thread here - start with this post: https://forums.macrumors.com/posts/20174860/

There's no "reason" why this has happened, and there's "solution". Disk Utility or Terminal is not able to assist you further. I'd been participating, but unsubscribed about a week ago as I feel it's a waste of time "guessing" or "wondering" why this is - I have better things to do with my time. I posed a means to revert my disk - which I've done - in that thread. I'm done postulating "why" as there's no explanation or documentation from Apple. At least, you understand why you're having issues and have another thread to follow...

 

[Ravenis]

OS X base system is the hidden portion for recovery. You need to verify disk for macintosh HD that is greyed out.

Due to the error you got, you will likely need to erase/install

 

[Essaux]

Your drive has been converted (literally) into a Core Storage Volume (a Logical Group is what you're seeing). There's been some discussion about this "issue" in another thread here - start with this post: https://forums.macrumors.com/posts/20174860/

There's no "reason" why this has happened, and there's "solution". Disk Utility or Terminal is not able to assist you further. I'd been participating, but unsubscribed about a week ago as I feel it's a waste of time "guessing" or "wondering" why this is - I have better things to do with my time. I posed a means to revert my disk - which I've done - in that thread. I'm done postulating "why" as there's no explanation or documentation from Apple. At least, you understand why you're having issues and have another thread to follow...

Thank you for your elaborate reply. I'll look into the other thread.

It sucks that Apple releases an OS that by the looks of it is worse than Mavericks. At least as far as I'm concerned.

OS X base system is the hidden portion for recovery. You need to verify disk for macintosh HD that is greyed out.

Due to the error you got, you will likely need to erase/install

Thanks. I did check disk repair for the Macintosh HD too and it didn't give me any errors either when done in Recovery Mode.

As it stands I indeed do need to time machine back to Mavericks and try again.....

 

[campyguy]

Thank you for your elaborate reply. I'll look into the other thread.

It sucks that Apple releases an OS that by the looks of it is worse than Mavericks. At least as far as I'm concerned.


Thanks. I did check disk repair for the Macintosh HD too and it didn't give me any errors either when done in Recovery Mode.

As it stands I indeed do need to time machine back to Mavericks and try again.....

There's no reason to revert to Mavericks. Elsewhere in that thread I linked to are two key Terminal commands - look at my post #36, and a few others following shortly thereafter that describe "what to do".

There's postulation that this conversion to Core Storage is related to Filevault. I used those two Core Storage commands on my two rMBPs and restarted, and all is back to how we've expected - I've had no issues whatsoever since reverting to non-Core Storage volumes. The only key result to look for after executing that first corestorage (or cs) Terminal command is whether or not the volume is "revertible" - if it is, the second command is non-destructive, and it's worked perfectly dozens of times with no loss of data. On the volume you have, the reversion takes maybe 10 seconds plus the time of a restart. Good luck...

 

[grahamperrin]

Live verification of HFS Plus file systems: limitations of Disk Utility with fsck_hfs

If the block count error detailed in the first screenshot is detected only when verification is live – when the file system is locked down – then that error detection may be negligible.

Archived by Apple:

Mac OS X: Disk Utility incorrectly reports disk errors on startup volume (disk)

There's a more recent article – if/when I find it, I'll add a link – but I should not treat it as comprehensive.

… Core Storage Volume (a Logical Group is what you're seeing).

Not quite.

… understand why you're having issues …

What's in the opening post is probably not a problem caused by Core Storage. Certainly it's not specific to Yosemite.

… I indeed do need to time machine back to Mavericks and try again.....

No …

… Due to the error you got, you will likely need to erase/install

No …

 

[grahamperrin]

"Incorrect size for file temp" alerts can be safely ignored

Mac OS X: Disk Utility incorrectly reports disk errors on startup volume (disk)

There's a more recent article – if/when I find it, I'll add a link …

From Apple support article HT1782:

Using Disk Utility to verify or repair disks

Quote:

You may notice some "Incorrect size for file tempnumber" alerts when you attempt to verify or repair a volume using Disk Utility or fsck_hfs with the "-l" option. You can safely ignore these alerts for any "tempnumber" files.

For example, you might see something like this: …

…

Advanced: This issue can happen because the on-disk size for truncated open-unlinked files doesn't get updated before you start a live verification. The presence of these files doesn't cause an issue because their in-memory size is correct. These files are deleted as soon as they are closed. If your computer does not shut down normally, they will be deleted during the next startup.

Additional Information

See these articles as well: … Disk Utility incorrectly reports disk errors on startup volume (disk) …​

– that's the article referenced in my previous post.

I should not treat article HT1782 as comprehensive.

… please move this to the right forum if I have misplaced it. …

I'll flag the opening post with a request for a moderator to move it to the OS X area.

… I can't find anything on the issue that I've encountered. …

Thanks in advance.

You'll probably find nothing in public.

The cases that I discussed (before Yosemite) were fairly reproducible. At least one involved mtmfs – Mobile Time Machine file system, an implementation of NFS (in simple terms, that's a default where Time Machine is enabled on an Apple notebook) – and a download that began in Safari before fsck_hfs began live verification.

 

[Weaselboy]

Hopefully someone on here can help me fix this problem as I really don't like not being able to get rid off this error message when doing a disk repair.

Thanks in advance.

Give this a try. Hold the shift key when booting to get to single user mode. Once you get to the command prompt enter the line below and hit return. Once the command completes enter reboot then so if the problem is gone in Disk Util.

fsck -fy

 

[grahamperrin]

… single user mode …

fsck -fy

The result from fsck_hfs in single user mode will be no different from the result from fsck_hfs with Disk Utility in Recovery OS.

(Assuming that the version of Recovery OS matches the version of OS X.)

 

[Weaselboy]

The result from fsck_hfs in single user mode will be no different from the result from fsck_hfs with Disk Utility in Recovery OS.

(Assuming that the version of Recovery OS matches the version of OS X.)

The support doc you linked specifically lists fsck from single user mode as a repair.

 

[grahamperrin]

Good point. I should clarify.

fsck_hfs in single user mode is appropriate when there's truly a file system inconsistency.

Indications in this case are that there's truly no inconsistency. Unless I'm missing something, every use of Recovery OS Disk Utility reported that the file system appeared to be OK.

In other words (don't take this personally): in this case, it's almost certainly a waste of time.

----

In rare cases, OS X in single user mode is preferable (to Recovery OS) for fsck_hfs, but those cases are very off-topic from what the opening poster has presented.

 

[Essaux]

If the block count error detailed in the first screenshot is detected only when verification is live – when the file system is locked down – then that error detection may be negligible.

Archived by Apple:

Mac OS X: Disk Utility incorrectly reports disk errors on startup volume (disk)

There's a more recent article – if/when I find it, I'll add a link – but I should not treat it as comprehensive.

I see. Good to have read this before actually doing anything.

Give this a try. Hold the shift key when booting to get to single user mode. Once you get to the command prompt enter the line below and hit return. Once the command completes enter reboot then so if the problem is gone in Disk Util.

fsck -fy

Thanks for this tip. If it turns out that it doesn't solve the problem, does it cause any new issues? If not, I'll give it a try for sure.

 

[grahamperrin]

… If it turns out that it doesn't solve the problem, does it cause any new issues? If not, I'll give it a try for sure.

fsck_hfs … fsck_hfs … fsck_hfs … and so on, you have tried it already. In your case, fsck in single user mode will be effectively nothing more than another run of fsck_hfs that's not expected to be any different from using Disk Utility in Recovery OS ;-)

At least part of the following 2011 article remains relevant:

Safe Boot or Disk Utility vs 'fsck' in OS X - CNET

A reminder: the Apple support articles are not comprehensive.

 

[Essaux]

fsck_hfs … fsck_hfs … fsck_hfs … and so on, you have tried it already. In your case, fsck in single user mode will be effectively nothing more than another run of fsck_hfs that's not expected to be any different from using Disk Utility in Recovery OS ;-)

At least part of the following 2011 article remains relevant:

Safe Boot or Disk Utility vs 'fsck' in OS X - CNET

I actually just tried it as Weaselboy suggested and then I just ran disk utility in Yosemite and the error is gone....

I admit, I don't understand why, but it's gone. It didn't work for me via Recovery Disk Utility, but this single user mode and the command did solve it.....

I appreciate all the feedback and help. And I've been reading the articles / links you have posted Graham. Definitely helping me understand it a little bit, but will need to spend more time reading about all of it just for the sake of knowing what is going on a next time.

 

[crjackson2134]

Hi all, please move this to the right forum if I have misplaced it.

I'm a long time lurker and I usually can solve my problems by reading other people's topics. But this time I can't find anything on the issue that I've encountered.

I'm doing a disk repair and it tells me to reboot into recovery mode and use disk utility in there to fix the problem.

The problem is, it tells me in there that everything is fine. However, when I do a disk utility in Yosemite again, I get the same error over and over again and it tells me to reboot into recovery where I again cannot fix the problem as it tells me everything is fine...

In normal usermode in Yosemite:
Image

In recovery mode:
Image

I also don't understand why there is a partition inside recovery mode. I didn't partition the drive at all.

I disk repaired Macintosh HD and the Base one and both give me no errors in recovery mode.

Hopefully someone on here can help me fix this problem as I really don't like not being able to get rid off this error message when doing a disk repair.

Thanks in advance.

At the risk of having Forum experts stating how wrong I am/was, I will tell you this.

I had the exact same issue on a clean install of Yosemite onto an empty drive. I reverted from CoreStorage Logical Volume to what used to be considered a normal HFS+ partition.

The problem went away on next reboot, Disk Utility started functioning as expected, no more errors or grayed out entries.

I don't know the technical issues and/or reasons behind the scenes, and I can't present you with links or articles, but I can tell you that it worked for me.

 

[Weaselboy]

I actually just tried it as Weaselboy suggested and then I just ran disk utility in Yosemite and the error is gone....

Glad it worked out for you.

 

[grahamperrin]

I actually just tried it as Weaselboy suggested …

Thanks, did you keep a photograph, or note, of what was reported by fsck_hfs at the command line?

I guess that a future run (not all future runs) of live verification with Disk Utility will, again, report a block count discrepancy for a .db file. Not necessarily the same name, but probably a .db file.

If you can identify the process that works with that type of file – presumably an app that works with a database – even better.

If you switch off Mobile Time Machine without switching off Time Machine, then you'll probably be unable to reproduce the same type of .db block count discrepancy with live verification.

For reference only

… with Mavericks cases a few months ago:

Summary of test results

1,158,608 blocks for  4.4 MB at one point whilst downloading, then 
    1,428 blocks for  5.8 MB and finally 
   11,212 blocks for 46 MB for the stopped download.

I assume that the operating system predictively allocates enough blocks for the to-be completed download (in this case a 4.75 GB .iso file) relatively soon after download begins – before completion – to ensure that there will be a reasonable amount of free space for completion. Then whilst downloading, the number of blocks allocated can be more optimal.

In my test case

Following the stop (with the download around ten percent complete after more than ten minutes): live verification with fsck_hfs found no inconsistency. Block counts were consistent with actual usage by files.

In the other person's case

Maybe the file system inconsistency arose from a stop of the download before the operating system had an opportunity to reduce the block count (from the high number predicted, to the actual number of blocks for the file) …​

 

[Essaux]

Thanks, did you keep a photograph, or note, of what was reported by fsck_hfs at the command line?

I guess that a future run (not all future runs) of live verification with Disk Utility will, again, report a block count discrepancy for a .db file. Not necessarily the same name, but probably a .db file.

If you can identify the process that works with that type of file – presumably an app that works with a database – even better.

If you switch off Mobile Time Machine without switching off Time Machine, then you'll probably be unable to reproduce the same type of .db block count discrepancy with live verification.

Unfortunately, I did not take a photograph nor a note of what was reported. Should have! But, in all my excitement I just typed reboot and proceeded to check if the error was gone in normal Yosemite Disk Utility.

May I run into the error again in the future and be able to solve it in a similar manner I'll remember to photograph it for future reference.