Well, I can safely say that my festive ‘dev’ plans were well and truly derailed. What follows is probably going to be a moan-fest, so feel free to skip to the last paragraph for a dev update 🙂 Though you’ll be sadly disappointed 🙁
Both my main dev-pc and my Mac Air Windows installs are Windows 8.1 upgraded to Windows 10, and for a while I’ve been putting off upgrading the 666 engine, and Dominium to build from Visual Studio 2015. Having updated it recently, I decided it was time to ditch the ‘upgraded’ Windows installations, and go for clean Windows 10 installs. It was also an ideal time to do a clean OSX El Capitan install on the Mac Air. And, heck, why not upgrade my 2009 Mac Mini file server to El Capitan at the same time (which is usually fraught with software peril with things stopping working after an upgrade).
For a long time, I’ve been running out of storage on the Mac Mini – it has a 128Gb SSD split into 40Gb for OSX, and 88Gb for Data – which holds my Perforce SCM server, amongst other things. So, why not upgrade the SSD at the same time? I bought a 240Gb SSD, and then discovered that I can remove the internal DVD drive, get a micro-SATA adapter, and fit an additional drive inside the Mac Mini! Awesome… then the 128Gb drive becomes the OSX install, and the 240Gb becomes the internal data drive. Sorted.
Wiping the Dev PC and installing Windows 10 clean was no bother, as expected, and oddly it ‘feels’ cleaner than the upgraded Windows 8.1 install did… I can’t say why, probably psychological 🙂 Building and running Dominium was more of a trial however… installing VS2015 and building the main project left me with a plethora of missing DLL’s for some reason (even after upgrading all the SDK’s to build with VS2015). It turns out I still need the VS2010 redistributables, so some internal dependency needs to be resolved there. Of course, simply installing the redistributables doesn’t cut the mustard! I had to remove VS2015, install VS2010, install VS2015 again, and then remove VS2010 leaving behind the redistributables and the VS2010 ‘pre-requisites’… fun.
Next, the Mac Air… frequent readers may be aware of my repeated whinging about the Intel HD 5000 graphics driver under Windows 10 that keeps crashing, almost every 20 seconds sometimes, for which Intel will assume no responsibility. When it crashes, it whinges about the ‘Windows 8(R)’ driver, so I presumed the Windows 10 install did not ‘take’ so well, even after updating the Bootcamp 6 drivers provided by Apple, or using the latest Intel HD 5000 ‘Windows 10’ drivers. The hope was to clean install Windows 10 and ‘kiss goodbye’ to this issue. Ahah.
Normally, when I do this kind of exercise, I do disk images of everything ‘just in case’ – but I’ve found from past (painful) experience they rarely work, and when you restore them they just fail, or corrupt, or go sideways in some interesting and hard to fathom fashion. So now I ensure a) all data is in the cloud, or on a NAS b) I catalogue every single application I installed, and ensure I have the licenses / keys to hand.
Wiping the Mac Air and installing El Capitan was cathartic, I can tell you. I then Boot camp’d it, and hit snag number one. Windows 10 wouldn’t recognise the bootcamp partition, even after formatting it itself. Arg. I google this and find it ‘just happens’… and the fix? Do you want to know the fix? Insert the USB Drive with the Windows 10 installation into the OTHER USB port. Of course. Of course. Obvious, when you think about it. ?. ??. ????. After doing this, Windows 10 happily recognised the Bootcamp partition and the magic happened.
After installing, guess what happened? Go on, guess, you can guess can’t you? Yep, you guessed. The Intel HD graphics driver crashed on the first run, once again whinging about the ‘Windows 8(R)’ driver. Yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeaaaaaaaaarg! There is no excuse Intel! Your drivers for your hardware are shambolic!
Post fume, I setup VS2015 (from the lessons learned on the Dev PC it went smoothly this time) and then went to download Perforce ‘p4sandbox’ – for those unfamiliar with Perforce, this allows you to replicate your P4 server locally, so you can use source control whilst offline – vital for a laptop where I do most of my dev work on the train. I go to www.perforce.com, and cannot find ‘p4sandbox’… indeed ‘Perforce’ is now christened ‘Helix’… but despite extensive searching, I cannot find a download that does the same as p4sandbox. Their doc’s still exist, helpfully telling me how I can use it, but the download is gone.
Yeeeeeeeeaaaaaaaaarg! If only I’d imaged the original install I could rescue the executable. Yeeeeeeeeaaaaaaaaarg!
Taking a break from this madness, I decide to tackle the Mac Mini upgrade. Oh boy, what a mistake.
Adding a Second SSD/HDD Drive to a 2009 Mac Mini
1. Don’t purchase one of these; micro-SATA Connector
2. Don’t deconstruct your Mac Mini like Mac Sales – Disassemble Mac Mini
3. Don’t buy a 240Gb Kingston UV300 SSD and then immediately disassemble it to get the SSD drive board out
4. Don’t use a Dremel to modify the existing black plastic DVD chassis to accomodate the micro-SATA connector and SSD drive board (as the SSD won’t fit in the Mac Mini in its original case due to the offset caused by the micro-SATA connector).
5. Don’t spend days trying to figure out why the …. you simply cannot clone the existing drive to the new one and then boot from it
Egads, I could scream. I have tried every possible way to upgrade the existing install to use the new 2nd drive, or indeed any drive. None of them worked. Disk Utility, .dmg files, Carbon Cloner, .sparseimage files, direct cloning of partitions, the list goes on.
This is what I wanted to do…
1. Clone existing 128Gb drive to a new 128Gb drive (connected as a 2nd drive via the micro-SATA connector).
This worked, and allowed me to boot from the clone, proving the micro-SATA works as expected. I then upgraded this clone to El Capitan, and had to figure out why Perforce server no longer worked – due to the /usr/local/bin folder being replaced during the upgrade, wiping the p4d executable from existence. After chasing down the correct version of the Perforce daemon, all worked as before which was good news! El Capitan, success!
2. Move the ‘Data’ volume on the upgraded drive to the 240Gb SSD.
So now this upgraded drive becomes the new ‘master’ boot volume, and I add in the 240Gb SSD as the data volume, and clone the current ‘Data’ volume to it from the recovery partition.
I then rename the original ‘Data’ volume to ‘_Data’, preserving it in case something goes horribly wrong.
I reboot, expecting to see the joy of El Capitan powering my new server, with the data in its spacious new home.
Instead I spend 23 minutes watching OSX log in, and painfully set up every single service in excruciatingly slowness of epic proportion. Something is wrong.
That’s what I wanted to do… I have tried backing up to an image, restoring the image to the new drive, or booting with just the new drive and installing El Capitan clean – none of it works, always I am left with an unbootable drive. So, it must be the new drive, right?
Under Windows (via the Dev PC) I can format, partition, verify, check, repair, scan, even do performance testing. The new drive is fine.
So despite the earlier evidence, it must surely be the micro-SATA connector, right?
Plug in the original drive (or another known working drive) via the micro-SATA connector and they all work fine.
Ok, so now I decide to ditch the 240Gb upgrade, stick with Yosemite, and just move the ‘Data’ volume from the original 128Gb drive, to the other known working ‘128Gb’ drive. That’ll work, right?
Now it won’t boot again. Further, it won’t even boot from the recovery partition, or the El Capitan installer USB drive.
Despite many attempts, every possible combination of ways and means, I reach the conclusion that alas, I cannot have a 2nd SATA drive connected and do what I want. I can only presume it’s power related, and that despite many others being able to do a 2nd drive upgrade with a 2009 Mac Mini, my one is the only one to roll off Apple’s production line that simply cannot handle it.
Ok, so now I clone the original 128Gb drive partitions to the 240Gb drive, and just boot with that drive only. At least I will have gained some more space.
Tether. End of. Short of throwing the entire machine out of the window (not particularly effective in a bungalow I’ll grant you), I have no more options to try. Nor patience to bother. I have replaced the original 128Gb SSD in the chassis, and left the damned machine in bits strewn across my desk. Let that be a lesson to it.
Returning to the Mac Air… I remember that Perforce used to allow you to browse their past releases on an FTP server. If they’ve done something to eradicate p4sandbox from existence on their main site, surely they wouldn’t leave it behind on their FTP? A quick tour of ftp.perforce.com and voila! I locate p4sandbox and the day is saved! After configuring it for both the Windows 10 boot camp and OSX El Capitan partition, I now have offline access to my Perforce server restored, and mobile dev is back online, huzzah! (I also have backup copies of p4sandbox just in case 😉 )
So, after this week of intense fuming madness, I am left with;
Shiny clean install of Windows 10 on my dev pc.
Shiny clean install of El Capitan on my Mac Air.
Shiny clean install of Windows 10 on my Mac Air – that still crashes the Intel HD 5000 graphics driver.
I can safely say that this only feels like a little win 😐
However, I have garnered some useful info on my available HDD and SSD drives, which is quite surprising. To avoid this blog becoming a mega-epic (it isn’t already??) I’ll do a separate post, as it’s worth dedicating a post to.
Cut to the Chase Already!
As the above precluded any coding effort, I’ve had plenty of time to think about coding, and my next efforts will be in locking the drive systems to allow travel according to their capabilities (ie. FTL drives can’t be used to dock, and so on).
Also, book-wise, sadly the full page ad in SciFi Now led to zero sales of the book, and zero additional web traffic to this hallowed portal 🙁 Ho hum. It is what it is. Maybe one day, who knows.