El Capitan Beta 4 update results in flashing question mark

Question

Created Jul ’15

Replies 13

Boosts 0

Views 1.2k

Participants 2

Hello,

My 15" Retina Macbook Pro has been running each successive El Capitan Beta since the first w/o any signficant difficulty, but immediately after updating to Beta 4 it boots to a flashing question mark. A couple of potentially relevant additional facts about my system: 1) I employ FileVault 2) I'm using an aftermarket internal OWC SSD (after the original Apple one failed a number of months ago). Additionally, I did not monitor the entire installation process and only became aware of a problem when returning to the flashing question mark. In other words, I don't know if the installation process had failed at a particular point. Among my troubleshooting steps:

• The boot picker (selecting the option key at boot chime) doesn't detect the presence of the internal SSD at all and only presents the option to net boot to a recovery partition over the internet (which incidentally is to a pretty antiquated OS version).

• I've gone through the normal incantations of clearing PRAM and resetting the SMC and such to no avail.

• I do have an external (Yosemite based) USB thumb drive that boots the machine w/o difficulty... but again doesn't see the internal drive in Disk Utility.

• I removed the internal SSD and placed it in an external USB enclosure and then again booted from the Yosemite based USB drive. This time it does see the presence of the drive, but cannot unlock it in Disk Utility. I supply the normal password (which I am absolutely certain of) and it rejects it. Replacing the SSD back into the internal slot and then selecting the boot picker immediately upon powering on resulted in it briefly seeing the drive, but when attempting to select it the drive dissappeared w/ the "poof" animation (and upon subsequent reboots doesn't reappear).

I'm not as intimite w/ OS X installtion processas a I once was... so I've only speculation to operate off of. My current theory is that something in the installation process (I'd heard that EFI updates might have been included as part of El Capitan beta payload) may set aside the user supplied FileVault password for a known value (so it can sustain reboots for EFI update and OS installation w/o requiring the user to supply the FileVault password at each stage). If this is roughly correct, it'd appear that something failed during the installation process and my normal FileVault password wasn't swapped back in. Again a theory... and it doesn't necessarily explain why the drive isn't even visible most of the time.

While I do normally aggressively back up my primary laptop (and yes I'm more than aware of all of the standard admonitions about beta software) I've been on the road and my last is about 2-3 weeks old... so I'm quite motivated to get my machine back to a working state w/o having to reformat. Any / all suggestions very much appreciated!

Please advise and thanks!

Boost

Answer 1

Max108 OP

Jul ’15

That's a nice and comprehensive explaination of the issue.

When you set up FileVault on the drive it would have given you the options of

Using your iCloud login credentials to unlock the disk or
Setting a seperate password along with the creation of a recovery key as a backup.

Which of the two did you choose? The path to trying to unlock depends a lot on the answer.

(btw. the version of OS X that Internet Recovery Mode is designed to offer you is the one that shipped with your MBP - it would erase your drive anyway though, which you're trying to avoid)

0

Answer 2

esker OP

Jul ’15

The latter of the two I believe (a recovery key).

0

Answer 3

Max108 OP

Jul ’15

Independant from the above, you could put the drive back in the enclosure and use the diskutil repairDisk command from a Terminal window to repair the EFI System Partition and the integrity of CoreStorage partitions (which yours should be due to FileVault). It will also ensure the provisioning of space for bootloaders. You can do this as follows; note that you'll be warned that a partition may be wiped - this is only the EFI partition being referred to, not the partition with OS X 10.11 installed:

In the terminal window type:
diskutil list
Look in the rightmost column of the output under IDENTIFER and note your drive - for the next command I will assume disk1 but you'll obviously need to substitute that for whatever it is identified as. The password it will prompt you for is you login password you use for your thumb-drive installation of Yosemite.
sudo diskutil repairDisk disk1

0

Answer 4

Max108 OP

Jul ’15

To expand on my earlier question, depending on which version of OS X you were running at the time you'd have been presented with one of the following recovery options:

In OS X Yosemite: you can store your FileVault key in iCloud. You can then use your iCloud account name and password to unlock your startup drive or reset your password.
In OS X Mavericks: you can share your FileVault key with Apple by answering a set of security questions. You can then contact Apple Support if you you forget your login password and need to decrypt your startup drive.

Alternatively you would also have been given the option of creating a recovery key that consists of a combination of numbers and letters.

0

Answer 5

esker OP

Jul ’15

The diskutil list command does see the logical volume "Retina HD" on disk16s1... alas, repairDisk results in:

"Problems were encountered during repair of the partition map"

"Error: -69808: Some information was unavailable during an internal lookup"

0

Answer 6

esker OP

Jul ’15

Correction: it found Retina HD on disk16s2 (s1 was EFI)

0

Answer 7

Max108 OP

Jul ’15

Peculiar that there should be 16 disks (0-15) listed before the one containing the Retina HD partition.

Btw. disk16s2is the identifier for a partition, not a disk - the identifier for the disk with that partition on it would be just disk16

Which did you put after the sudo diskutil repairDisk command above?

0

Answer 8

esker OP

Jul ’15

Just disk16 (l didn't specify a slice). Agreed it's peculiar that disks 3-15 are there (but they're present regardless of whether or not I have the external USB enclosure now containing the SSD physically attached or not).

0

Answer 9

Max108 OP

Jul ’15

Accepted Answer

Fair enough.

"Alas" could be apt I'm afraid - a quick Google search for that error isn't encouraging.

On the bright side, it doesn't denote a hardware fault - just a botched FileVault. Erasing the disk is looking increasingly like your only option.

Two things you could try first though (I don't have high hopes, but they're worth a shot):

diskutil cs list
note the uuid; a placeholder IvUUID and password is given in the next command
diskutil cs decryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase password

If that doesn't work you can try

diskutil coreStorage revert 4CC5881F-88B3-42DD-B540-24AA63952E31

0

Answer 10

esker OP

Jul ’15

It seems that one must unlock the volume before decrypting... when I do so (via diskutil cs unlockvolume) it indicates that it successfully unlocks the volume, but it follows w/:

"Error: -69774: Couldn't bring the new Cores Storage Logical Volume online"

I attempted to decryptVolume thereafter anyway... but it indicated that the volume must be unlocked. Trying the revert operation now...

0

Answer 11

Max108 OP

Jul ’15

You're right, I forgot that step.

If you're interested in the various coreStorage (a.k.a. FileVault for all intents and purposes) possibilities, run man diskutil and scroll - about 2/3rds of the way down - to the section indented with coreStorage. You can keep this open in one tab while you work in another.

EDIT: Or you may find it easier to view in a browser: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/diskutil.8.html

0

Answer 12

Max108 OP

Jul ’15

You may still need to append -passphrase password to the revert command, but you'll be lucky if you get anything other than:

Error: -69741: The target disk isn't eligible for reversion ....

0

Answer 13

esker OP

Jul ’15

Unfortunately, I've ended up exhausing the options suggested here... I've left the laptop in the state it's in should someone (hint: Apple) want to investigate what might have happened. I've restored from a ~3 week old backup on a separate system... but will reformat the original in the next few days. Thanks to those who provided suggestions.

0