I am bumping this so I can also get a "fix" if there is one. We are a school district and have about 450 machines out of 1200 (MacBook Pros) that have this issue also. When we set an EFI password, at some random point when the machine is rebooted it shows no HD. The behavior is repeated on every subsequent reboot. Typing in the EFI password allows us to see the HD and boot from it.
We remove the EFI password and give it back to the end users. I would much rather keep the EFI password in place.
Also, thanks in advance!

After some digging, I found this out.

The Mac OS X Yosemite recovery update 1.0 is known to cause this, we should check to see if the update is installed shortly after. Hope this helps someone!!

We are also seeing this issue. We have turned off EFI password policy but that is not what we want to do. With nearly 4000 machines, either supporting the question mark folder issue or removing the EFI password are bad resolutions.

I don't understand the Yosemite Update 1.0 note in the previous post. Someone please explain.

@chendricks the startup disk value is stored in PRAM, when the EFI password is enabled, without intervention, the system will only look for that volume to startup from. The Yosemite Recovery Update unceremoniously overwrites the Recovery partition with a new one, so that the value stored in PRAM is no longer valid, for the former Recovery Partition in order to unlock FileVault. So when the system restarts the volume it wants is no longer present, and returns a flashing folder with a question mark.

@htse With that said, are you seeing that it is deploying reliably without affecting the current startup disk as long as it's deployed after the recovery update has been applied?

We have about 700 MacBook Airs having the same issue after target imaging them.

@cstout It's been a while, but I think I ended up putting the RecoveryHDUpdate.pkg into a disk image, which puts it down into /tmp, followed by a script that uses installer to install the package, versus letting the jamf binary use jamf install to install the package.

any update on this? we noticed this when we pushed out the efi password policy to machines that do not have it set. So far about ~10 machines have had this issue.

Our solution is to boot into recovery mode and select the startup disk. Need to unlock the start up disk since its encrypted. Then reboot.

If we did an Option boot and select the start up disk, the next restart would still show the flashing folder.

I haven't tried this, but what if you ran systemsetup -setstartupdisk at the conclusion of installing the updated Recovery HD package?

@AlistairCarr

There is a defect bug in 9.8.1 when you use the built-in firmware set , it will cause the computer to lose the startup disk selection. The advice is to talk to your TAM to report it .

i use this script to attach to bless the volume , my volume are called Macintosh HD or Mac HD

!/bin/bash

mac_partition_Name=$( diskutil list | grep -i mac | awk '/Apple_HFS/{print $NF}' )

mac_partitions=$(/usr/sbin/diskutil info "$mac_partition_Name" | /usr/bin/grep "Device Node" | /usr/bin/awk '{print $3}')

/usr/sbin/bless --device "$mac_partitions" --setBoot

exit 0

@acorn When doing the option boot, you can hold down ctrl while selecting the boot disk. This will turn the icon into a "circular arrow" and set the boot disk permanently.

We're running into this as well, with El Capitan 10.11.6, and JAMF 9.93. Solution is to restart using control to set the boot disk, but that requires touching each one at random times. May have to remotely remove the EFI password, which isn't a great option.

Push out the bless command with the firmware password set

bless --mount /Volumes/Macintosh HD -setBoot

@ccerrudo did the solution @boberito work for you? I'm in the process of implementing this now.

I did a belt/suspenders thing:

1. I implemented @boberito 's script in the imaging process to run at reboot
2. I also then ran the script on a daily basis to all Macbooks in the scope for a week.

Haven't seen the issue pop up lately, so hopefully we're past it!

WoW, Missing startup disk after policy execution. Jamf should put some fine print on some of these payloads.

You might run a PreInstall package with this:

!/usr/bin/expect

spawn firmwarepasswd -setpasswd
expect { "Enter new password:" { send "PASSWORD " exp_continue } "Re-enter new password:" { send "PASSWORD " exp_continue }
}

And then a PostInstall to make sure startup volume is set correctly:

!/bin/bash

/usr/sbin/bless --device "$(diskutil info / | grep "Device Node:" | awk '{print $3}')" --setBoot

@thomasknudsen Thanks