ConfigurationOf vs. upgradeSeasideImage

Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list

Ken,

I suggest that you take a look at the GsDevKit_home upgradeStone script[1] for inspiration. That sounds like a familiar problem and I'm pretty sure that I've addressed that issue plus others in the upgradeStone script.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone#L192

On 02/07/2018 05:08 PM, Ken Treis via Glass wrote:
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list
Thanks, Dale. It turns out I was premature in declaring victory yesterday, and the "needs recompile" error is still happening even with my triumphal "fix".

Should I be using the upgradeStone script from GsDevKit rather than the upgradeSeasideImage script in the official GS 64-bit distribution? I'm not using GsDevKit / tODE on this project yet, but migration to tODE is a near-term goal.

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 7, 2018, at 6:18 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Ken,

I suggest that you take a look at the GsDevKit_home upgradeStone script[1] for inspiration. That sounds like a familiar problem and I'm pretty sure that I've addressed that issue plus others in the upgradeStone script.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone#L192

On 02/07/2018 05:08 PM, Ken Treis via Glass wrote:
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list

Yeah, I suggest that you take the topaz scripts from the upgradeStone script and add them to your own scripts ... there are also some version dependent steps that is done using tODE scripts ... what versions are involved in your upgrade ... I can decode the tODE scripts and let you know the additional steps that might be needed.

Dale


On 02/08/2018 10:30 AM, Ken Treis wrote:
Thanks, Dale. It turns out I was premature in declaring victory yesterday, and the "needs recompile" error is still happening even with my triumphal "fix".

Should I be using the upgradeStone script from GsDevKit rather than the upgradeSeasideImage script in the official GS 64-bit distribution? I'm not using GsDevKit / tODE on this project yet, but migration to tODE is a near-term goal.

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 7, 2018, at 6:18 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Ken,

I suggest that you take a look at the GsDevKit_home upgradeStone script[1] for inspiration. That sounds like a familiar problem and I'm pretty sure that I've addressed that issue plus others in the upgradeStone script.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone#L192

On 02/07/2018 05:08 PM, Ken Treis via Glass wrote:
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list
Dale,

I'm stumped.

I'm trying to upgrade from 3.2.15 (non-tODE but with some MetacelloPreview stuff loaded) to 3.3.6. I get through the regular `upgradeImage` step without any problems. But I'm still getting the same error during a GLASS bootstrap when it processes the BootstrapApplicationLoadSpecs:

--transcript--'Loading 1.0-beta.9.2.1 of ConfigurationOfGLASS...'
--transcript--'Fetched -> ConfigurationOfMetacello-dkh.795 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfMetacello-dkh.795 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsCore-dkh.301 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsCore-dkh.301 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsMisc-dkh.117 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsMisc-dkh.117 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 61294601217 exception : 69199241217
Arg 1: [69199240961 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR

In topaz, I can run `ConfigurationOf ensureMetacello` and it returns immediately. This makes sense, since it just got loaded fresh from Metacello-Base-dkh.103.mcz earlier in the bootstrap process.

But it seems that ConfigurationOfGsSqueakCommon — which it just fetched — somehow ends up referring to an obsolete version of the ConfigurationOf class. This is weird on multiple levels:

* ConfigurationOf has only one entry in its classHistory.
* Before the attempted load, ConfigurationOfGsSqueakCommon doesn't exist in DataCurator's UserGlobals. Even after the attempted load, it doesn't exist (presumably because the load attempt happens in a transaction).

So… where's it getting this obsolete code from? Is it possible that the fetches mentioned in those transcript lines — the ones that say "cached" at the end — are pulling in old classes?

====

Since I'm not running tODE yet, and since I thought maybe this error was due to something wrong in the official `upgradeSeasideImage` script, I've been writing my own scripts based on `upgradeStone` in GsDevKit_home. I may have missed something, but the steps are as follows:

1. In 3.2.15, set passwords to `swordfish` and stop the stone/LDI
2. Copy extent into 3.3.6 data dir
3. Run `upgradeImage`

The next steps are copied from upgradeStone:

4. As SystemUser, add patch for bug 46217 (GS_BOOTSTRAP_MONTICELLO_SKIP_REMOVE_CLASS)
5. Set GS_BOOTSTRAP_MONTICELLO_SKIP_REMOVE_CLASS to true
6. Remove SystemLoginNotification subscriptions and patch for Issue #71
7. Set BootstrapApplicationPostloadClassList to #( #SecureHashAlgorithm #MCFileTreeFileDirectoryUtils ). 
8. As SystemUser, set #SeasideUpgradeUser and input $GEMSTONE/upgrade/prepareSeasideImage.topaz
9. Input $GEMSTONE/upgrade/bootstrapSeasideImage.topaz

Everything goes fine until step 9, which blows up as described (regardless of whether ConfigurationOf is included in the BootstrapExistingConfigurationList).

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 9, 2018, at 8:08 AM, Dale Henrichs <[hidden email]> wrote:

Yeah, I suggest that you take the topaz scripts from the upgradeStone script and add them to your own scripts ... there are also some version dependent steps that is done using tODE scripts ... what versions are involved in your upgrade ... I can decode the tODE scripts and let you know the additional steps that might be needed.

Dale


On 02/08/2018 10:30 AM, Ken Treis wrote:
Thanks, Dale. It turns out I was premature in declaring victory yesterday, and the "needs recompile" error is still happening even with my triumphal "fix".

Should I be using the upgradeStone script from GsDevKit rather than the upgradeSeasideImage script in the official GS 64-bit distribution? I'm not using GsDevKit / tODE on this project yet, but migration to tODE is a near-term goal.

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 7, 2018, at 6:18 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Ken,

I suggest that you take a look at the GsDevKit_home upgradeStone script[1] for inspiration. That sounds like a familiar problem and I'm pretty sure that I've addressed that issue plus others in the upgradeStone script.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone#L192

On 02/07/2018 05:08 PM, Ken Treis via Glass wrote:
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list
Ken,

I just re-ran a 3.2.15 to 3.3.6 upgrade using GsDevKit_home and the upgrade ran cleanly, so your upgrade scripts must be different from the GsDevKIt_home scripts in some subtle fashion.

From topaz.out in the upgradeLog directory These are the Bootsrap* values that are being used:

Bootstrap parameters being used for upgrade:        
   BootstrapSymbolDictionary: #'UserGlobals'
   BootstrapSymbolDictionaryName: #'UserGlobals'
   BootstrapRepositoryDirectory: '/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository/'
   BootstrapApplicationPostloadClassList:
      #'SecureHashAlgorithm'
      #'MCFileTreeFileDirectoryUtils'
   BootstrapApplicationLoadSpecs:
      anArray( 'ConfigurationOfGLASS', '1.0-beta.9.2.1', anArray( 'default'), '/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository/')

And here is my transcript for the BootstrapApplicationLoadSpecs load:

--transcript--'Loading 1.0-beta.9.2.1 of ConfigurationOfGLASS...'
--transcript--'Fetched -> ConfigurationOfMetacello-dkh.795 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfMetacello-dkh.795 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsCore-dkh.301 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsCore-dkh.301 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsMisc-dkh.117 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsMisc-dkh.117 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsSqueakCommon-dkh.25 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsOB-dkh.93 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'

So far we seem to be loading the same packages ... and your error is presumably popping up while fetching ConfigurationOfGsOB-dkh.93 .... so it is odd that you've also successfully loaded all of the other configurations up to this point ...

So I think we need to characterize whats happening with ConfigurationOf a bit ... the ConfigurationOf cannot be appearing out of thin air. The 3.3.6 upgradeSeasideImage code removes classes by unconditionally removing the classes from the symbol dictionary they were found in:


topaz 1> ! patch Class>>removeFromSystem until upgrade is complete
topaz 1> category: '*change-notification'
topaz 1> method: Class
removeFromSystem
| ar |
ar := System myUserProfile dictionaryAndSymbolOf: self.
ar ifNotNil: [ (ar at: 1) removeKey: (ar at: 2) ].
%
topaz 1> commit
Successful commit
topaz 1>
topaz 1> ! Remove the known list of Metacello configuration classes (they have had their
topaz 1> !   methods removed and need to be reloaded.
topaz 1> !
topaz 1> run
ClassOrganizer clearCachedOrganizer.
BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].
true
%

... and this code is executed right before the BootstrapApplicationLoadSpecs load ... and I notice that  there is no commit in the script between the removal of the ConfigurationOf and the BootstrapApplicationLoadSpecs so an ill-timed abort would restore the old ConfigurationOf... The other possibility is that there is another ConfigurationOf class floating around in your symbol list ... so as a first order step I'd like to know the oops of the ConfigurationOf classes that are involved ...

So record the oop of the class ConfigurationOf from the 3.2.15 db, then modify the upgradeSeasideImage script to dump the oops of the ConfigurationOf classes being removed as they are removed ... Finally we can get the oop of the class that owns the un-recompiled method #ensureMetacello by inspecting the GsNMethod for #ensureMetacello and looking at it's inClass instance variable ... if we are dealing with the same oop in all cases, then we have to assume that either there is an abort involved or the ConfigurationOf class is in the symbol list multiple times ...

... and then we'll go from there.

Dale

On 02/13/2018 10:40 AM, Ken Treis wrote:
Dale,
 
I'm stumped.

I'm trying to upgrade from 3.2.15 (non-tODE but with some MetacelloPreview stuff loaded) to 3.3.6. I get through the regular `upgradeImage` step without any problems. But I'm still getting the same error during a GLASS bootstrap when it processes the BootstrapApplicationLoadSpecs:

--transcript--'Loading 1.0-beta.9.2.1 of ConfigurationOfGLASS...'
--transcript--'Fetched -> ConfigurationOfMetacello-dkh.795 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfMetacello-dkh.795 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsCore-dkh.301 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsCore-dkh.301 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsMisc-dkh.117 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsMisc-dkh.117 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 61294601217 exception : 69199241217
Arg 1: [69199240961 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR

In topaz, I can run `ConfigurationOf ensureMetacello` and it returns immediately. This makes sense, since it just got loaded fresh from Metacello-Base-dkh.103.mcz earlier in the bootstrap process.

But it seems that ConfigurationOfGsSqueakCommon — which it just fetched — somehow ends up referring to an obsolete version of the ConfigurationOf class. This is weird on multiple levels:

* ConfigurationOf has only one entry in its classHistory.
* Before the attempted load, ConfigurationOfGsSqueakCommon doesn't exist in DataCurator's UserGlobals. Even after the attempted load, it doesn't exist (presumably because the load attempt happens in a transaction).

So… where's it getting this obsolete code from? Is it possible that the fetches mentioned in those transcript lines — the ones that say "cached" at the end — are pulling in old classes?

====

Since I'm not running tODE yet, and since I thought maybe this error was due to something wrong in the official `upgradeSeasideImage` script, I've been writing my own scripts based on `upgradeStone` in GsDevKit_home. I may have missed something, but the steps are as follows:

1. In 3.2.15, set passwords to `swordfish` and stop the stone/LDI
2. Copy extent into 3.3.6 data dir
3. Run `upgradeImage`

The next steps are copied from upgradeStone:

4. As SystemUser, add patch for bug 46217 (GS_BOOTSTRAP_MONTICELLO_SKIP_REMOVE_CLASS)
5. Set GS_BOOTSTRAP_MONTICELLO_SKIP_REMOVE_CLASS to true
6. Remove SystemLoginNotification subscriptions and patch for Issue #71
7. Set BootstrapApplicationPostloadClassList to #( #SecureHashAlgorithm #MCFileTreeFileDirectoryUtils ). 
8. As SystemUser, set #SeasideUpgradeUser and input $GEMSTONE/upgrade/prepareSeasideImage.topaz
9. Input $GEMSTONE/upgrade/bootstrapSeasideImage.topaz

Everything goes fine until step 9, which blows up as described (regardless of whether ConfigurationOf is included in the BootstrapExistingConfigurationList).

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 9, 2018, at 8:08 AM, Dale Henrichs <[hidden email]> wrote:

Yeah, I suggest that you take the topaz scripts from the upgradeStone script and add them to your own scripts ... there are also some version dependent steps that is done using tODE scripts ... what versions are involved in your upgrade ... I can decode the tODE scripts and let you know the additional steps that might be needed.

Dale


On 02/08/2018 10:30 AM, Ken Treis wrote:
Thanks, Dale. It turns out I was premature in declaring victory yesterday, and the "needs recompile" error is still happening even with my triumphal "fix".

Should I be using the upgradeStone script from GsDevKit rather than the upgradeSeasideImage script in the official GS 64-bit distribution? I'm not using GsDevKit / tODE on this project yet, but migration to tODE is a near-term goal.

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 7, 2018, at 6:18 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Ken,

I suggest that you take a look at the GsDevKit_home upgradeStone script[1] for inspiration. That sounds like a familiar problem and I'm pretty sure that I've addressed that issue plus others in the upgradeStone script.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone#L192

On 02/07/2018 05:08 PM, Ken Treis via Glass wrote:
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass





_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ConfigurationOf vs. upgradeSeasideImage

GLASS mailing list
Thanks, Dale. Your tips set me on the right path and I figured it out.

I had two versions of ConfigurationOf in my system; the one in UserGlobals and another that was acting as superclass for BaselineOf and MetacelloBaseConfiguration. Once I recompiled those two subclasses and migrated, I was back to sanity and the upgrades went fine.

I still contend that ConfigurationOf itself shouldn't be included in the auto-generated BootstrapExistingConfigurationList (BECL). We gut all classes from UserGlobals, bootstrap (which loads ConfigurationOf), and then remove everything named in BECL… which (in my case) ends up removing the ConfigurationOf that we just loaded. If somebody didn't have ConfigurationOf pre-upgrade, it wouldn't be an issue.

Also, one thing that threw me a little is that the report of Bootstrap* values in my configuration said:

  BootstrapSymbolDictionary: #'BootstrapSymbolDictionary'
  BootstrapSymbolDictionaryName: #'BootstrapSymbolDictionary'

I did confirm that BootstrapSymbolDictionary == UserGlobals; it just apparently had some amnesia or a split personality or something.

Anyhow, thanks again. I think I'm finally out of the woods on this.

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 14, 2018, at 4:43 AM, Dale Henrichs <[hidden email]> wrote:

Ken,

I just re-ran a 3.2.15 to 3.3.6 upgrade using GsDevKit_home and the upgrade ran cleanly, so your upgrade scripts must be different from the GsDevKIt_home scripts in some subtle fashion.

From topaz.out in the upgradeLog directory These are the Bootsrap* values that are being used:

Bootstrap parameters being used for upgrade:        
   BootstrapSymbolDictionary: #'UserGlobals'
   BootstrapSymbolDictionaryName: #'UserGlobals'
   BootstrapRepositoryDirectory: '/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository/'
   BootstrapApplicationPostloadClassList:
      #'SecureHashAlgorithm'
      #'MCFileTreeFileDirectoryUtils'
   BootstrapApplicationLoadSpecs:
      anArray( 'ConfigurationOfGLASS', '1.0-beta.9.2.1', anArray( 'default'), '/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository/')

And here is my transcript for the BootstrapApplicationLoadSpecs load:

--transcript--'Loading 1.0-beta.9.2.1 of ConfigurationOfGLASS...'
--transcript--'Fetched -> ConfigurationOfMetacello-dkh.795 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfMetacello-dkh.795 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsCore-dkh.301 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsCore-dkh.301 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsMisc-dkh.117 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsMisc-dkh.117 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsSqueakCommon-dkh.25 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsOB-dkh.93 --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository --- rogue:/home/dhenrich/rogue/_homes/rogue/_home/server/stones/gs_3215_336/product/seaside/monticello/repository'

So far we seem to be loading the same packages ... and your error is presumably popping up while fetching ConfigurationOfGsOB-dkh.93 .... so it is odd that you've also successfully loaded all of the other configurations up to this point ...

So I think we need to characterize whats happening with ConfigurationOf a bit ... the ConfigurationOf cannot be appearing out of thin air. The 3.3.6 upgradeSeasideImage code removes classes by unconditionally removing the classes from the symbol dictionary they were found in:


topaz 1> ! patch Class>>removeFromSystem until upgrade is complete
topaz 1> category: '*change-notification'
topaz 1> method: Class
removeFromSystem
| ar |
ar := System myUserProfile dictionaryAndSymbolOf: self.
ar ifNotNil: [ (ar at: 1) removeKey: (ar at: 2) ].
%
topaz 1> commit
Successful commit
topaz 1>
topaz 1> ! Remove the known list of Metacello configuration classes (they have had their
topaz 1> !   methods removed and need to be reloaded.
topaz 1> !
topaz 1> run
ClassOrganizer clearCachedOrganizer.
BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].
true
%

... and this code is executed right before the BootstrapApplicationLoadSpecs load ... and I notice that  there is no commit in the script between the removal of the ConfigurationOf and the BootstrapApplicationLoadSpecs so an ill-timed abort would restore the old ConfigurationOf... The other possibility is that there is another ConfigurationOf class floating around in your symbol list ... so as a first order step I'd like to know the oops of the ConfigurationOf classes that are involved ...

So record the oop of the class ConfigurationOf from the 3.2.15 db, then modify the upgradeSeasideImage script to dump the oops of the ConfigurationOf classes being removed as they are removed ... Finally we can get the oop of the class that owns the un-recompiled method #ensureMetacello by inspecting the GsNMethod for #ensureMetacello and looking at it's inClass instance variable ... if we are dealing with the same oop in all cases, then we have to assume that either there is an abort involved or the ConfigurationOf class is in the symbol list multiple times ...

... and then we'll go from there.

Dale

On 02/13/2018 10:40 AM, Ken Treis wrote:
Dale,
 
I'm stumped.

I'm trying to upgrade from 3.2.15 (non-tODE but with some MetacelloPreview stuff loaded) to 3.3.6. I get through the regular `upgradeImage` step without any problems. But I'm still getting the same error during a GLASS bootstrap when it processes the BootstrapApplicationLoadSpecs:

--transcript--'Loading 1.0-beta.9.2.1 of ConfigurationOfGLASS...'
--transcript--'Fetched -> ConfigurationOfMetacello-dkh.795 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfMetacello-dkh.795 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsCore-dkh.301 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsCore-dkh.301 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsMisc-dkh.117 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsMisc-dkh.117 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
--transcript--'Fetched -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- upgrade:/opt/gemstone/product/seaside/monticello/repository'
--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 61294601217 exception : 69199241217
Arg 1: [69199240961 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR

In topaz, I can run `ConfigurationOf ensureMetacello` and it returns immediately. This makes sense, since it just got loaded fresh from Metacello-Base-dkh.103.mcz earlier in the bootstrap process.

But it seems that ConfigurationOfGsSqueakCommon — which it just fetched — somehow ends up referring to an obsolete version of the ConfigurationOf class. This is weird on multiple levels:

* ConfigurationOf has only one entry in its classHistory.
* Before the attempted load, ConfigurationOfGsSqueakCommon doesn't exist in DataCurator's UserGlobals. Even after the attempted load, it doesn't exist (presumably because the load attempt happens in a transaction).

So… where's it getting this obsolete code from? Is it possible that the fetches mentioned in those transcript lines — the ones that say "cached" at the end — are pulling in old classes?

====

Since I'm not running tODE yet, and since I thought maybe this error was due to something wrong in the official `upgradeSeasideImage` script, I've been writing my own scripts based on `upgradeStone` in GsDevKit_home. I may have missed something, but the steps are as follows:

1. In 3.2.15, set passwords to `swordfish` and stop the stone/LDI
2. Copy extent into 3.3.6 data dir
3. Run `upgradeImage`

The next steps are copied from upgradeStone:

4. As SystemUser, add patch for bug 46217 (GS_BOOTSTRAP_MONTICELLO_SKIP_REMOVE_CLASS)
5. Set GS_BOOTSTRAP_MONTICELLO_SKIP_REMOVE_CLASS to true
6. Remove SystemLoginNotification subscriptions and patch for Issue #71
7. Set BootstrapApplicationPostloadClassList to #( #SecureHashAlgorithm #MCFileTreeFileDirectoryUtils ). 
8. As SystemUser, set #SeasideUpgradeUser and input $GEMSTONE/upgrade/prepareSeasideImage.topaz
9. Input $GEMSTONE/upgrade/bootstrapSeasideImage.topaz

Everything goes fine until step 9, which blows up as described (regardless of whether ConfigurationOf is included in the BootstrapExistingConfigurationList).

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 9, 2018, at 8:08 AM, Dale Henrichs <[hidden email]> wrote:

Yeah, I suggest that you take the topaz scripts from the upgradeStone script and add them to your own scripts ... there are also some version dependent steps that is done using tODE scripts ... what versions are involved in your upgrade ... I can decode the tODE scripts and let you know the additional steps that might be needed.

Dale


On 02/08/2018 10:30 AM, Ken Treis wrote:
Thanks, Dale. It turns out I was premature in declaring victory yesterday, and the "needs recompile" error is still happening even with my triumphal "fix".

Should I be using the upgradeStone script from GsDevKit rather than the upgradeSeasideImage script in the official GS 64-bit distribution? I'm not using GsDevKit / tODE on this project yet, but migration to tODE is a near-term goal.

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221


On Feb 7, 2018, at 6:18 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Ken,

I suggest that you take a look at the GsDevKit_home upgradeStone script[1] for inspiration. That sounds like a familiar problem and I'm pretty sure that I've addressed that issue plus others in the upgradeStone script.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone#L192

On 02/07/2018 05:08 PM, Ken Treis via Glass wrote:
I'm working on upgrading a system from 3.2.15 to 3.3.5 and hit a snag. I'm not sure if this is a bug in upgradeSeasideImage or just an odd quirk of our setup.

When upgradeSeasideImage tries to auto-detect ConfigurationOfX classes to remove, it is apparently deciding to include the base `ConfigurationOf` class from Metacello in its list of removals. The script ends up loading it fresh, removing it, and then bombing when one of the packages triggers  `ConfigurationOf class>>ensureMetacello`.

I worked around this by building my #BootstrapExistingConfigurationList that omitted ConfigurationOf, and then the upgradeSeasideImage script completed without errors.

Here are some highlights from the upgradeTo3x.log leading up to the failure:

Automatically generating list of loaded configuration classes to be removed:
  ConfigurationOfGLASS
  ConfigurationOfFileTree
  ConfigurationOfGofer
  ConfigurationOfGsSqueakCommon
  ConfigurationOfGrease
  ConfigurationOfGsMisc
  ConfigurationOfGsOB
  ConfigurationOfGoferProjectLoader
  ConfigurationOfGsMonticello
  ConfigurationOfGsCore
  ConfigurationOf
  ConfigurationOfZincHTTPComponents
  ConfigurationOfSeaside3
  ConfigurationOfMetacello

[snipped]

loading 'Metacello-Base-dkh.103.mcz'
class created: 'ConfigurationOf'

[snipped]

BootstrapExistingConfigurationList do: [:class | class removeFromSystem ].

[…]

--transcript--'Loaded -> ConfigurationOfGsSqueakCommon-dkh.25 --- upgrade.weco-write.com:/opt/gemstone/product/seaside/monticello/repository --- cache'
-----------------------------------------------------
GemStone: Error         Nonfatal
a ImproperOperation occurred (error 2142), Cannot execute method, 'method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889'
Error Category: 231169 [GemStone] Number: 2142  Arg Count: 2 Context : 69194451969 exception : 72186891777
Arg 1: [72186892033 sz:82 cls: 74753 String] method needs recompile, ConfigurationOf class >> ensureMetacello , oop 36494597889
Arg 2: [20 sz:0 cls: 76289 UndefinedObject] nil
ERROR: UNEXPECTED ERROR
topaz> time
 02/07/2018 10:47:24.935 PST
topaz > exec iferr 1 : stk 
==> 1 ImproperOperation (AbstractException) >> _signalFromPrimitive: @7 line 15   [methId 56587946753]
2 ConfigurationOfGsSqueakCommon >> project      @1 line 1   [methId 72117275905]

Again, this might be just a quirk of my setup… but it seems (in my limited understanding) that the upgrade wouldn't need to remove ConfigurationOf after having just loaded it.

In case anybody else needs the workaround, I just copied the auto-generation code from the log, hacked it as follows, and used it to set #BootstrapExistingConfigurationList explicitly before running `upgradeSeasideImage`:

"Patched code from upgradeSeasideImage (to avoid removing base ConfigurationOf class)"
GsFile gciLogServer: 'Automatically generating list of loaded configuration classes'.
UserGlobals at: #BootstrapExistingConfigurationList put: OrderedCollection new.
UserGlobals associationsDo: [:assoc |
  assoc value isBehavior
    ifTrue: [
      ((assoc key asString _findString: 'ConfigurationOf' startingAt: 1 ignoreCase: false) == 1 and: [assoc key ~= #ConfigurationOf])
        ifTrue: [
          GsFile gciLogServer: '  ', assoc key asString.
          (UserGlobals at: #BootstrapExistingConfigurationList) add: assoc value ]
    ].
].

--
Ken Treis
Miriam Technologies, Inc.
(866) 652-2040 x221




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass






_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass