Welcome, Guest
Username: Password: Remember me

Search Micromat Forum

Keyword

TOPIC: Corrupted boot volume

Corrupted boot volume 19 Mar 2019 15:40 #10875

I've been running High Sierra on a MacPro 3,1 system for quite a while and now have a BIG problem . This system was created using DosDude's High Sierra method/program for installing High Sierra on a MacPro3,1 system last year some time. When I rebooted the system yesterday, I now get an error saying "This version of Mac OS X is not supported on this platform! Reason: Mac-F42C88C8" -- and unfortunately the Recovery disk says the same thing. But the good news is that I have a Sierra (macOS 10.12.4) TechToolPro eDrive volume that boots OK (but it only has a few apps and does not have TimeMachine but it can mount the TimeMachine backup volume).

So the question is what might have happened to goof things up? I have a TimeMachine backup volume, but can't run TimeMachine from the eDrive, as it has very few apps installed (why not include TimeMachine on the eDrive??). And even if I could run TimeMachine and do a restore, not sure how to decide what to restore, since the cause of the problem is not understood yet.

Suggestions are welcome in how to get back to HighSierra land on my MacPro3,1 system and even better would be how to determine what exactly got messed up to cause the problem. One clue as to what happened is the volume that is now called SSD-HighSierra (and has been named this way since I did the install -- so that didn't get changed), but the icon associated with this volume has a different icon that looks very like something to do with TechToolPro -- Have attached the image I got from taking a photo of the boot screen (result of holding down the Option key)

Another clue that points to having TechToolPro having something to do with it is that in the folder /System/Library/CoreServices are a couple of unusual named files (this is the last few lines of a "ls -lart" command showing the most recent modified files):

drwxr-xr-x 101 root wheel 3434 Feb 21 21:07 ..
-rw-r--r-- 1 root wheel 0 Mar 11 18:04 .MicromatProtogoVolume.flag
-rw-r--r-- 1 root wheel 0 Mar 11 18:04 .MicromatProtogoBasic.flag
-rw-r--r-- 1 root wheel 576056 Mar 11 18:13 boot.efi
-rw-r--r--@ 1 root wheel 3557 Mar 17 19:42 .disk_label_2x
-rw-r--r--@ 1 root wheel 893 Mar 17 19:42 .disk_label
drwxr-xr-x 172 root wheel 5848 Mar 18 20:15 .

Have never seen the files starting with ".Micromat..." or .disk_label..." in this folder, or anywhere else for that matter that I can recall. How to determine if this is the "correct" boot.efi file and why did it get modified so close to when the .Micrommat... files got created (within 9 minutes)?? The checksum for the boot.efi file is:

sh-3.2# sum boot.efi
70 563 boot.efi

Another item is that when running System Preferences and looking in the "Startup Disk" pane, it shows the default boot volume as "SSD-HighSierra" which is what it should be, and it also shows that it's a "macOS 10.13.6" version, which is also correct. This indicates to me the volume is still considered as "blessed" but the fact that it won't boot is the real problem. Would "blessing" it again help?

Another odd thing that I was surprised to see is the contents of the "PlatformSupport.plist file -- would have thought it should have an entry for the MacPro3,1 system but it doesn't:

sh-3.2# pwd
/Volumes/SSD-HighSierra/System/Library/CoreServices
sh-3.2# grep -i macpro PlatformSupport.plist
<string>MacPro6,1</string>
<string>MacPro5,1</string>
sh-3.2#


I recall having to edit this file a long time ago (perhaps for Sierra or even before), but perhaps DosDude's method doesn't require this manual edit any more?

Another thing I can say is that I did use the TechToolPro app to clone another boot volume from another computer to a brand new drive, and that seemed to have worked OK (it was cloning a Mountain Lion boot volume for an old white MacBook early 2008 system if it matters). Was careful on what source and destination volume I chose, but certainly possible something might have been unintentionally clicked on, but if that were the case, I would have expected far bigger problems as that volume was a minimal MacOS 10.7.5 system with no apps other than what came with when new and this problem volume has lots of stuff in the /Applications folder.

Many of the parts on the boot volume seem to be there (my /Applications and /Users folders seem to be intact and look normal from what I've looked at so far but without the ability to boot from it can't really make much use of them at the moment), so the problem seems to be in the stuff that macOS High Sierra looks for and needs when it boots, but what exactly is not there or messed up is a real puzzle to me at the moment.

So, have any suggestions to get the MacPro3,1 back up and running off that High Sierra boot volume? and also how to fix the Recovery partition so that it can boot the High Sierra recovery? and biggest question of all is how to restore the system back to it's pre-messed up state? And even more important, why would TechToolPro even mess with the Recovery volume at all? Seems like that is not something it would ever be involved with since it is such a special tool. Of course, don't know this for sure, but the fact that it exhibits the same error when attempting to boot from it as the volume that I can see Micromat "droppings" seems very odd to me.

Thanks very much...

ps -- I'm trying to attach a jpeg image of the boot screen on the MacPro (what you get when you hold down the Option key) but it doesn't appear to be working -- are you having problems with attaching files or is this an e-drive boot issue or ???
Attachments:
The administrator has disabled public write access.

Corrupted boot volume 19 Mar 2019 16:21 #10876

I am sorry, but I have no experience with the problems created by running an operating system on hardware that does not support it.

Time Machine is on your eDrive. It is part of System Preferences.

The TechTool Pro files you mentioned are not the source of the problem. The likely source is running High Sierra on hardware that does not support it. We do not support running TechTool Pro when the computer is running an operating system not supported by the hardware.

The File Cloning and Volume Cloning tools in TechTool Pro are intended to allow you to make backups of files, but are not a substitute for a program such as Carbon Copy Cloner, Super Duper, or ChronoSync. A bootable volume is more than a collection of files, and requires various tasks to be done upon it before it becomes bootable.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.

Corrupted boot volume 19 Mar 2019 16:40 #10877

Thanks -- Time Machine in System Preferences is for backing up but I need to restore -- I just looked and there is a checkbox in there to show in the Menu bar the TimeMachine icon which has a "restore" feature --- so thanks for that...

Like I said I had NO PROBLEM before with this setup -- even running TechToolPro -- until a few days ago.

The presence of the weird micro mat files starting with "." (to hide the file unless you know how to see these files with "ls -a" type commands in Terminal is what I think is the big tipoff that TTP or ProToGo has done something.

TTP did a fine job of cloning the boot volume -- it's running right now on the older MacBook white 2008 system so perhaps you might want to reconsider recommending your own product to clone disks. What does TTP not do that those other products do regarding cloning?

In any event, thanks for trying to answer ... will keep looking for what happened though ... perhaps you might ask someone at Micromat with more experience?

Thanks...
The administrator has disabled public write access.

Corrupted boot volume 19 Mar 2019 16:47 #10878

You are welcome.

I have not looked into this issue lately, but if I recall correctly, some people have reported being able to make bootable volumes with our cloning tool, and some people have reported getting a non-bootable collection of files. You can see Super Duper make a clone bootable when its log is run.

I have asked people about the running of system software on unsupported hardware, and basically, the response is that we do not study the problems that arise from it. You should consider why Apple did not permit the operating system to be installed on that model. Things work fine, right up to the moment they do not.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.

Corrupted boot volume 19 Mar 2019 22:27 #10883

Can you at least explain why the TTP software (either TTP or Protogo) would have created the files in the /System/Library/CoreServices folder (the ones I refer to in my original post)? And further please explain what would be the point of your software in modifying with those partitcular folders? I could easily take this disk and mount it on a newer MacPro system that is supported by Apple and have the same problem -- surely you're not refusing to support your software are you?

I'm merely trying to understand the problem and what might have caused it and how to best go about in fixing it. You, or someone else in the company surely understands under what circumstances those very odd files are created in that particular folder?

And most importantly what else would have been modified -- that is the most important thing as far as I can tell -- something got modified and only Micromat knows what your software does at this sort of detailed level. The presence of this unusual files leads little else to conclude that TTP or Protogo has attempted something, so please explain so that I can determine the best way to fix the problem that it would appear your software has caused in the first place. The fact that I'm running it on an older piece of hardware really has very little to do with situation.

Thanks...
The administrator has disabled public write access.

Corrupted boot volume 19 Mar 2019 23:00 #10884

Regarding:

rw-r--r-- 1 root wheel 0 Mar 11 18:04 .MicromatProtogoVolume.flag
-rw-r--r-- 1 root wheel 0 Mar 11 18:04 .MicromatProtogoBasic.flag

These invisible files are flags in /System/Library/Core Services of Protogo devices and Protogo Basic devices to tell TechTool Pro when running on those devices to disable features in TechTool Pro that should not be used when a Protogo device is the active boot volume. For example, you should not create an eDrive using a Progoto device as the OS X Source Volume, so when a Protogo device is the active boot volume and TechTool Pro is running, the ability to create such an eDrive is suspended. The files are essentially text or plist files, and contain no executable code. They belong only on Protogo devices. No program but TechTool Pro uses the files in any way. The only way they can get into /System/Library/Core Services of a regular startup volume is if at some point a user did a file migration from a Protogo device to a regular bootable volume. You can delete them. These cases are very rare, but a few have been seen before. I hope this makes it clear that the files are not the source of the problem you have encountered.

All you have to do to completely remove TechTool Pro is to run the Installer, and use the Customize button and the checkboxes to remove the program. At the end of the process, you will see a statement that the program has been installed, rather than removed, but that is just because Apple's installer has only that message at the end of installing a program.

When you run a system software installer, some of the files that get installed are specific to the hardware that the installer has recognized. You fooled the installer into recognizing the wrong model, to force it to install High Sierra on unsupported hardware. That type of installation cannot be trusted.

We do not, in fact, support the use of TechTool Pro on system software other than the versions stated in our system requirements for each release of the program, and we do not support the use of it on hardware on which you have installed a version of the operating system not compatible with the hardware, according to Apple.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.

Corrupted boot volume 20 Mar 2019 05:46 #10886

Well, thanks for this information, BUT...

Those weird files are on my primary boot partition, not an any special Micromat e-drive or ProToGo volume, so now that it's apparent that your software put stuff where you say it shouldn't have, it would seem even more obvious that the problem lies in your software, and I'll ask again...since your software did this on the primary macOS High Sierra volume what else could it have changed to alter the system from being able to boot without problems to booting only to get the "This version of Mac OS X is not supported on this platform..." and then halt?

I'm not knowledgeable enough to know what files are involved in the booting up of macOS High Sierra, but I would guess someone there at Micromat is very aware of the sequence of events and files that, if mistakenly modified, would cause this sort of problem --- and that's all I'm asking for from you -- a list of files that, if modified incorrectly by your software, would exhibit exactly this sort of problem? That will allow me to restore only the ones that got mistakenly modified rather than be forced to restore the system to a state before the problem occurred - and the reason for that is that I would loose all the work I've done between when the problem happened and when I rebooted several days later and then discovered the problem was serious enough to prevent the system from booting. And also don't forget the Recovery volume also exhibits the same error message, so it too apparently got modified as well.

For example, did it also alter the boot.efi file (the timestamp of boot.efi is just a few minutes after the timestamp of the .Mciromat... files)? Seems odd timing for them both to be created/modified with such a short time? Did it alter the PlatformSupport.plist file (it doesn't appear to have, but can't be certain yet), or any other crucial file important to the process of booting up?

Thanks for your help...
The administrator has disabled public write access.

Corrupted boot volume 20 Mar 2019 11:19 #10887

You are welcome.

The only way that the MicromatProtogoVolume.flag and MicromatProtogoBasic.flagfiles, which are created only on Protogo devices, could have gotten on your primary boot partition is if you or a utility program used to copy files transferred them from the Protogo device to the the primary boot partition. They are not created on a primary bootable volume when TechTool Pro is installed on it.

Our software did not modify your operating system, which you created by fooling Apple's installer. There are thousands of files involved in booting a Macintosh. We do not have a list of them. We copy system software installations or subsets of them when Protogo devices or eDrive volumes are created. You would be much better off restoring your files than trying to figure out which of thousands of files has some defect.
MicroMat Inc
Makers of TechTool
Last Edit: 21 Mar 2019 21:33 by micromattech3.
The administrator has disabled public write access.
Time to create page: 0.379 seconds