Upgrade D6.20 to D7 fails with PDO Exception

Are you visiting update.php immediately after restoring the backup? Those columns should be created by the update, and locale module shouldn't be running on update.php.

I too see the third (ssid) exception when attempting an upgrade from 6.20 to RC3.

So I tested this and I can only reproduce the ssid exception in the following circumstances:

* Start with a Drupal 7 database.
* Don't empty it.
* Restore a Drupal 6 backup into that database.
* Hit update.php

If I empty the D7 database first before restoring the backup, everything runs smoothly.

Thx catch, this saved my evening. I also did not empty the database before running upgrade.php and ran into the same error.

Empty database first, then import -> everything upgrades fine.

I don't understand "Drupal 6 database that is restored into Drupal 7" in the first place. That makes no sense. You don't need to install Drupal 7 before you can upgrade from D6.

I think this means restored into an empty database which is pointed to in the D7 settings.php.

If the update fails, and you repeat the restore without emptying the new database first, then new tables added in Drupal 7 will still be there.

CvW: Can you list the installed contributed modules, as this may help diagnose the problem.

It is likely one specific module that is causing problems, you could try to figure out which.

Something that works rather fast is the divide and conquer/bisect mechanism. Uninstall 50% of your modules, try the upgrade path. If it works, then only leave 25% more modules installed, if it doesn't, uninstall 25% more modules. And so on :)

Drupal tests bugs against dev releases.

I got these issues with a new D7 site. When I enabled locale module, I got a WSOD which persisted even though error reporting was switched on and I had bumped up the memory limit. When I ran update.php I got the errors as described above. The issues disappeared once I deleted the locale module folder.

I do have quite a few contrib modules enabled on that site, but I dont think this is a 'contrib modules fighting with each other' problem. If anyone thinks otherwise, I am happy to list the modules. I am tempted to change the title, but just want to see can anyone else reproduce this on clean D7.

I got this too tonight. Going to test again to see if it was a fluke, but some interesting tidbits:

- Site's running Pressflow, but an older version (I think 6.17 or so)
- Logged in as uid 1, verified the site looked good.
- I ran 'drush up' which took care of the core, modules, and theme upgrades to the latest 6.x versions.
- Clicked around, further verified the site looked good.
- I used the Upgrade Assist module (part of the Upgrade Status module) to disable all contrib modules before attempting the upgrade.
- Did 'drush dl drupal-7.0; drush cp -r drupal-7.0/* .' to move in the core files.
- Hit update.php

Error:

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => e673ceda49d2ed489f7d97bdea80b595 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 204 of /Users/webchick/Sites/x/html/includes/session.inc).

Looked in the system table with the previous attempt, and verified that other than the upgrade assist module, all contrib modules were set to status = 0 in the database.

Reading the rest of the issue, I tried restoring D6 database from backup, setting $update_free_access = TRUE and going directly to update.php. I get a WSOD.

Looking into the log, I get this:

[12-Jan-2011 00:18:26] PHP Fatal error:  Only variables can be passed by reference in /Users/webchick/Sites/x/html/modules/upload/upload.module on line 619

[12-Jan-2011 08:30:13] PHP Fatal error:  Cannot redeclare theme_link() (previously declared in /Users/webchick/Sites/store6/html/includes/theme.inc:1369) in /Users/webchick/Sites/x/html/sites/all/modules/contrib/link/link.module on line 531

So obviously, the first problem is at least partially caused because when I copied in Drupal 7's files it didn't remove Drupal 6's files. :P Adjusting upgrade mechanism momentarily...

Any news on fixing this bug error? I have the same problem.

I just hit the same error trying to update from 6.20 -> 7.0. Followed instructions in UPGRADE.txt to the letter. I even tried nuking my /sites/default/modules directory (as per comment #10) but still got the following:

The website encountered an unexpected error. Please try again later.

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => fcc4d8f7955c7c3d27a5149d3ee6da18 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 204 of /usr/www/users/####/####/dev/includes/session.inc).

So... reloaded the D6 db from backup, tried running update.php again, and got the following 2 error messages (1 in the content area, the 2nd one *below* the content area):

Error message
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'source' in 'field list': SELECT source FROM {url_alias} WHERE alias = :alias AND language IN (:language, :language_none) ORDER BY language ASC, pid DESC; Array ( [:alias] => update.php [:language] => en [:language_none] => und ) in drupal_lookup_path() (line 177 of /usr/www/users/####/####/dev/includes/path.inc).
The website encountered an unexpected error. Please try again later. 

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => fcc4d8f7955c7c3d27a5149d3ee6da18 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 204 of /usr/www/users/####/####/dev/includes/session.inc).

Any clues?

When you reload your database, make sure to empty it first and remove all existing tables. If you don't then Drupal 7 thinks that it already has done the necessary steps to at least provide the minimum compatibility so that it can run update.php.

Did you remove your module folder after you reloaded your D6 database without cleaning up first? That could be the issue then..

We could try to make our "initial upgrade necessary" check more error-proof but we can't support partly upgraded sites, that gets way too complex.

Hm... well the very first time I tried running update.php I did get a bit further, but the update choked on #7005 (one of the taxonomy updates) so that's when I tried the following (twice):

- reloaded the D6 db from backup (without emptying/removing first),
- deleted all D7 files and directories (except for "sites"),
- restored all D6.20 files and folders,
- confirmed everything was working again,
- deleted a vocabulary that wasn't being used for anything (bc it had shown up in my initial error message),
- disabled all non-core modules,
- nuked the contrib'd modules directory (sites/default/modules)
- deleted all directories except "sites",
- re-uploaded all D7 directories and files,
- ran update.php again.

So Berdir, are you suggesting that if update.php fails or throws any errors I need to nuke *everything* and completely restore all files and the db from scratch?

crispinbailey: Yes, it's best to start completely over -- otherwise you'll be working from a slightly corrupt half-way state...

Until there's a reproducible bug report that doesn't result from a partially upgraded site I'm downgrading this.

I tried to update from 6 to 7 with all modules turnt of. I left the Locale module on and got the message "Warning: Cannot use a scalar value as an array" with the locale.module. I turned back to my old installation and turned Locale of, now no problems with updating.

@grootte - could you open a new issue for the locale bug? Please include the line number of the error message, and also whether you have any contrib modules installed in D6 (particularly i18n).

This problem still exists.

Yeah, I'm getting this as well. Followed upgrade.txt to the letter and got this error.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 's.ssid' in 'where clause': SELECT u.*, s.* FROM {users} u INNER JOIN {sessions} s ON u.uid = s.uid WHERE s.ssid = :ssid; Array ( [:ssid] => ) in _drupal_session_read() (line 90 of includes/session.inc). happens if you try to run update.php via HTTPS while being logged in to the site. The two work-arounds are either to logout and set $update_free_access = TRUE; or run update.php via HTTP.

I Got this error:

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => 331d68f07fa8b5c0c0d5488eed10eed3 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 203 of /home/bank/public_html/includes/session.inc).

Settings has free access but I don't have user 1 anymore.
Could it be my problem?

#27 sounds reproducible to me, back to a bug report.

@catch what you mean with empty the database? Erase all the tables?

I have a test site. I imported my production site database to reflect it how it is today to the test site. Both on 6 version.
Then trying to upgrade the test site I got the ssid error above.
Could it be the problem?

I have been battling the same issue for 2 days now :(

@a.luiz.n: yes before re-attempting an upgrade you should:

- drop the database
- recreate the database
- re-import the database dump.

Dropping each table individually also works.

@catch tried your suggestion. Still having errors. But I'll give it another shot to see what happens. Will keep you posted.

If you always get s.sid, please confirm whether you're visiting the site via http or https.

This is work worked for me. My main concern was extracting database information for "users" and "user_roles". Upgrading from Drupal 6 to Drupal 7 (on my main site) was giving me A HEADACHE. So here is what I did.

Please back up your files and database before trying my suggestions

1. Restored my web files and database backup to a previous working Drupal 6 condition
2. Created a subdirectory on my hosting
3. Created a new and separate drupal database. This will later serve as a container
4. Installed a fresh Drupal 6 in new subdirectory
5. Imported Database from "main" website into database of new subdirectory. Make sure site was still functioning after
6. Update your new subdirectory from D6 to D7 (I made sure I didn't update to a 7.X-dev.)
7. At this point you may port your subdirectory drupal and new database structure to your root directory. I will advice deleting all previous D6 files. Of course you should keep your contributed modules and themes (located in root/sites). "

Hope this helps.

Is anyone/everyone using Backup/Migrate in their process? When I migrate to a dev site to do the upgrade, I'm pulling my live db down via backup_migrate, then importing it with a normal sql import to do the upgrade....I was wondering if that could have something to do with it or if it shouldn't matter. (just trying to figure out why so many of us are having this issue on such a basic level)

My latest attempt error, related to sid/ssid but with different error:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes: ALTER TABLE {sessions} ADD PRIMARY KEY (`sid`, `ssid`); Array ( ) in db_add_primary_key() (line 2818 of /d7/includes/database/database.inc).

This error, specifically, may be related to my previous question about people using backup_migrate: #982966: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071

EDIT: Imported a dump made with phpmyadmin instead and go the same error...so maybe not BAM related...

@Rob_Feature: You can empty session table and other tables before attempting the upgrade. That might help.

Best Wishes,

Fabian

@Fabianx: Yup, emptied session tables and it was a nogo...same error.

Also, I ended up (just to see what would happen) disabling AND uninstalling ALL MODULES on the site including core modules. Same error.

A question: do I have to update also all the modules to their newest version, or just the core?

I dropped all the tables, kept the database.
Restored my db dump.
Try it again and same error.

ps: Visiting the site via http

sub

Following the upgrade.txt I was able to migrate drupal core from 6.22 to 7.2 without any errors.

I did not user/have locale. Here is an overview of the steps I took: http://paste2.org/p/1487354

I tried the #43 method and got the same error, but I use the locale module.

Does anybody here with the issue about ssid use locale module?

I am NOT using locale (and am getting the errors), so I don't think we can narrow it down to that.

I did it as #35 said and everything worked fine.
those are my steps:

- Core and modules update (D6)
- Put site offline
- Select default theme: Garland
- Disable contrib modules

- Install a new drupal 6 in a subdirectory, using a new database
- Import the real site's database into the new created D6 database
- Upgrade the subdirectory site to 7

- Delete all drupal 6 files from root (except for sites directory)
- Move all files from subdirectory to root (including settings.php)
- That way your site will point to the new created and upgraded database and you'll keep your old one as a backup, then you can delete it if you want.

Thanks @npoku!

It seems many people are getting this error because they are using backup_migrate or mysqldump to load a D6 database over top of a D7 database. The problem is these methods DON'T empty the database before starting: they just drop each table that is about to be created from the dump, leaving tables that are in D7 (but not in D6) unmodified.

@lyricnz I havent used backup and migrate and I've imported my dump to a brand new database.

I fixed this by clearing my browser cache. Apparently if you have an old Drupal session in your browser, it attempts to load it with the new settings, even though it hasn't upgraded the database yet.

subscribe

I hit the error that has been mentioned here, and I found a solution. I think this deserves a code fix, but I'm around it for now.

Ubuntu 11.10 with root cli access
MySQL 5.1.58
Apache 2.2.20
PHP 5.3
Drupal 6.22
Upgrading to Drupal 7.10
Running under SSL

Followed the steps in upgrade.txt to the letter. I did it three times and always got the same error. When I went to https://___/update.php it immediately displayed this error page:
"
Error

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 's.ssid' in 'where clause': SELECT u.*, s.* FROM {users} u INNER JOIN {sessions} s ON u.uid = s.uid WHERE s.ssid = :ssid; Array ( [:ssid] => DVSsGn6cA7U-617ZTNXnMvfoUkd1dRpS8tZiOQzQn_o ) in _drupal_session_read() (line 92 of /home/mark/www/includes/session.inc).
The website encountered an unexpected error. Please try again later.
Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => DVSsGn6cA7U-617ZTNXnMvfoUkd1dRpS8tZiOQzQn_o [:db_condition_placeholder_1] => DVSsGn6cA7U-617ZTNXnMvfoUkd1dRpS8tZiOQzQn_o ) in _drupal_session_write() (line 206 of /home/mark/www/includes/session.inc).
"

I looked at line 92 of session.inc, and noticed that it is an if($is_https) function:
// Otherwise, if the session is still active, we have a record of the
// client's session in the database. If it's HTTPS then we are either have
// a HTTPS session or we are about to log in so we check the sessions table
// for an anonymous session with the non-HTTPS-only cookie.
if ($is_https) {
$user = db_query("SELECT u.*, s.* FROM {users} u INNER JOIN {sessions} s ON u.uid = s.uid WHERE s.ssid = :ssid", array(':ssid' => $sid))->fetchObject();
(that last line is 92 in my session.inc)

I reset my site to not use SSL, and then re-did the whole process. Worked like a charm.

Here are my updated steps for the upgrade:

Clone your server and do the whole process on a test site first. Update the upgrade.txt document to fill in the precise steps that you have to take on your site.

MAJOR VERSION UPGRADE
---------------------
To upgrade from a previous major version of Drupal to Drupal 7.x, after
following the instructions in the INTRODUCTION section at the top of this file:

1. Check on the Drupal 7 status of your contributed and custom modules and
themes. See http://drupal.org/node/948216 for information on upgrading
contributed modules and themes. See http://drupal.org/node/895314 for a list
of modules that have been moved into core for Drupal 7, and instructions on
how to update them. See http://drupal.org/update/modules for information on
how to update your custom modules, and http://drupal.org/update/theme for
custom themes.

You may decide at this point that you cannot upgrade your site, because
needed modules or themes are not ready for Drupal 7.

2. Update to the latest available version of Drupal 6.x (if your current version
is Drupal 5.x, you have to upgrade to 6.x first). If you need to update,
download Drupal 6.x and follow the instructions in its UPGRADE.txt. This
document only applies for upgrades from 6.x to 7.x.

3. Convert the site from SSL to non-ssl
Edit both your apache config and (if needed) the $base_url in your settings.php.

4. Log in as user ID 1 (the site maintenance user).

Make absolutely certain that you are logged in to http:// instead of https://!

5. Go to Administer > Site configuration > Site maintenance. Select
"Off-line" and save the configuration.

6. Go to Administer > Site building > Themes. Enable "Garland" and select it as
the default theme.

Disable all other themes besides "Garland".

7. Flush Caches.

8. Go to Administer > Site building > Modules. Disable all modules that are not
listed under "Core - required" or "Core - optional". It is possible that some
modules cannot be disabled, because others depend on them. Repeat this step
until all non-core modules are disabled.

If you know that you will not re-enable some modules for Drupal 7.x and you
no longer need their data, then you can uninstall them under the Uninstall
tab after disabling them.

9. In PHPMyAdmin, make a backup of the database.

10. On the command line or in your FTP client, remove the file

sites/default/default.settings.php

11. Remove all old core files and directories, except for the 'sites' directory
and any custom files you added elsewhere.

If you made modifications to files like .htaccess or robots.txt, you will
need to re-apply them from your backup, after the new files are in place.

12. If you uninstalled any modules, remove them from the sites/all/modules and
other sites/*/modules directories. Leave other modules in place, even though
they are incompatible with Drupal 7.x.

13. Download the latest Drupal 7.x release from http://drupal.org to a
directory outside of your web root. Extract the archive and copy the files
into your Drupal directory.

On a typical Unix/Linux command line, use the following commands to download
and extract:

wget http://drupal.org/files/projects/drupal-x.y.tar.gz
tar -zxvf drupal-x.y.tar.gz

This creates a new directory drupal-x.y/ containing all Drupal files and
directories. Copy the files into your Drupal installation directory:

cp -R drupal-x.y/* drupal-x.y/.htaccess /path/to/your/installation

If you do not have command line access to your server, download the archive
from http://drupal.org using your web browser, extract it, and then use an
FTP client to upload the files to your web root.

14. Re-apply any modifications to files such as .htaccess or robots.txt.

15. Make your settings.php file writeable, so that the update process can
convert it to the format of Drupal 7.x. settings.php is usually located in

sites/default/settings.php

16. Run update.php by visiting http://www.example.com/update.php (replace
www.example.com with your domain name). This will update the core database
tables.

If you are unable to access update.php do the following:

- Open settings.php with a text editor.

- Find the line that says:
$update_free_access = FALSE;

- Change it into:
$update_free_access = TRUE;

- Once the upgrade is done, $update_free_access must be reverted to FALSE.

17. Backup your database after the core upgrade has run.

18. Change the site back to ssl.
Apache and (if needed) the $base_url in your settings.php

19. Replace and update your non-core modules and themes, following the
procedures at http://drupal.org/node/948216

20. Go to Administration > Reports > Status report. Verify that everything is
working as expected.

21. Ensure that $update_free_access is FALSE in settings.php.

22. Go to Administration > Configuration > Development > Maintenance mode.
Disable the "Put site into maintenance mode" checkbox and save the
configuration.

I too have been struggling with this problem I am attempting 6.24 to 7.12, with the same error. And this is a stock standard install, site is using garland. First of all my site is backed up and I have retried the upgrade from a fresh copy every time, taken it off line and cleared is caches. This is no partial upgrade issue!

I've created new database, I've created empty databases, and then imported, I've created new databases then imported, I've created new d6 installs imported and then tried an upgrade by both new empty and newly createed d7. On top of that matrix I also redid all of the above but manually created a d7 settings.php, and then redid that with disabling all core-optional modules. I've also tried drush ! And always there is some kind of pdo error. The upgrade is impossible. Fortunately the site is very small and I can recreate it from scratch very easily.
However I have a larger site, that does have contrib modules, and I won't even attempt that upgrade until a stock upgrade will work.
So here is a summary matrix of what I have tried and none of it has worked, and always I restarted with a d6 backup, cleared the caches, site offline. In addition and wiped out the failed attempt, both db and files.

1. into new empty db,
2. into freshly installed d7 db
3. copied d6 into new d6 - import new d6 into new empty db
4. copied d6 into new d6 - import - newly install d7 db
5. step 1 with manual changing settings.php
6. step 2 with manual changing settings.php
7. step 3 with manual changing settings.php
8. step 4 with manual changing settings.php
7. step1 - all core optional modules disabled
8. step2 - all core optional modules disabled
9. step3 - all core optional modules disabled
10. step4 - all core optional modules disabled
11. step5 - all core optional modules disabled
12. step6 - all core optional modules disabled
13. step7 - all core optional modules disabled
14. step8 - all core optional modules disabled
15. step9 - all core optional modules disabled
16. step10 - all core optional modules disabled

Again all methods do not work.

EDIT: this is not an ssl site standard http

I've encountered this problem as well. From latest D6 to 7.12. After reading this thread, I tried following the steps of #53, but still encounter the same problem. My particular error references 'registry' table:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'foobar.registry' doesn't exist: CREATE TABLE {registry} ( `name` VARCHAR(255) NOT NULL DEFAULT '', `type` VARCHAR(9) NOT NULL DEFAULT '', `filename` VARCHAR(255) NOT NULL DEFAULT '', `module` VARCHAR(255) NOT NULL DEFAULT '', `weight` INT NOT NULL DEFAULT 0, PRIMARY KEY (`name`, `type`), INDEX `hook` (`type`, `weight`, `module`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8; Array ( ) in db_create_table() (line 2688 of /Users/foobar/path/drupal/includes/database/database.inc).

At this point it seems that update is looking for something my system does not have.

Okay, I found success building off of all the way back to #4.

So I tested this and I can only reproduce the ssid exception in the following circumstances:

* Start with a Drupal 7 database.
* Don't empty it.
* Restore a Drupal 6 backup into that database.
* Hit update.php

If I empty the D7 database first before restoring the backup, everything runs smoothly.

Since other comments were suggesting keeping the new D7 tables and simply restoring the D6 backup over the D7 db, I first tried that, but ran into a series of fatal errors when update did not find tables it expected, or found fields/indexes in tables it did not expect.

Having confirmed that this approach would not work, at least not without a lot of repetition and manual editing of the db, I dropped all tables in the D7 db, restored the D6 backup into the D7 db, and ran update. No problems. 130 updates. No errors.

Why this worked and doing this the conventional way, I don't know. I had tried D6- and D7- version settings.php files previously with no success.

Anyway, another data point to help track this down.

@laura s - are you restoring with a D6 backup with all contrib disabled?

@k8 - Contrib disabled, yes.

I was receiving similar errors noted in these posts attempting a 6.26 site to 7.14. Per the suggestions in #49 I did the following and then re-ran update.php and it worked to upgrade core:

1) Make a copy of my D6 site folder and use this version for the D7 upgrade

2) Download 7.14 and add all the 7.14 files to the folder I created in #1

3) Make sure to add the /sites folder from my D6 site so I have my existing settings.php file (and all existing D6 contrib modules) mapping to the D6 db

4) Make sure to disable all contrib modules - you can re-enable them later when upgrading them

4) Make sure the settings.php file is writable

5) Make sure you've set the update_free_access to TRUE so you do not need to be logged in to run update.php

6) Clear browser cache (very important)! I was using Chrome so I shut Chrome down, then fired up Firefox, made sure to clear browser cache and then I attempted the upgrade/update in Firefox

7) Close browser and re-start it before attempting to run update.php per above

8) Now fire browser up and run update.php again

This time the update successfully ran and I was successful in upgrading to Drupal 7.14. The update generated no errors. So just make sure to clear your browser cache and restart the browser so you're clearing all browser sessions.

Hope this helps.

Best-

Trevor

I've posted my upgrade process step-by-step over on my site (might be helpful for others attempting this):
http://variantcube.com/upgrade-drupal-6-to-drupal-7

-Trevor

After searching around for a bit, found the solution to this same error I was having:

http://forums.acquia.com/comment/55761#comment-55761

If you're current settings.php file isn't in drupal 7's format, you will get semi-random sql errors about missing columns or whatnot. Use the settings.php file from Drupal 7 but replace the creds w/ the current one.

Following up, I performed an upgrade on another site recently and encountered no real problems. The steps are documented in http://drupal.org/node/570162, which has been updated and now seems to have a workable process, at least for some sites. (Note: I have not confirmed by re-attempting a dry-run upgrade of the previous site I was working on.)

If you have the same error on the first page at /update.php (without op=info), then:

Make sure that you'll include in settings.php the following variables:

/**
 * Migration 6 to 7 variables
 */
$update_free_access = TRUE;
$conf['maintenance_mode'] = TRUE;
$conf['maintenance_theme'] = 'bartik';

before going to: /update.php
So the sessions table shouldn't be used at this point. If it is, please remove the modules which are using it on update process.

Example command to disable all non-core modules and themes:

echo 'UPDATE system SET status = 0 WHERE filename NOT LIKE "themes%" AND filename NOT LIKE "modules%";' | `drush sql-connect`

Also clear the cache:

echo "DELETE FROM cache`drush sql-connect`
echo "DELETE FROM cache_bootstrap" | `drush sql-connect`

And remove any included files from the settings.php file such as memcached, etc.

Also please follow Upgrade process for more info.

There is some still problem with this error on the 2nd page at: /update.php?op=info
Here is the backtrace:

string 'SELECT 1 AS expression
FROM 
{sessions} sessions
WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE' (length=146)
array (size=7)
  0 => 
    array (size=7)
      'file' => string 'includes/database/select.inc' (length=80)
      'line' => int 1264
      'function' => string '__toString' (length=10)
      'class' => string 'SelectQuery' (length=11)
      'object' => 
        object(SelectQuery)[12]
          protected 'fields' => 
            array (size=0)
              ...
          protected 'expressions' => 
            array (size=1)
              ...
          protected 'tables' => 
            array (size=1)
              ...
          protected 'order' => 
            array (size=0)
              ...
          protected 'group' => 
            array (size=0)
              ...
          protected 'where' => 
            object(DatabaseCondition)[14]
              ...
          protected 'having' => 
            object(DatabaseCondition)[7]
              ...
          protected 'distinct' => boolean false
          protected 'range' => null
          protected 'union' => 
            array (size=0)
              ...
          protected 'prepared' => boolean true
          protected 'forUpdate' => boolean true
          protected 'connection' => 
            object(DatabaseConnection_mysql)[1]
              ...
          protected 'connectionTarget' => string 'default' (length=7)
          protected 'connectionKey' => string 'default' (length=7)
          protected 'queryOptions' => 
            array (size=1)
              ...
          protected 'uniqueIdentifier' => string '525c1f1a825748.63162151' (length=23)
          protected 'nextPlaceholder' => int 2
          protected 'comments' => 
            array (size=0)
              ...
      'type' => string '->' (length=2)
      'args' => 
        array (size=0)
          empty
  1 => 
    array (size=7)
      'file' => string 'includes/database/query.inc' (length=79)
      'line' => int 1618
      'function' => string 'execute' (length=7)
      'class' => string 'SelectQuery' (length=11)
      'object' => 
        object(SelectQuery)[12]
          protected 'fields' => 
            array (size=0)
              ...
          protected 'expressions' => 
            array (size=1)
              ...
          protected 'tables' => 
            array (size=1)
              ...
          protected 'order' => 
            array (size=0)
              ...
          protected 'group' => 
            array (size=0)
              ...
          protected 'where' => 
            object(DatabaseCondition)[14]
              ...
          protected 'having' => 
            object(DatabaseCondition)[7]
              ...
          protected 'distinct' => boolean false
          protected 'range' => null
          protected 'union' => 
            array (size=0)
              ...
          protected 'prepared' => boolean true
          protected 'forUpdate' => boolean true
          protected 'connection' => 
            object(DatabaseConnection_mysql)[1]
              ...
          protected 'connectionTarget' => string 'default' (length=7)
          protected 'connectionKey' => string 'default' (length=7)
          protected 'queryOptions' => 
            array (size=1)
              ...
          protected 'uniqueIdentifier' => string '525c1f1a825748.63162151' (length=23)
          protected 'nextPlaceholder' => int 2
          protected 'comments' => 
            array (size=0)
              ...
      'type' => string '->' (length=2)
      'args' => 
        array (size=0)
          empty
  2 => 
    array (size=7)
      'file' => string 'includes/session.inc' (length=72)
      'line' => int 209
      'function' => string 'execute' (length=7)
      'class' => string 'MergeQuery' (length=10)
      'object' => 
        object(MergeQuery)[17]
          protected 'table' => string 'sessions' (length=8)
          protected 'conditionTable' => string 'sessions' (length=8)
          protected 'insertFields' => 
            array (size=7)
              ...
          protected 'defaultFields' => 
            array (size=0)
              ...
          protected 'insertValues' => 
            array (size=0)
              ...
          protected 'updateFields' => 
            array (size=5)
              ...
          protected 'expressionFields' => 
            array (size=0)
              ...
          protected 'needsUpdate' => boolean true
          protected 'connection' => 
            object(DatabaseConnection_mysql)[1]
              ...
          protected 'connectionTarget' => string 'default' (length=7)
          protected 'connectionKey' => string 'default' (length=7)
          protected 'queryOptions' => 
            array (size=2)
              ...
          protected 'uniqueIdentifier' => string '525c1f1a80ef18.94061295' (length=23)
          protected 'nextPlaceholder' => int 0
          protected 'comments' => 
            array (size=0)
              ...
          public 'condition' => 
            object(DatabaseCondition)[15]
              ...
      'type' => string '->' (length=2)
      'args' => 
        array (size=0)
          empty
  3 => 
    array (size=2)
      'function' => string '_drupal_session_write' (length=21)
      'args' => 
        array (size=2)
          0 => &string 'c7b30d4163d2cfec24098386ec617486' (length=32)
          1 => &string (length=1111)
  4 => 
    array (size=2)
      'function' => string 'session_write_close' (length=19)
      'args' => 
        array (size=0)
          empty
  5 => 
    array (size=4)
      'file' => string 'includes/bootstrap.inc' (length=74)
      'line' => int 3405
      'function' => string 'call_user_func_array' (length=20)
      'args' => 
        array (size=2)
          0 => &string 'session_write_close' (length=19)
          1 => &
            array (size=0)
              ...
  6 => 
    array (size=2)
      'function' => string '_drupal_shutdown_function' (length=25)
      'args' => 
        array (size=0)
          empty

Ignore this patch, as drupal_save_session() function is not available on update.php

Bottom line for me here: You can't run D7 upgrade with https enabled. It works if you reconfigure to use http instead.

Using the drupal 7 settings file like explained by #59 worked for me. Thanks!