The preparing for update took 15 minutes for me. Maybe that was it.
For me, I went through the preparing for update stage countless times (I can't count very high...or perhaps I didn't try to count since I didn't think I'd need to restart over and over again) and it eventually started. It finished in about the expected amount of time, but the percentage completed numbers could lead you to believe that it wasn't working as well as it should. So here's my mostly irrelevant and possibly off topic rant on that, knowing that in the scope of things, this isn't really a big problem. So stop reading this.
For those who have never tried to write a computer program using progress bars, the secret is that aside from things like downloads and copying files, where there's a finite amount of data and the computer knows what percentage is processed, applying them to just about anything else means deciding arbitrarily that certain tasks make up a certain percentage of the process. Then, lots of programmers bump up the numbers by a certain percentage after each task, leading to things like sudden jumps from 50% to 99% (if it was 50% a second ago, did it do 49% of the task in a split second?), which do nothing to help a user know how much of anything was done, or how much time is left. What users really care about is what percentage of the time waiting has elapsed.
In situations where everybody is running on the same hardware, using the same processor and the same storage media, it's a lot easier to predict. But Lucid did a particularly bad job of showing percentages that help the user. Merely having a count up timer expressed as a percentage would work, or giving each task a percentage based on how much time it takes proportionally, bumping up the percentage as the task happens, and adjusting at the end of the task if the numbers disagree could be more meaningful. Or it could simply have a list of tasks, put an indicator in front of each one as it finishes, and leave it at that. But the types of task names would be meaningless to most users. So programmers should just tell users how long it will take for something this predictable and come up with a way for numbers to increase regularly and proportionally to the expected time. It's more of a mess when users could have any random combination of hardware but it's not the case here.
So, note the time started, figure out what time it should end based on how long they tell you it should take, and check back then. Or check periodically to see if something blew up, and if it shows a percentage done, take it as a sign that things are working, not that the percentage shown is in any way meaningful to you.