10-31-2017 03:51 AM
I’ve been trying to update my Macbook Pro (late 2011) to High Sierra, coming from El Capitan. My hard drive is a 512 Gb Crucial MX100 SSD. The process went fine and I was using my computer again when it couldn’t open Preview, so I restarted the machine. I was never able to boot on my regular partition: there is a recurrent error message that says that it can’t access the files, and so it restarts on the install/boot partition until the message comes again.
In Recovery mode (Cmd+r at startup), Trying to Repair the disk with SOS bring the following error: « fsroot tree is invalid », althought it can see the total size of the disk and also the size of space that is occupied by data.
I assume it’s the transition to APFS that has messed up something. I tried to mount the disk into an enclosure and to read it within Gparted in Linux as an external drive: it sees it but doesn’t detect the file system.
I’m quite concerned by the issue as I have a big folder of my studio projects that I forgot to backup - the rest is OK...
Any hint on a possible fix before going to see the professionals?
Thanks a lot!
11-10-2017 09:53 AM
The same happened to me after upgrading to High Sierra on my Mac Book Pro mid-2012.MacBook Pro (13-inch, Mid 2012). OS X 10.13 (17A405). I had a crucial M500 (Firmware MU03).
After migrating from HPFS+ to APFS, and after a couple of days, the OS X refused to boot showing the screen with the folder an the question mark (No File System found). I thought My SSD (M500) was broken because it was 2 years old and it suffered heavy load.
I bought 3 days ago a brand new Crucial MX 3000 275 GB (firmware M0CR060), and I recovered my back-up (I had an updated Time Capsule backup). After a couple of reboots (actually, after upgrading OS X to 10.13.1), it started to fail booting, showing the screen with the forbidden symbol (disk found, but no proper file system found). I checked with diskutil several times after Internet recovery to no avail. According to First Aid, everything was fine. I restored again, I reinstalled the OS X from Recovery mode...nothing.
Even more strange was that sometimes, after shutting down my Macbook and let it several hours to rest, it booted fine. A new reboot was always faulty. Sometimes after several flashes of forbidden symbol/Apple logo it started finally (I guess after several retries).
In the end, nothing worked and I restored to a HDD I had from my original configuration. It worked like a charm and it solved the booting problem (even with APFS, not the option for HDD disks)
So, after my ordeal, I think there is a serious issue between new APFS file System and Crucial (SSD) disks used as a booting disk. I do not know if it is Crucial's firmware or Apple/OS X bug (or even both), but I bought a new disk and it was useless.
I am stuck with my (slow) HDD disk that it is the only way of running High Sierra (10.3).
If someone from Crucial support reads this, I am open to collaborate on troubleshooting testing and providing further data.
11-12-2017 01:57 AM
Additional info. Giving another try, and after updating to OS X 10.13.1 with the same booting issues (no changes), I have begun to profile the issue. If after working with the macbook I shutdown and boot or I reboot the booting issue shows up. If I shutdown the latop, and wait for 1 hour or more, the macbook boots without issues on my Crucial SSD.
So, I guess there is some cache or data stored that prevents from booting properly.
This does not happen with my other HHD disk, using the same OS image from Time Capsule backup.
Further info: I have an external USB 3.0 to SATA disk enclosing. If I boot from the USB 3.0 connection with the same Crucial SSD disk, the issue does not show up.
So, the faulty combination is OS X 10.13.1, Crucial SSD boot disk with APFS filesystem on a SATA interface.
11-13-2017 01:45 AM
I found the 'fix' in the end. Somehow the booting drivers cache was obsolete (or corrupt). This cache is created by the command: kextcache. I guess that was the reason the macbook booted after about 1 hour of resting.
$ sudo kextcache -i /
and it worked like a charm. Issue fixed!