As a QA mechanism, we are testing the upgrade path from Drupal 6 to Drupal 7 on a copy of Drupal.org.

CommentFileSizeAuthor
#11 deedotoh6_2011-08-04.sql_.txt119.61 KBwebchick
#10 drush-sup-log.txt21.8 KBwebchick
#9 binlog.txt191.27 KBwebchick
#7 drush-sup-log.txt21.8 KBwebchick

Comments

damien tournoud’s picture

damien tournoud commented

- Upgrade path goes smoothly
- Logged in as Dries
- Enabled Bartik and set it as default
- Disabled the aggregator and search modules (via drush)
- VIsited the block page, no region appear; run drush cc all, the regions appear (maybe a Drush bug?)
- The Help and Main content blocks are not in their regions, but the other are correct; moved the two there manually
- The user links have been moved to the user menu, but the block is not enabled; enabled it manually
- Enabled the download block to show on the front page (how does it appear on d.o??)
- On Bartik settings, enabled the site name and logo, clicked "use default logo", submitted the form, error "The custom logo path is invalid.", unclicked "use default logo", removed the custom logo path, reclicked "use default logo"
- The primary menu is upside down, manually moved the links (d.o specific)
- Moved the "site slogan" to the "featured" region and display it only on the front page
- Enabled the toolbar module and the contextual module
- Enabled the tracker module; it doesn't automatically index nor gives any hint as that indexing is done on cron; forced indexing via a drush job

damien tournoud’s picture

damien tournoud commented

- Gave the "Use the administration toolbar" and "Use contextual links " permissions to roles that have the "Use the administration pages and help" (that should probably have been done automatically)
- Gave "administer modules" and "administer themes" to "Administrators" (this disappeared?)

damien tournoud’s picture

damien tournoud commented

- The forum link is marked as "collapsed" but has no children.

damien tournoud’s picture

damien tournoud commented

This was triggered (but not logged to the screen) somewhere during the upgrade path (found in the watchdog):

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'queued' in 'where clause': SELECT * FROM {aggregator_feed} WHERE queued = 0 AND checked + refresh < :time AND refresh != :never; Array ( [:time] => 1286404607 [:never] => 0 )  in aggregator_cron() (line 313 of /shared/drupalorg/www/modules/aggregator/aggregator.module).

This column was properly added later during the upgrade process.

damien tournoud’s picture

damien tournoud commented

- Enabled the footer block, which was also missing

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

subscribing. going to try this again with a staging db dump to test out #717834: The dependencies declared in core's hook_update_dependencies() implementations aren't actually correct.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
StatusFileSize
new drush-sup-log.txt21.8 KB

Tested this on a copy of the staging.drupal.org database today with drush site-upgrade. Using unpatched D7.

Things look pretty good and then I get smacked with:

WD php: PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated  [error]
for column 'bootstrap' at row 11: ALTER TABLE {system} CHANGE
`bootstrap` `bootstrap` INT NOT NULL DEFAULT 0; Array
(
)
 in db_change_field() (line 2957 of
/Users/abyron/Sites/deedotoh7/includes/database/database.inc).
PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column &#039;bootstrap&#039; at row 11: ALTER TABLE {system} CHANGE `bootstrap` `bootstrap` INT NOT NULL DEFAULT 0; Array
(
)
 in db_change_field() (line 2957 of /Users/abyron/Sites/deedotoh7/includes/database/database.inc).

And updatedb dies. Full log (minus 13,000 or so "Function ereg() is deprecated file.inc:1000 [notice]" errors) is attached.

damien tournoud’s picture

damien tournoud commented

I bumped into this before. This is because there are NULL values in this column. The simplest way to quickly fix is to run this query in the first place right after you import the database.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
StatusFileSize
new binlog.txt191.27 KB

That's just it though, there aren't NULL values in that column. :( Only 1 or 0. SELECT * FROM system WHERE bootstrap IS NULL returns zero rows. And if I take that query and run it against a copy of the table in straight-up MySQL, there are no problems.

HOWEVER! I noticed in the effed up database, if I do the same query, ALL rows get returned. So something in fix_d7_requirements or whatever is removing the values? chx is helping me debug, and we've turned on the binlog to log the queries being executed from drush updb. Attached.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
StatusFileSize
new drush-sup-log.txt21.8 KB

And here's a dump of the system table from d.o. That owner column is hilarious. ;)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
StatusFileSize
new deedotoh6_2011-08-04.sql_.txt119.61 KB

Oops. I meant this.

damien tournoud’s picture

damien tournoud commented

No, run this query right after import but before upgrade:

ALTER TABLE system CHANGE `bootstrap` `bootstrap` INT NOT NULL DEFAULT 0

The problem are with missing modules, and only happens after Drupal has rescaned the filesystem.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Ok, chx filed #1240222: bootstrap is NULLable to perform that query against the d.o database so that when we do this 'forreal' the query's already run and it won't fail.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.