Unfortunately there is an all too common bug with upgrading a system that has a filevault user – in short it doesn’t fucking work! I’m the only user on my laptop and when I tried to log in after the upgrade all I got was an error message:

“Your FileVault-protected home folder did not open and needs to be repaired. Click OK to repair the folder and continue logging in. Click Cancel Login to log in as a different user”

oh fuck.

I’d like this part of the story to be the part where I say, it’s all ok because I had backups, but it’s not. I had my daughter in my arms and was flying one handed, she’d just dozed off for a short nap and I didn’t want to wake her up so I didn’t reach down, unplug the external drive from my desktop machine, I didn’t plug it into my laptop and I didn’t back up my files.

oh fuck.

I clicked OK, waited a few seconds and hoped for the best…

“Logging into the account failed because an error occurred”

oh fuck.

Now it sinks in, what was meant to be a nice little morning project, upgrade my OS has turned into a total nightmare. Here are the steps to sort it out, they worked for me and hopefully will help someone else.

Reset the root password, so you can login

Restart you machine with the install disk in the drive and hold the c key to boot from the disk.

Select your instalation language, accept the agreements and click continue. When it’s loaded choose reset password from the utilities list. Choose your system drive and select System Administrator (root) from the list of users. Set a password and click save.

Login as root

Close all the windows and quit the Mac OS X Installer, when your prompted to select a startup disk choose your hard disk.

Now you login screen should have an option to log in as another user, pick this and use the username root and the password you set above. You should now get a new desktop from here you’ll be able to recover your files.

Get your files

Open finder and browse to the Users folder. Find your user and in there you should find a file called username.sparseimage.

I tried to back the whole file up to my external drive, but couldn’t get it to copy in either Finder or terminal.

So just double click it to mount it as a disk. You’ll be asked to type a password, it’s your user password for the account. Type it and click ok.

Finder will start to mount the disk then stop with the following message:

You’ve got nothing to lose here, it’s mount it or lose everything so just go ahead and click Open.

So it can’t read it properly, just click ok. You should now have a drive mounted and it has all your files in there. Time to back them all up, except they probably won’t all back up. I tried that and got some permission issues, rather then worry too much about them I ignored them and just made sure I got all my documents, pictures, music, movies and the application settings I wanted, I ignored everything else.

I have a lot of files and this took a very long time, the lesson I’ve learned – back up more often. Ironically that’s part of the reason I wanted to upgrade, so timemachine would do this for me… but I digress.

Recover

At this point you have a choice. You can create a new users, move files into it and move on with your upgraded system. Since I was tempted to wipe the system and start again when I considered installing the OS I chose to go that route. I rebooted, used disk utility to clean the drive and started again from fresh.

Either way from you backups and your new user you should be able to either do a recovery and get more or less back to where you wanted to be.

Rant

Filevault is promoted as a great security feature of the OS. I like it, I deal with the fact that my machine is somewhat slower for using it, but I feel the benefits if for any reason my laptop is lost or stolen far outweigh the inconviniences.

I haven’t really had any problems with my mac before now and I don’t see any reason that my system should be anything but standard. Since I’m not the only one that has been experiencing these issues, one can only assume it’s fairly widespread.

If only I’d know, I could have saved myself hours by simply turning file vault off. I mean I took the trouble to reboot once and clean up my home directory so the OS could fully recover it’s space.

To anyone reading this contemplating an upgrade, TURN FILEVAULT OFF FIRST!

The good news

The only good to come from the whole experience is that I ended up with the clean install I kinda wanted anyway. Though not really through choice.

Also next time I’ll be running a simple google search for “snow lepoard upgrade problems” first and hopefully timemachine means I’ll have consistent backups, before I start.

your software has bugs

Your software has bugs, go ahead, say it, try it on. Does it scare you? It doesn’t scare me. I know mine does, this isn’t a shock, revelation or epiphany for me. I had that years ago:

One dark stormy night with a start I sat bolt upright and realised I wasn’t perfect, that I couldn’t write perfect code. I sat through the rain and the thunder awake and frightened, but as the sun broke the next morning it a clear new day dawned on a world washed free of it’s sins. I felt renewed, rejuvenated; I bounded to the office, spearheaded an overhaul of our development process, got a more agile workflow implemented with fast iterations and complete management support.

Ok, it wasn’t quite like that. I was actually up all night because someone somewhere had been freaking out about yet another bug the day before. It was affecting one user, and it would only be a matter of time before it would be affecting others – then like dominoes all of them; soon they’d be the rats leaving our sinking ship upstream and they’d take the paddles with them – in short: DOOM!

It’s very easy to find a bug, say it’s obvious and should have been tested, it’s quite another to test all the functionality and find all of the bugs before launch. My software has bugs, so does yours and everyone else too.

get over it and stop blaming others for your problems

Bugs are a result of code, written by programmers- but it’s not always just the programmers who are to blame. Organisational pressures leading to scope and feature creep, poor design and processes or a lack of any sort of roadmap will all contribute to the problem.

So many times I’ve been working to a deadline (beginning, middle or end – it doesn’t really matter once a timeline is fixed any changes will incur a cost), then someone comes along and starts a sentence with “What about…” and totally blows the schedule. The problem is people rarely take into account the very simple fact that the schedule wasn’t set to include this new task, or the next next one.

This schedule pressure then leads to rushing either the design, the testing, the coding or all of them – this more or less ensures there will be more bugs.

Common excuses I hear for this are:

• It’s obvious, and should have been thought of. Sometimes this is a valid comment, but I have never been part of a team where the obvious was actually missed. In my experience this has almost always been used as some rhetorical comment to excuse someone for not mentioning a feature until launch or later.

• If we don’t have that for Friday’s launch, we won’t get customer X< The short simple answer should always be, if this goes into the current iteration- no customers will get a launch Friday.

• Adding would mean getting so many more customers This is such a great trap for a business- so good I’ll be writing much more about it in the future. Oftentimes it’s political or the result of an organisation without any clear goal setting or planning.

Schedule pressure is often further exacerbated by not making any allowances for bugs. If you don’t make allowances for fixing them post launch, you’ve already missed your next deadline.

what can we actually do about them?

There are a few things we can do organisationally and individually to lessen their impact. Start by not being afraid of them, accept they’re a fact of life and get over it. Shit happens, and it piles up – get a shovel or get out of the way. Look to the processes and people and streamline the development workflow. Everyone involved needs to think things through. Finally once you’ve accepted bugs, worked to minimised them in development deal with them calmly and rationally, if at all.

deal with the workflow issues

If your development processes seem to be creating a lot of bugs, they’re the fist place to look. These are going to be the hardest to change, but they’ll also give you the biggest returns. A few of simple steps to take:

• Design the interfaces first Changes to desgin mid-stream cost at any stage of the cycle, but the earlier they’re discovered the less of an impact it will have. At least wireframing your interfaces means everyone gets a good look at them before development starts, and can say “what about…” early.

• Remember changes cost When someone asks for a change, make sure you point out that changes will affect delivery. Ask them why it wasn’t thought of earlier. Don’t take anything as read and make sure nobody else does either.

• Iterate often Small quick iterations mean features go into use quickly and mean less changed code and less places for bugs to hide. This also allows bugs to form part of the next iterations work.

all bugs are not created equal

Not all bugs will affect people equally. Minor display issues are not as important as an issue where user data is randomly disappearing. An issue where the front page of your website is full of gibberish is far more important that a newsletter not being sent on time.

All bugs should enter a triage system, where the scope of the problem is analysed and a prioritisation decision is taken. There is no room for rhetoric, blame or politics in this process and clear descriptions of the problems are key. The title of this post is verbatim the subject line from quite a few emails I’ve seen in my life, the body is usually not much more helpful and generally descends into politics and conflict. A minor display issue affecting some users is hardly “irreparably damaging”, “actionable”, cause for anyone to “seek any and all legal recourses for reimbursement or compensation” or cause to run off and offer the person our most heart felt and abject apologies for the inconvenience.

We need to step back, look at the extent of the problem and respond appropriately. Going off on one while a wild wacky tale to tell alter, isn’t really professional or productive.

Which leads us to…

not all bugs need to be fixed immediately, or even at all

In a perfect world, we’d fix every bug as soon as it was reported. Then again, the world wouldn’t be so perfect because we’ve got a bug in our code… in a slightly more perfect, yet undeniably imperfect world we’d like to fix bugs as soon as they happen. This isn’t always going to be possible and for various reasons it may not make sense to fix a bug immediately.

Take for example the following completely hypothetical situation. You’ve got a bug in some obscure import routine written for one customer a year and a half ago. The sales team promised it was going to be the next big thing, would open the door on a whole raft of customers that used that package – it turned out to be just the one and they may or may not renew their contract in six months time. Politics aside, given certain situations the import fails and you might choose to just not fix the bug

• They’re unlikely to renew and fixing it isn’t going to sway them or get you any new customers Don’t fix it and just remove the whole broken import from a future iteration. Chalk it up to learning and plan new features better so you’re addressing the needs of your users

• A work around exists Your time might be better spent elsewhere, especially if the problem only affects a single or small number of customers

• Planned developments will obsolete the feature A reworking of the feature, section or other areas of your website, the integration of a new API or a new workflow or way of doing things may mean the bug just dissapears in a future revision. One caution with this, as with any bug fix the promise should be delivered to the cusqtomer on time