Sounds like a separate issue. I'm not encountering that. Maybe check your base image?
Don't install Yosemite, it's a giant turd. I realize this is not helpful to your problem, I'm sorry.
@chris.hotte I guess I'm not following your solution. Are you saying to boot to single user mode and perform the commands written in your original response? If I have a Mac thats already not booting I can't push commands to it, even with a login script because its not getting that far.
I'm confident it will work, I just need to better understand how to implement it.
Thanks!
Hey @mklos look at @chris.hotte's post again above the code block. He boots into single user mode then uses nano to create a rc.server file at /etc/ and then puts the script in that code block in and saves it.
Hey @mklos look at @chris.hotte's post again above the code block. He boots into single user mode then uses nano to create a rc.server file at /etc/ and then puts the script in that code block in and saves it.
That pretty much summarizes it. If you have a remote box, that presents an issue. Such as helping someone on the phone. You can direct them through the steps. Obviously the echo command was just me having a bit of fun - but something in there helps to identify the code is executing during a verbose boot.
You can also have a remote user attempt many repeat many hard boots until they get to the gui and use terminal to add the /etc/rc.server script by hand, or you can remote in at that point.
Not much else for it.
@chriscollins Okay I guess I did do it right but sometimes it boots and other times it doesn't. This only seems to be an issue if someone just holds the power button down instead of shutting it down naturally. I'll keep monitoring it. Hopefully 10.10.2 fixes the issue.
@tnielson
Don't install Yosemite, it's a giant turd. I realize this is not helpful to your problem, I'm sorry.
Pre-installs...
Business requirements...
That being said I've pretty much said the same thing about every new release. 10.5, 10.7 being pretty exceptional... and not in a good way. If I could, my vote would be 10.6.8 forever! But to be fair most releases get pretty good around X.X.8. Then its time for the next one. *sigh*
@chris.hotte
That pretty much summarizes it. If you have a remote box, that presents an issue. Such as helping someone on the phone. You can direct them through the steps. Obviously the echo command was just me having a bit of fun - but something in there helps to identify the code is executing during a verbose boot.
You can also have a remote user attempt many repeat many hard boots until they get to the gui and use terminal to add the /etc/rc.server script by hand, or you can remote in at that point.
Not much else for it.
Okay I'll just keep an eye on it...like I said hopefully Apple fixes this issue in 10.10.2. It sounds like their well aware of the issue from reading around support forums.
That being said I've pretty much said the same thing about every new release. 10.5, 10.7 being pretty exceptional... and not in a good way. If I could, my vote would be 10.6.8 forever!
If I remember correctly, wasn't 10.6 mostly an under the hood OS update? Not many new improvements/features but just code cleanups, fixing issues with the OS, etc. Basically setting the OS up for future updates and squashing all the little bugs that annoy us users. Maybe Apple needs to do this again. They could stand doing the same thing with iOS but thats a different topic for a different time.
Used @chris.hotte's suggestion and it totally fixed a Mac I thought was a goner.
Again:
external image link
I understand @chris.hotte. We do a thin image on hardware that only works with Yosemite... there will be no upgrading to it in any way, however.
For the record, I really like 10.9.5. 10.7.5 was my previous favorite. The almighty 10.6.8 as well, for SMB connections only.
We just had a good success with @chris.hotte suggestion.
So would adding that rc.server script to all yosemite machines in /etc resolve the issue? Thinking about how to apply this widespread to prevent further issues.
Safe Mode, Resetting PRAM, or fixing Disk Permissions does not fix the issue.
chris.hotte 's fix works great - /usr/sbin/BootCacheControl jettison
@chris.hotte Could you tell me the exact steps you took. ie how to get into single user mode and what are the exact commands you ran in the terminal.
Sorry I am not very familair with osx and all of our AD bound macs have this issue.
@chris.hotte thanks for posting about /usr/sbin/BootCacheControl jettison command.
Can this be setup to run as a logout hook? As that would be ideal as it could be turned off in future from the JSS as a policy if 10.10.2 fixes these startup issues with our Yosemite users.
Unless this is a permanent command that has another command to turn it off?
@frank I think the issue with that idea is that this happens because of a sudden power loss or a user purposefully doing a hard shut down which corrupts the cache. The chances of a user logging out THEN hard powering down or losing power is minuscule.
@chriscollins good point, so setting up a policy to run this command once a day at startup, login and check-in should cover any sudden loss of power from the client.
This way it's easy to remove this command from clients once (and hopefully) 10.10.2 addresses this bug.
What does everyone think?
@frank if you're using the rc.server workaround with the BootCacheControl jettison command then there's no need to anything else for now. Regardless of whether the Mac is cleanly powered down or hard powered off that command will be called every time the laptop boots! That's why it's a good workaround/fix until Apple get their stuff sorted.
Once Apple come out with a correct fix for this issue you should be able to safely remove the /etc/rc.server file from your client Macs (not Mac OS X Server) without any harm and they will revert to their standard boot process. In our environment i've used Composer to take a copy of the rc.server file (created with nano) and package it in the correct location. We've pushed it out to our Macs as a "once per computer" deployment - Make sure you do your testing first of course though!
Once Apple do their fix we'll likely remove it with a simple script similar to:
#!/bin/bash
rm -f /etc/rc.server
Hope that helps!
Cheers!
@frank][/url
What @mkremic][/url said.
In regards to the testing. Be thorough! If you were to mass deploy and somehow manage to trigger a freeze during boot in the /etc/rc.server script (I don't know how... but if you did) it will lock boot on every machine with no hook for recovery. Meaning you would have to manually touch every machine and boot into single user mode to undo.
I call that sort of error a bad day.
i used @chris.hotte][/url 's method, tested it many times and it worked well.
thanks for your workaround mate!
We'Re using Deploystudio/munki in our company, so i created the rc.server file on my local mac and created a dmg file with the command munkiitem from munkitools.
i mass-deployed the dmg with munki on every mac here.
worked without problems and the problem seems solved.
if apple do their fix i will just deploy a script like @mkremic][/url said.
Cheers
Our configuration is
10.10.1 AutoDMG package
FV2 Enabled
AD Bound
We are seeing the issue and resetting PRAM/logging into single-user mode fixed it for us.
A colleague and I have spent this afternoon in my labs recreating the issue (bound to AD, 10.10.x, hard power off) and have had 100% success on over 40 cumulative hard power offs using @chris.hotte 's suggestion.
This has definitely saved our bacon in the staff environment, the labs however i'm lucky enough to have hardware that will still take 10.9.5 so i'm going that route for the time being.
One thing however, I had 0% success when using single user mode and running the command manually - it would only work when inserted into an /etc/rc.server file - which I find a bit odd. Cheers again.
Great to hear.
As for the single user boot reason... I'm not certain - could be a timing/sequence of events issue.
If you have access to AppleCare OS support or a TAM, be sure to open a case with them.
I've seen reports of a supplied fix from Apple to some customers.
No idea if it'll be in 10.10.2 yet, & neither do I have the "fix" myself.
Just wanted to say, it appears to be coming.
