Warnings from disk utility after 3rd kernel panic

Discussion in 'macOS Mojave (10.14)' started by Mac Hammer Fan, Jul 26, 2019.

  1. Mac Hammer Fan macrumors 6502a

    Mac Hammer Fan

    Joined:
    Jul 13, 2004
    Location:
    Belgium
    #1
    I had a third kernel panic in three months with Mojave (now 10.14.6) and bootrom 144.0.0.0.0.

    *** Panic Report ***
    panic(cpu 2 caller 0xffffff801b2bb0ef): initproc exited -- exit reason namespace 2 subcode 0xa description: none
    uuid info:
    0x10ab6e000 uuid = <d3e77331-ace5-349d-a7cc-433d626d4a5b>
    0x100f01000 uuid = <bbd445b6-fba9-3a9c-828f-a112f63e2080>
    Mac OS version:
    18G84

    Kernel version:
    Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64
    Kernel UUID: 982F17B3-0252-37FB-9869-88B3B1C77335
    System model name: MacPro5,1 (Mac-F221BEC8)
    Root disk errors: "Failed to issue COM RESET after 3 attempts. Terminating."

    Drive DX reports no errors.
    But disk utility does now: Should I reformat the SSD?

    NOTE: First Aid will temporarily lock the startup volume.

    Verifying storage system
    Using live mode.
    Performing fsck_apfs -n -x -l /dev/disk6s2
    Checking the container superblock.
    Checking the EFI jumpstart record.
    Checking the space manager.
    Checking the space manager free queue trees.
    Checking the object map.
    Checking volume.
    Checking the APFS volume superblock.
    The volume Macintosh HD was formatted by diskmanagementd (945.260.7) and last modified by apfs_kext (945.275.7).
    Checking the object map.
    Checking the snapshot metadata tree.
    Checking the snapshot metadata.
    Checking snapshot 1 of 1.
    Checking the extent ref tree.
    Checking the fsroot tree.
    Checking volume.
    Checking the APFS volume superblock.
    The volume Preboot was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.7).
    Checking the object map.
    Checking the snapshot metadata tree.
    Checking the snapshot metadata.
    Checking the extent ref tree.
    Checking the fsroot tree.
    warning: directory valence check: directory (oid 0x70050): orphan directory record
    warning: directory valence check: directory (oid 0x70050): orphan directory record

    Checking volume.
    Checking the APFS volume superblock.
    The volume Recovery was formatted by diskmanagementd (945.250.134) and last modified by apfs_kext (945.275.7).
    Checking the object map.
    Checking the snapshot metadata tree.
    Checking the snapshot metadata.
    Checking the extent ref tree.
    Checking the fsroot tree.
    Checking volume.
    Checking the APFS volume superblock.
    The volume VM was formatted by apfs.util (945.250.134) and last modified by apfs_kext (945.275.7).
    Checking the object map.
    Checking the snapshot metadata tree.
    Checking the snapshot metadata.
    Checking the extent ref tree.
    Checking the fsroot tree.
    Verifying allocated space.
    The volume /dev/disk6s2 appears to be OK.
    Storage system check exit code is 0.

    Operation successful.
     
  2. Mac Hammer Fan thread starter macrumors 6502a

    Mac Hammer Fan

    Joined:
    Jul 13, 2004
    Location:
    Belgium
    #2
    The warnings went away after repairing the disk in the recovery mode.
    But I am still worried about the kernel panics. Three in three months. None in the three years before under HFS+
     
  3. Mac Hammer Fan thread starter macrumors 6502a

    Mac Hammer Fan

    Joined:
    Jul 13, 2004
    Location:
    Belgium
    #3
    The problem is not solved!:(
    The warnings are not visible in the recovery mode, but when I start in Mojave in the safe boot mode or normally.
    In the safe mode it takes more than 5 minutes.
    I get the message that the disk need to be repaired.
    "Problems were found with the partition map which might prevent booting"
    And I get these warnings.
    warning: directory valence check: directory (oid 0x70050): orphan directory record
    warning: directory valence check: directory (oid 0x70050): orphan directory record
    Sometimes the computer locks up.
    I already reformatted the drive two months ago. I am desperate.
    I guess returning to HFS+ will be the only solution.
    Any suggestions would be appreciated.
     
  4. NoBoMac Moderator

    NoBoMac

    Staff Member

    Joined:
    Jul 1, 2014
    #4
    Returning to HFS is not the only solution: can always erase/re-format the drive as APFS again and re-install.

    Not sure what to make of the kernel panic message, as no there there, but does read like something that might be repaired via a fresh install, to get rid of whatever corruption is there (and might not even be related to the valence errors).
     
  5. Honza1 macrumors 6502

    Joined:
    Nov 30, 2013
    Location:
    US
    #5
    This does not seem usual APFS experience. It looks more like hardware issue to me. My MBP 2017 SSD died few weeks ago. It looked like APFS file system problem. So I followed what Apple suggests - copy data off the drive (I was lucky, I could clone the drive using Carbon Copy Cloner with full functionality), try to fix using Disk Utility, and if it fails, reformat the drive. This is standard suggestion from Apple you can find on their web site (and is same for APFS or HFS+).
    I copied the data and tried to fix file system when booted from external drive. Could not be fixed. So I tried to reformat the drive and computer died mid-way formatting. Drive corrupted and any time I tried reformat the drive (to any format), computer reboots mid way. I took to to Apple Store Gurus and they replaced (I have AppleCare) the whole mainboard with SSD. It was bad SSD = hardware error. It would have been problem with HFS+ also even though it looked like APFS problem.
    So, while you seem to be pointing your finger on APFS, there is no proof that it is APFS bug in any way. I had HFS+ formatted disks and SSD die on me, some really badly and some slowly. I had some HFS+ file systems get corrupted and fixed by DiskUtility - or not fixed by Disk Utility (and needed reformat). And I had now the same happen with APFS SSDs.

    All SSDs & Hard disks will eventually die. All file systems will eventually get corrupted. It is draw of the luck when it happens to your system. It is life... Use reliable backup, reformat the drive, replace failed hardware, if needed.
     
  6. Mac Hammer Fan, Aug 1, 2019
    Last edited: Aug 1, 2019

    Mac Hammer Fan thread starter macrumors 6502a

    Mac Hammer Fan

    Joined:
    Jul 13, 2004
    Location:
    Belgium
    #6
    DriveDX reports that the SSD is OK. I will reformat the drive for the second time in three months.
    Perhaps the last supplemental Mojave update will solve the sleep wake up problem.
    I have no issues with APFS in my MacBook Pro 2015, only in my MacPro 5,1 with SATA III pci-card OWC Accelsior / Samsung EVO 850 SSD. Perhaps the OWC Accelsior is not fully compatible with APFS...
     
  7. NoBoMac Moderator

    NoBoMac

    Staff Member

    Joined:
    Jul 1, 2014
    #7
    Re: OWC: might be onto something there. Seen posts/threads where mention of OWC, Mojave, and MacPros are "troublesome".

    Might want to dig through the MacPro sub-board and possibly Mojave on unsupported systems thread (as might find some general OWC issues in there as well).
     
  8. Mac Hammer Fan, Aug 2, 2019
    Last edited: Aug 16, 2019 at 2:26 PM

    Mac Hammer Fan thread starter macrumors 6502a

    Mac Hammer Fan

    Joined:
    Jul 13, 2004
    Location:
    Belgium
    #8
    I reformatted the drive APFS for the last time and copied the whole disk back from a Carbon Copy Clone. DriveDX reports again that the SSD is OK. Disk utility reports no errors now. We'll see in a couple of weeks. Perhaps the supplemental 10.14.6 update will solve the problem. Fingers crossed the kernel panics after wake up from sleep and the error warnings will be gone.
     
  9. Mac Hammer Fan thread starter macrumors 6502a

    Mac Hammer Fan

    Joined:
    Jul 13, 2004
    Location:
    Belgium
    #9
    10.14.6 supplemental update seems to solve the problem. No kernel panics and no disk damage after sleep/wake up yet. :)
     

Share This Page

8 July 26, 2019