Moodle upgrade nightmare (1.9 - 2.2)

[dgsmith]

Having the most torrid time with moodle. We're migrating to a new server and in the process decided to take the opportunity to upgrade to 2.2 in the interim. However, despite having started the actual upgrade bit around 2:30pm yesterday, it's still barely done. The plugins it seems to either fail on for one reason or another or simply just time out.

 

I've amended the php execution time and the timeout time for cgi in IIS though it's failing every 5-10mins or so on something. I don't think I could stand refreshing all day and sorting out each little niggle manually. Should it not just upgrade what it can then throw back issues in the end? For instance this morning it had stopped because upgrading a table found to not exist and go progress any further.

 

I see the advice is to the use the CLI which is probably too late now though i'd cry if I had to scrap it and start again..

[FN-GM]

You might be able to start off from where you left it in the CLI. I have done this in the past when an upgrade froze.

[dgsmith]

I wish it was as simple as it just freezing. It wouldn't be too bad if there was a way to make it skip errors or things it can't find, do the rest and let me sort the issues out manually at the end, but it's halting on every thing and it's just not viable, and I can't see a way to change this behaviour..

[Achandler]

Upgrade in stages (that's what I did at my old work).

 

Remove all your plugins to and then upgrade the base system. I found it seemed to freeze but then about 10 minutes later it suddenly jumped forwards.

[penfold_99]

@dgsmith

 

how large is you moodledata folder? If its big it will take an age as moodle needs to migrate all files from the old course based file system to a checksum based file system.

It is best to do this on the command line as it avoids a lot of the timeout issues.

[bencellis]

Having just upgraded 190+ Moodle 1.9s to 2.4 via 2.2, the CLI is really the way to go. It should continue from where it left off but I would make sure all you sort out the plugins. Make sure you have install the latest versions of any plugins for your version of 1.9. Move all the non standard plugins folders out of the way - the tables will remain ready for upgrade later - then upgrade. I had to re-do the upgrade for some of the larger instances 3 or 4 times - having to resolve any issues along the way, some of which took more than 8 hours to upgrade. I used the nohup command to avoid being interrupted if my ssh session timed out. The biggest issues came from course files where old files, duplicate files and files with the same name caused no end of issues. Afterwards re-install the plugin if they have 2.2 versions. Some half of the 3rd party plugins did not have a 2.2 version so you will have to decide what you are going to do about them.

 

Good Luck

 

Ben

[dgsmith]

Moodledata folder about 70GB Next time CLI will be the way forward I think. Lost count of the amount if refreshes and timeouts though!

 

As we barely had any custom plugins I opted to try and have them upgrade at the time.. probably won't next time(!) It did eventually upgrade.. apparantly, after I removed some suspect plugins and there is now what appears on first glance a working setup, though initially only the "administrator" user login worked.

 

From what I have read it would normally have something to do with the password salt needing to be copied to the new config, but our old config had no password salt reference. It would seem that I can login as admin, browse to a user and change their password that way which then allows login, but alas certainly don't want to be doing that for everyone. Would there be any other reason why logins no longer work?

I would considering having users change their password themselves via the change password form, but this returns a 404 not found despite the php file being there, quite bizarely!

 

It's a mysql database for accounts (ldap will be at some point) and all accounts are still there and active.

[dgsmith]

So it seems like the way the passwords are being stored is differently.. when changing an account password to the same password as before, the md5 hash in the database changes completely, which is probably why existing users can't login.. argh! How would I make this use the original method?

[bencellis]

Did you change the hash in the config file? If you are using your 1.9 config file then you should not be having an issue with passwords.