scottryan1992 Posted September 30, 2014 Share Posted September 30, 2014 Hi, I installed OS X 10.9 to a virtual machine which worked fine and everything was great, then I installed the combo update to 10.9.5... I first backed up extensions and the kernel then reinstated them after the update, otherwise the kernel had problems. However now I have another problem, like in the picture.. There is a fix but it requires a rollback on 2 Kexts.. How do I rollback I kext if I can't boot into OS X? Link to comment Share on other sites More sharing options...
JVene Posted September 30, 2014 Share Posted September 30, 2014 Hi, I installed OS X 10.9 to a virtual machine which worked fine and everything was great, then I installed the combo update to 10.9.5... I first backed up extensions and the kernel then reinstated them after the update, otherwise the kernel had problems. However now I have another problem, like in the picture.. There is a fix but it requires a rollback on 2 Kexts.. How do I rollback I kext if I can't boot into OS X? ImageUploadedByTapatalk1412036202.556579.jpg When using virtual machines, you should keep a copy of a working OS X, even an older one, so you can mount the disk for the failing OS X in the VM of a copy that still runs. If you used snapshots (you did, didn't you?)...you could clone the older snapshot, but there's a small issue. OS X can't mount two drives with exactly the same name (without some expert effort, that is). In order to do that you have to mount the drive manually. So, most of us that do this create a "safety" VM, a copy of a working version, with unique names of the main OS disk, often unique network identities and unique IP addresses (when using bridged mode). Link to comment Share on other sites More sharing options...
scottryan1992 Posted September 30, 2014 Author Share Posted September 30, 2014 Okay I understand what you are getting at. Basically create a new vm, mount the disk from the original vm. Rollback the kext using the kext manager I've seen around and then unmount it, shutdown, start the original vm and all shall be happy... I will try this on Thursday.. Thanks for the help. JVene. Link to comment Share on other sites More sharing options...
scottryan1992 Posted October 2, 2014 Author Share Posted October 2, 2014 I am just setting up my VM now that will become my "Support" VM as you mentioned. Is there any paticular software that you would recommend to Roll-back the kext? Link to comment Share on other sites More sharing options...
scottryan1992 Posted October 2, 2014 Author Share Posted October 2, 2014 Does rolling back of a kext simple mean replacing it with a previous version and then repairing permissions? This is what I have done and the permissions are now repairing, once that is done I will post back and let you know how I got on. Link to comment Share on other sites More sharing options...
scottryan1992 Posted October 2, 2014 Author Share Posted October 2, 2014 I am now stuck again, after sending the virtual disk back to its oringal vm it is saying the id's are wrong. How do I rectify this? Link to comment Share on other sites More sharing options...
JVene Posted October 2, 2014 Share Posted October 2, 2014 I am now stuck again, after sending the virtual disk back to its oringal vm it is saying the id's are wrong. How do I rectify this? This last message I don't yet understand....what software is complaining about the ID's being wrong, and has OS X booted to that point, or .... well....give me some context for that one. As to kexts, basically....yes. You're copying directories (kexts are usually packages, directories of various content), but there's a little more to it. I suggest you get Kext Wizard. It can help with this (has an "install" kext tab, will show you what is currently loaded, and....the important part....fixes permissions). The steps in "rolling back" kexts is basically installing replacements from a backup, then fixing permissions...then....rebuilding the cache (kext cache). Kext wizard has a function on it's main page for doing that. Takes a few minutes, but avoids problems doing this. Snapshots....learn to use snapshots when experimenting. Also, learn how to create clones...both linked clones and full clones. Big time saver those features. Also, just realized a little puzzle in your last post...."after sending the virtual disk back..." Give me more detail about what you did to accomplish that. Here's a quick summary (very terse) of a few typical "manipulation" tasks I use. Snapshots....in VMWare since about 8 you can create snapshots while a VM is running - going back to such a snapshot is like resuming a machine from a suspended state. However, be forewarned, taking the snapshot requires twice the RAM as the VM occupies when it's running. Make sure you have sufficient RAM if you're going to take a "live" snapshot of a running machine, or you'll need to order chinese while it's trying to do it. If you get caught by this, be paitent. It works, it's just thrashing virtual memory like crazy if you're overrunning RAM. Otherwise, snapshots are like backups, but they create these numbered versions of your disks. Once you start taking snapshots you can't just copy a VMDK file for use elsewhere. That's not a bad thing, just something to understand about snapshots. They're fantastic to use, and they're related to clones. Clones come in two flavors, full and linked. A full clone is a complete copy of the VM. The result will be completely stand alone. More importantly, if you've taken several snapshots and want a version of the final state (or any state in the snapshot set) which has a "clean" VMDK file you can just copy and keep, a full clone provides that. Sometimes I get a machine just perfect, or I've used it for a long while and I have lots of snapshots cluttering up drive space. I'll create a full clone of the current state (while shut down), and then erase the version with all the snapshots...this basically "publishes" a "final" form of that VM without any snapshots incorporated. To experiment with configurations and tweaks, I take a machine that is at some workable state and create a linked clone from it. The difference between a full clone and a linked clone is that the linked clone is dependent on the original from which it is created, boots from that original and then ADDS TO IT, privately, in the linked clone location. If, for example, the VMDK were about 10 Gbytes, and I create a linked clone from it, then installed or added 5 Gbytes of new software / data - the linked clone directory would have only about 5 Gbytes...yet represents a machine which has 15 Gbytes in it. In experimentation, then, I have some basic install that's not tuned. I create a linked clone and attempt configuration, but usually I end up with the "what if" question. Rather than corrupt a good machine (or one developing into a good one), I create yet another linked clone to corrupt. In this way you can have several (dozens) of examples all based on some "good" starting point (or points along the way) representing different attempts at fixing things (which often end up corrupting things). The only problem is keeping track of what sources a linked clone is based upon. Eventually I settle on some successful experiment, create from that a full clone, then delete all the linked clones in the experiment....LEAVING THE ORIGINAL SOURCE MATERIAL UNTOUCHED. That last point is where you are....well, not. From what I read you've corrupted your original, yes? Linked clones make it possible to experiment and still be able to create a linked clone from some known starting point that remains intact. Sometimes I create a linked clone that lives for only 10 minutes. Long enough to prove something doesn't work, and then delete it. Sometimes I create a maze of linked clones like this: /--failed experiment 1 / root (installed)-----linked clone, good result---failed experiment 2 \ /-failed experiment 3.1 \--good experiment 3----- \-good experiment 3.2-----failed experiment 3.2.1 \ \----good result, final 3.2.2 From that set, I could branch of good experiment 3 and form experiment 3.3, or from good result 3.2.2 and make a 3.2.2.1. I can also create another linked clone from "linked clone, good result", creating experiment 4. All the while, the root...just installed version is untouched. I can subsequently create a full clone of good result, final 3.2.2 and run with it, making IT the base of such a hierarchy in a future set of experiments. Sometimes I'll create linked clones just to try new software, or see if it's harbouring viruses. Sometimes I'll create linked clones to visit websites reported to have corrupted a friend's machine with a virus. When I update Android development tools, I use a linked clone so I can screw up the update and try again. It's something you just can't do with real computers. A linked clone can be created in about 10 seconds. In a real computer, you'd have to backup the entire hard drive TO A NEW ONE, and have lots of them around to accomplish something remotely similar in real hardware. At one point I calculated that, all collected, I had sufficient duplicates of an 80Gbyte VM installation to account for 2 Terabytes of duplicates. Yet, each linked clone only occupied about 100 MBytes because I was only altering configuration in each one, but over dozens of them. Link to comment Share on other sites More sharing options...
scottryan1992 Posted October 2, 2014 Author Share Posted October 2, 2014 Thanks for clearing that up, I have worked with snapshots before but it's been interesting reading about them a little more in depth. The clone thing is also very clever, I like it Okay so to clear up what I mean in my last question. I created a new VM which is now my "working maintenance vm" so to call it. Then from there I added another drive which was the VMDK from the first one that I had upgraded. Here is where I think I went wrong, I mounted the OS X.vmdk rather than the OS X-000001.vmdk. So because I edited the parent and the child hadn't been touched there CID's no longer match. When I try to boot it gives me an error. Just another quick question when installing a kext for example, system.kext which I need to roll-back, does it automatically overwrite the already installed one? Thanks Link to comment Share on other sites More sharing options...
JVene Posted October 3, 2014 Share Posted October 3, 2014 Thanks for clearing that up, I have worked with snapshots before but it's been interesting reading about them a little more in depth. The clone thing is also very clever, I like it Okay so to clear up what I mean in my last question. I created a new VM which is now my "working maintenance vm" so to call it. Then from there I added another drive which was the VMDK from the first one that I had upgraded. Here is where I think I went wrong, I mounted the OS X.vmdk rather than the OS X-000001.vmdk. So because I edited the parent and the child hadn't been touched there CID's no longer match. When I try to boot it gives me an error. Just another quick question when installing a kext for example, system.kext which I need to roll-back, does it automatically overwrite the already installed one? Thanks Ah, yes...and I've never been able to add an existing HD and make it work when under snapshots. I've had to create full clones for that. On a side note, never attempt to mount an OS X HD using the VM utilities (map virtual drive). It may let you mount it, but Windows doesn't understand it and will crash to a BSOD ingloriously - when you remove the mount. Disks are Windows' Achilles heal. Sometimes Windows will BSOD because it looses track of a USB drive. Now, about kexts overwriting...yes and no. Not inspiring, I know. Here's the point: you're moving a directory of content into a directory. Just like any other such copying, if there are files in the current directory that are NOT in the old directory, those files won't be removed for you. They may not matter because most of the time they'll be unreferenced material. That's something Kext Wizard takes care of for you, but if you're doing that manually, it may be best to remove existing content first. Otherwise, however, all files in the kext of the same name will be overwritten by those from the source, and that's sufficient at least 99% of the time. Link to comment Share on other sites More sharing options...
scottryan1992 Posted October 3, 2014 Author Share Posted October 3, 2014 That is what I did, I removed the old Kexts for S/L/E and then added the new ones after that I repaired the permissions for the VMDK using disk utilities. So in theory the only thing I have done wrong is mounting the original OS X VMDK rather than the snapshots? Well I think I will just create a new vm install the combo update then when it shows the error mount it into the "maintenance" vm and then rollback the Kexts. Because I haven't made any snapshots the CID problem should be no longer. Link to comment Share on other sites More sharing options...
JVene Posted October 3, 2014 Share Posted October 3, 2014 That is what I did, I removed the old Kexts for S/L/E and then added the new ones after that I repaired the permissions for the VMDK using disk utilities. So in theory the only thing I have done wrong is mounting the original OS X VMDK rather than the snapshots? Well I think I will just create a new vm install the combo update then when it shows the error mount it into the "maintenance" vm and then rollback the Kexts. Because I haven't made any snapshots the CID problem should be no longer. All that sounds right. On the point about mounting the VMDK when there are snapshots, I never get that to work correctly. It seems that it should work, in that if you pointed to the latest snapshot of the VMDK series, VMWare ought to be able to figure out what to do. I swear that instead VMWare managed to alter the base VMDK, invalidating the entire series. So, when I'm in need of mounting a VMDK into another machine, I usually resort to a usage pattern of avoiding snapshots, but backuping up the VMDK at each major step (just about every reboot). I have several drives, so I always have a different physical drive available as a destination for the VMDK backups (makes that move MUCH more quickly than copying a 10+ Gbyte file within a physical drive). If I do have a VM with snapshots and the need arises to mount the VMDK in another OS, I've resorted to creating a full clone first. At the very least, backup the directory of the VM containing the snapshots before you try mounting the latest snapshot of the drive, because I have anecdotal data that it just doesn't work. Don't think you're alone, though. I probably tried 3 different sources and dozens of install attempts before I got a 10.9.4 install I like, and I've done this on versions dating to 10.4.8, I've been a developer for 30+ years and I know this stuff like my way home. You're doing it right, it's just tricky. Link to comment Share on other sites More sharing options...
scottryan1992 Posted October 3, 2014 Author Share Posted October 3, 2014 Okay thanks for that, it's annoying me because originally I wanted to have Mavericks for Xcode then after that i realised I need the latest update and that's where I am getting stuck. The update I'm doing is the combo update and I have been backing things up like the kernel before hand then doing the update and then adding them back in. Maybe just a few extra lines of code I can backup the system.kext and others and add them back in as well. I will try to find the steps I used for this and show them to you to see if it would work for this as well. Again thanks for your help, your awesome. Link to comment Share on other sites More sharing options...
Recommended Posts