Shirt Pocket Discussions

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)
-   General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Mavericks 'Invalid' Start-Up Problem (https://www.shirt-pocket.com/forums/showthread.php?t=7054)

Loopy C 05-07-2017 04:43 PM

Mavericks 'Invalid' Start-Up Problem
 
So, I started with a raw drive connected via a 'Voyager 2' Firewire dock.

I cloned my Mac Pro internal 10.8.5 system, then booted off of the Firewire clone and performed an upgrade to 10.9.5. I then ran that 'test system, booted from same Voyager device for over a week while I tweaked and tested for compatibility.

After a week of start/re-starts, and being satisfied this would be my new system...I cloned this clone to a brand new partitioned drive which would contain this new 10.9.5 copy, and then another partition with original 10.8.5 (I am stuck with 1 TB partitions because of original system drive size and not wanting to start over 'clean due to several thousand audio plug-ins and having to re-install their individual licensing systems which cloning alleviates).

I installed this new drive into my computer...and everything seemed fine, running either 10.9.5 or 10.8.5 via 'Start Up' disk preference worked as expected.

Fast forward a few weeks later...and one night upon shutting down 10.9.5 it instead restarted? And when it re-started it displayed the 'Null' sign (prohibitory sign)'? What changed? (details to follow)

Through trial and error, and after checking/repairing drive via the 10.8.5 partition which it would eventually default back to, I finally did a 'Hail Mary' and attempted to start up using command 'Recovery Mode'...the thing is this system was originally created in 2009 and upgraded to 10.6.8, to 10.8.5, and now to 10.9.5)...so there is NO 'Recovery' partition! But now 10.9.5 system booted fine!!! Just like a normal boot???

So...Command -R seemed to bypass whatever this problem is, so instead of the invalid sign, holding Command-R caused system to boot up normally (so no 'Recovery menu, just normal system start-up).

Now one thing I had done...original 2009 disk name was 'Mac Pro 1', then when I cloned I named it 'Mac Pro 1 (10.9.5), and again it been cloned/upgraded while booted from Voyager/Firewire with this name, but it seemed fine once installed internally (via SATA bus of Mac Pro 2009), BUT, while upgrading my Native Instruments this new name (the added (10.9.5) caused Native Instruments installs (Reaktor, Kontakt, etc) to fail as you can't change disk name from original install so I reverted back to 'Mac Pro 1' only (no '(10.9.5)) to fix their hard-wired directory problems tied to original name of disk used by original NI installers).

Is this change of disk name from clone name used during system upgrade a problem for booter/launchd?

The problem first started when I had the machine 'Re-Start instead of 'Shut Down' (i.e. I chose 'Shut Down from menu but it instead initiated a 'Restart', and and that's first time it didn't find valid system (Null Sign)... and then a 'Safe Start' reverted it back to 10.8.5 system partition which was/is still working fine. The disk rename probably happened in that period before this last shutdown...and up until then I had probably shut down several times from internal 10.9.5 partition without incident.

Disk repair (ran either from 10.8.5 system or via Command-S start-up 'sbin/fsck -fy' finds no problems...and as I said command-R seems to bypass problem even though there is no recovery partition installed.

Could the renaming of the disk cause this? This is a music studio machine so I have only shut it down twice since problem started, and even though both times the command-R seemed to allow it it to boot back into 10.9.5 normally, I am remiss to shut down again until I have a better understanding why a command that shouldn't do anything (Command-R) given no recovery partition is installed is allowing it to boot normally and system/disk is fine otherwise (I have been working from it for over a month since problem happened and only 'sleeping' it).

So in summary...I am seeking insight as to problem and why command-R is seemingly solving problem? before I dedicate myself to shutting down again and risk losing my now current install of 10.9.5 (which would disrupt studio work). Any comments/opinions as to technical reasons for my problem/symptoms welcome!

Thanks in advance '-)

dnanian 05-07-2017 05:03 PM

Renaming the disk wouldn't cause this kind of problem. It sounds like something lost the NVRam setting for the startup disk. Did Option+Boot show the disk (as opposed to "Recovery")? Cmd+R wouldn't really do anything useful, so I'm a bit surprised that worked at all in this situation...

Loopy C 05-07-2017 05:57 PM

Quote:

Originally Posted by dnanian (Post 33783)
Renaming the disk wouldn't cause this kind of problem. It sounds like something lost the NVRam setting for the startup disk. Did Option+Boot show the disk (as opposed to "Recovery")? Cmd+R wouldn't really do anything useful, so I'm a bit surprised that worked at all in this situation...

The 10.9.5 disk is always 'available' as a start-up from preferences...it just hits this problem (haven't done the exact sequence of 'option boot' as again since I had original problem and stumbled onto 'solution' of Command-R, yesterday was only second time I attempted shut down/fresh boot (which I was pushed to risk as I needed to do a Command/Option P/R as I was experiencing 'lags' with my keyboard controlled on-screen volume control).

According to Apple, 'Prohibitory Sign' means system HAS found and recognized the installed OS as a valid OS, but cannot boot from it because of some problem with the system.

It's this 'Command-R' as solution that really throws me. I think when I attempted 'Safe Boot' during initial troubleshooting it reverted to doing a 'Safe Boot' from the 10.8.5 partition so I could never do a 'Safe Boot' from 10.9.5.

I don't know if it would be possible to do a combination of 'option boot' to select 10.9.5 drive, then immediately direct it to 'Safe Boot' from that selection? If so, I then at least have option to maybe run 'Combo Updater' again to fix while booted in Safe while on problematic drive but at this point, I am avoiding the situation of losing my current working system until I feel comfortable with what/why these particular events are and their meaning ...as you said 'Command-R shouldn't do anything yet twice now it has allowed boot!

Thanks for reply ;-)

dnanian 05-07-2017 09:50 PM

I don't think that's right - it can mean many things but is obviously unclear. But both volumes boot, right?

Loopy C 05-07-2017 11:55 PM

Quote:

Originally Posted by dnanian (Post 33785)
I don't think that's right - it can mean many things but is obviously unclear. But both volumes boot, right?

The info I referred to actually came from CNET/Topher Kessler (must have been linked to the Apple article I had started research from) so not necessarily 'definitive':

https://www.cnet.com/news/managing-a...t-os-x-bootup/


"But both volumes boot?" Yes, if by both volumes you mean:

-10.8.5 partition (clone of original system disk that was installed in Mac Pro)

-10.9.5 partition (clone of original system but upgraded to 10.9.5). This is volume that now suddenly needs the 'Command-R' to boot correctly...at least that is what has got it to boot the two times I shut machine down and tried to boot back up and received 'prohibitory' sign.

Maybe the Native Instruments updated/installed something at the system level (a system extension) that is confused by the renaming and is now causing a system-level hang at start-up? Having the 10.8.5 partition is kinda messing things up because system reverts back to it when I try to do 'Safe Boot' I think (I believe that's what happened initially).

The other thing I did right before problem (again, this 10.9.5 volume had been booting fine both as external Firewire and final internal SATA disk), I was trying to troubleshoot a problem with a demo app ('Myriad' by Audiofile Engineering wouldn't open it's GUI properly), in that process I did a 'Force Quit' of 'Total Spaces' and 'SizeUp'...system level desktop and window utilities. I did the force quit from 'Activity Monitor', and after seeing no effect of quitting either on the Myriad problem is when I gave up for the night and initiated shut-down...which then was first time it restarted instead and exhibited current problem. And as I said, earlier that day did the NI updates and disk rename.

Total Spaces and SizeUp have never been a problem in the past, and both continue to work fine, it was just a 'theory I was pursuing. Once system is booted, it seems normal (other than the volume control lag which is first time I ever saw that...seems to have happened to many Mavericks users according to the forums, and now seems to have been solved after my 'S-Ram reset'.

dnanian 05-08-2017 07:29 AM

Does Option+boot work? (Holding down Shift after that does allow startup in Safe Boot.) You shouldn't need to reinstall the OS - that doesn't make any sense given what you're saying.

Loopy C 05-08-2017 04:37 PM

So, I am in the position of every time I shut down machine I may not be able to boot it back up without some intense and time consuming troubleshooting...as I said this 'Command-R' solution was both a 'Hail Mary' and an unexpected/unexplained temporary fix.

Having said that...at the point I feel I have gathered as much info as I can to facilitate an understanding and at least possible permanent repair to problem, then the questions/information you are providing is something I can try and answer based on actually going through the process of shutting down again.

Unfortunately, I had already done a clone/back-up of this current 10.9.5 system when issue arose so now my back-up may also have same problem so again, I want to be as prepared as possible if things go south next time I shut down.

Is there a 'summary' of what, given your understanding of problem up to now, you would suggest and want to know next time I do commit to a full shut down?

Thanks again ;-)

dnanian 05-08-2017 05:58 PM

Well, I don't think any of this has anything to do with the backup itself... but what I was wondering is whether you can simply use Option+Power On to select the volume you want to start from.

Loopy C 08-04-2017 01:49 AM

So, believe or not, I finally shut my machine down and restarted for the first time since above posts tonight, so I can finally answer your last question above...

...yes, 'Option+PowerOn' showed the desired (and already set) boot disk along with my other 10.8.5 previous system partition. Selecting it (10.9.5 main system) allowed normal boot-up AFTER one successful boot, but then one restart later back to failed ('null sign') boot.

So, here is sequence:

Last time I successfully booted (which was when I last posted here), I used 'Command+R', otherwise cold boot and restart would take me to 'null sign' or boot off the other partition (10.8.5 system). I then ran machine since then without rebooting (using only 'sleep' and using 'log out' to clear any small issues).

Tonight, after a audio problem I couldn't clear up, I shut down out of necessity. When I restarted, machine correctly booted to my target 10.9.5 system partition! Feeling empowered, I took the opportunity to run an installer I had been putting off as it required a 'restart'. But, THAT restart came up with 'null' again :(

At that point, I then attempted to answer your question and start holding 'option', my 10.9.5 system and alternate 10.8.5 were there (and already selected) so I just pressed enter and I am back up.

So in summary, yes I can use 'Option' to choose correct and previous set start-up disk, but normal restart continues to tend towards a 'null' screen which I then have to deal with...previously using 'Command-R' to successfully boot (though no 'restore' partition exists on this disk since it is an updated original OSX 10.5 system), and tonight using 'option' to manually select correct start-up.

So, the mystery continues.

dnanian 08-04-2017 07:18 AM

I'm afraid that given it works and breaks without intervening SuperDuper activity, it must be something the OS is doing during bless (or similar) that is causing your problem.

Another simple thing to try is "Safe Boot" from the one that's giving the "Prohibitory Sign" when you're in that state.

Loopy C 08-04-2017 01:58 PM

Thanks again for all your replies dnanian, just to be clear I had never intended that Super Duper be directly indicated in this unusual behavior happening, I just came here because I figured you would have the most experience of anyone I could think of in both boot/bless things, and you had always been generous in sharing your thoughts and assisting in other matters ;-)

I guess it will remain a mystery for now, as long as I have two paths for getting around it ('Command-R' which shouldn't work lol, and 'Option/Select') I simply can't think of what else I can do without starting from scratch with that drive.

One day if I have the opportunity, it will be interesting to see if the clone of that disk does same thing. Otherwise, it may be the way I created the disk (via Firewire+Voyager dock?) and some other item (rename disk after creation??) that just seems to confuse the 'blessing', though not when manually directed...just strange.

Thank you very much for all your input, if I ever come up with anything I will update you :)

dnanian 08-04-2017 02:12 PM

Did you try Shift+boot? Try that next time it has trouble...

Loopy C 10-11-2017 08:57 PM

FWIW, I think I accidentally stumbled upon the answer to my above described problems. The drive mentioned and circumstance (OSX/Mac Pro) is EXACTLY my situation, and the problem didn't start until I ended testing cycle (which was booting via FireWire/Voyager dock) and installed in my Mac Pro tower as an internal drive.

https://arstechnica.com/civis/viewto...f=19&t=1300231

My holding down 'command R' (which is how I currently do a successful cold boot up) must be slowing down the boot cycle enough for it to mount?

So bottom line...the choice of running this particular 'NAS' drive with this particular Mac Pro and OS seems to be the overall culprit.

Again, FWIW, thought I should at least share in case it helps anyone else in the future (or just as a mystery 'solved') ;-)

Thanks again Dave Nanian for your input along the way.

dnanian 10-11-2017 09:14 PM

Thanks for the update, Loopy C!


All times are GMT -4. The time now is 06:33 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.