Yosemite / DISK UTILITY issue (can't repair)

Discussion in 'OS X Yosemite (10.10)' started by Essaux, Oct 23, 2014.

  1. Essaux macrumors regular

    Joined:
    Oct 23, 2014
    Location:
    South of the Border, West of the Sun
    #1
    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:
    [​IMG]

    In recovery mode:
    [​IMG]

    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.
     
  2. Potatochobit macrumors regular

    Joined:
    Apr 2, 2011
    #2
    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
     
  3. Essaux thread starter macrumors regular

    Joined:
    Oct 23, 2014
    Location:
    South of the Border, West of the Sun
    #3
    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?
     
  4. campyguy macrumors 68040

    Joined:
    Mar 21, 2014
    Location:
    Portland / Seattle
    #4
    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: http://forums.macrumors.com/showpost.php?p=20174860&postcount=273

    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...
     
  5. Ravenis macrumors member

    Joined:
    Feb 4, 2014
    #5
    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
     
  6. Essaux thread starter macrumors regular

    Joined:
    Oct 23, 2014
    Location:
    South of the Border, West of the Sun
    #6
    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.....
     
  7. campyguy macrumors 68040

    Joined:
    Mar 21, 2014
    Location:
    Portland / Seattle
    #7
    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...
     
  8. grahamperrin, Oct 25, 2014
    Last edited: Oct 25, 2014

    grahamperrin macrumors 601

    grahamperrin

    Joined:
    Jun 8, 2007
    #8
    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.

    Not quite.

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

    No …

    No …
     
  9. grahamperrin macrumors 601

    grahamperrin

    Joined:
    Jun 8, 2007
    #9
    "Incorrect size for file temp" alerts can be safely ignored

    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.

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

    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.
     
  10. Weaselboy Moderator

    Weaselboy

    Staff Member

    Joined:
    Jan 23, 2005
    Location:
    California
    #10
    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.

    Code:
    fsck -fy
     
  11. grahamperrin macrumors 601

    grahamperrin

    Joined:
    Jun 8, 2007
    #11
    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.)
     
  12. Weaselboy Moderator

    Weaselboy

    Staff Member

    Joined:
    Jan 23, 2005
    Location:
    California
    #12
    The support doc you linked specifically lists fsck from single user mode as a repair.
     
  13. grahamperrin macrumors 601

    grahamperrin

    Joined:
    Jun 8, 2007
    #13
    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.
     
  14. Essaux thread starter macrumors regular

    Joined:
    Oct 23, 2014
    Location:
    South of the Border, West of the Sun
    #14
    I see. Good to have read this before actually doing anything.


    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.
     
  15. grahamperrin macrumors 601

    grahamperrin

    Joined:
    Jun 8, 2007
    #15
    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.
     
  16. Essaux thread starter macrumors regular

    Joined:
    Oct 23, 2014
    Location:
    South of the Border, West of the Sun
    #16
    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.....

    [​IMG]

    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. :)
     
  17. crjackson2134 macrumors 68020

    crjackson2134

    Joined:
    Mar 6, 2013
    Location:
    Charlotte, NC
    #17
    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.
     
  18. Weaselboy Moderator

    Weaselboy

    Staff Member

    Joined:
    Jan 23, 2005
    Location:
    California
    #18
    Glad it worked out for you. :)
     
  19. grahamperrin macrumors 601

    grahamperrin

    Joined:
    Jun 8, 2007
    #19
    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

    Code:
    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) …​
     
  20. Essaux thread starter macrumors regular

    Joined:
    Oct 23, 2014
    Location:
    South of the Border, West of the Sun
    #20
    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.
     

Share This Page