1.9 install hangup

1.9 install hangup

by Jim Lockwood -
Number of replies: 10

Installation proceeds ok until the point below then stops.

Would someone please tell me what this means and how to fix it?  PLEASE!


(mysql): SELECT name FROM mdl_config WHERE name = 'version' LIMIT 1  



(mysql): UPDATE mdl_config SET value = '2.0071E+9' WHERE name = 'version'  



(mysql): UPDATE mdl_tag_instance SET itemtype = 'post' WHERE itemtype = 'blog'  



(mysql): SELECT name FROM mdl_config WHERE name = 'version' LIMIT 1  



(mysql): UPDATE mdl_config SET value = '2.0071E+9' WHERE name = 'version'  



(mysql): SELECT name FROM mdl_config WHERE name = 'version' LIMIT 1  



(mysql): UPDATE mdl_config SET value = '2.0071E+9' WHERE name = 'version'  



(mysql): SELECT name FROM mdl_config WHERE name = 'version' LIMIT 1  



(mysql): UPDATE mdl_config SET value = '2.0071E+9' WHERE name = 'version'  



(mysql): SELECT name FROM mdl_config WHERE name = 'version' LIMIT 1  



(mysql): UPDATE mdl_config SET value = '2.0071E+9' WHERE name = 'version'  



(mysql): UPDATE mdl_role_names SET name = text  


1054: Unknown column 'text' in 'field list'

           
Scroll to previous warningUpgrade savepoint: Error during main upgrade to version 2.0071E+9Scroll to next warning
Scroll to previous warningMain Upgrade failed! See lib/db/upgrade.phpScroll to continue button
PLEASE HELP!
Average of ratings: -
In reply to Jim Lockwood

Re: 1.9 install hangup

by Richard Enison -
In reply to Richard Enison

Re: 1.9 install hangup

by Jim Lockwood -

Richard, thank you for the link to your dialogue with OS

I followed your instructions in the dialogue to OS.

Tried these:

 $CFG->version = "2007101520";

I think that should override the erroneous value in the database. If that doesn't work, you will need to fire up your favorite database client program (for example, phpMyAdmin if your database type is MySQL) and change the value column in the row of the mdl_config table in which the name column has the word version. If you want or need to do this with a query, this one should do it:

UPDATE mdl_config SET value='2007101520' WHERE name='version';

These produced:

(mysql) SELECT name FROM mdl config wHERE name = 'version' LIMIT 1
(mysql): UPDATE mdl config SET value
= ‘2007101526’ WHERE name = ‘version’
(mysql): SELECT value FROM mdl-config WHERE name
= 'statsruntimedays’ LIMIT I
(mysql): SELECT name FROM mdL config WHERE name
= 'version' LIMIT 1
(mysql): UPDATE mdLconfig SET value
= ‘2.0071 E+g’ wHERE name = ‘version’ 

"there is already a role with this name!"  (in a pink box)

then a Continue button, which brings it right back to this when pressed.

I am totally perplexed!

Any other suggestions or instructions?

JL



In reply to Jim Lockwood

Re: 1.9 install hangup

by Richard Enison -
JL,

Did you read the entire thread? Because if you did, then you know that after inserting the line I recommended into config.php, OS ran into an upgrade loop, perhaps somewhat similar to the one you are reporting (although he didn't say anything about a role already existing; I'm not sure what that's about yet), which he was able to escape when I suggested he remove that same line from config.php. Have you tried that?

At least it's not complaining about the text field anymore. Very strange. Because OS was doing an upgrade, but you seem to be just trying to do a fresh install of Moodle, is that correct? If so, I can't imagine where the lower version number in the database came from in the first place, if it was ever there. And if it wasn't, I am at a loss to explain the error about the text field.

RLE
In reply to Richard Enison

Re: 1.9 install hangup

by Jim Lockwood -

RLE,

Thanks again for the reply.  Yes, I did read entire thread and put the line in and removed it.  No resolution.

I have two domains. On one I'm doing upgrade and the other is a new install. I've been running 1.8.2 with good success for about a year.  Then made the decision to upgrade after backing up my critical files.  Now I'm regretting it!  I have the old version in maintanence mode but am hung up with upgrade.  The new install under a different domain hangs up, too. I'm at a total stand still now on both efforts!

JL

In reply to Jim Lockwood

Re: 1.9 install hangup

by Richard Enison -
JL,

I would suggest following the steps in PS (skodak)'s post for your upgrade site. If there is something you don't understand about a specific step, ask.

For the fresh install site, you might just delete everything (the files, the database tables) and start over with a new download, and hopefully you will get his fix, which he said would be released today.

RLE
In reply to Richard Enison

Re: 1.9 install hangup

by Jim Lockwood -

RLE,

My two domains are hosted by the same provider. I access the two domains under the same login with the provider, but they are listed as separate accounts. Is it possible that when attempting to do new install on the domain account which never had Moodle that the config file in the other domain account which has Moodle 1.8.2 is affecting the new install because maybe the two accounts are housed on the same server???

Also, how will I know when the fix by PS (skodak)'s post will be completed and available?

Thanks again!

In reply to Jim Lockwood

Re: 1.9 install hangup

by Richard Enison -
JL,

  • By the config file I presume you mean config.php. There should be two separate files of that name in two separate directories. I know of no reason why one should be interfering with the other. There are lots of cases of multiple Moodle sites on the same server reported in this forum; I have never seen a report of such interference. Also, if by the config file you really mean the config table in the database, again, as long as they are in different databases or use different table prefixes, it should be okay.
  • The new build of Moodle 1.9.3+ with PS's fix in it was supposed to be available Wednesday (my time), but I just went to the download page and it says the latest build is 3 days 9 hours old, which would be late Tuesday afternoon. When you go to the Moodle core download page, and it says how long it has been since the weekly build of 1.9.3+, subtract from the current time and if that turns out to be Wednesday, January 14 or later, then it is ready. On the other hand, I could have misunderstood his post, which is dated Tuesday at 1:20 a.m. my time, in which he said it would be released "tomorrow". Maybe by tomorrow he meant Tuesday. In that case, it is ready now. Because it is supposed to be built weekly, so the next build will probably be next Tuesday, January 20. However, he is in central Europe, so his post was probably around 10:20 a.m. Tuesday his time, so maybe he thought he would have an extra day to get his fix into it but it was released a day early. More likely, he had already uploaded it to CVS at the time of his post, it was included in the build that afternoon, and released to the public the next day.
RLE
In reply to Richard Enison

Re: 1.9 install hangup

by Jim Lockwood -

I succeeded in a clean install of 1.9.3+ by creating a subdomain on my account which never had Moodle and installing it there.  It is complete and functional.  I have made no modifications to it at all.

Now my focus is transfering my existing data, theme, quizes, and teaching modules from my Moodle 1.8.2 (which I've been running for a year) to the new Moodle installation.

Is this approach possible?  (Instead of doing an upgrade of the 1.8 to 1.9)

If so, please kindly advise.

Thanks in advance.

In reply to Jim Lockwood

Re: 1.9 install hangup

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Hello,

I am afraid the only safe way is to:
  1. Restore database from sql dump or any other full backup. (Everybody does full backup before upgrade, right?)
  2. Save information from php info page - this info describes your server environment, this might give us a clue what is wrong and where
  3. Upgrade to next weekly 1.9.3+ build (to be released tomorrow).

I just committed a new diagnostic code that should detect one type of problem that might cause this. It is executed on admin/index.php page.

Very many sites were upgraded to 1.9.x, this is the second time I see something similar - that is why I suppose it is more probable that the problem is caused by server configuration or PHP executables.

Petr