Open Bug 1556748 Opened 3 months ago Updated 5 days ago

Implement balrog rule to update 32-bit Windows Thunderbird users running 64-bit OS

Categories

(Thunderbird :: Build Config, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: rjl, Assigned: rjl)

References

(Blocks 1 open bug)

Details

Attachments

(5 files, 1 obsolete file)

Attached file win32Towin64_balrog.py (obsolete) —

The way this worked for Firefox, there's two Balrog rules:

  • Rule 685 acted as a watershed for all Windows users to install FF 56.0
  • Rule 681 then migrated only users running 56.0 and met the other criteria

Criteria for migrating to 64-bit:

  • Did not opt out with the registry setting created by the installation of 56.0
  • Running 32-bit app on 64-bit Windows
  • Have more than 2G of RAM

It looks like we need a watershed for Windows users on the next beta so the updater can set that registry key. We'll have to do the same for the release branch as well.

I've modified the script that releng used for Firefox to mangle the Balrog blob for a given release. It removes the non-windows data and sets the mapping for win32 on x64 users to get the 64 bit version.

For reference, this is the watershed rule that forced all users to install FF-56.0.

For reference, this is the rule that did the actual migration for eligible users.

Attached file TB_win32Towin64.md

Some notes on how to set up Balrog

The URLs that get generated by the Thunderbird updater should look something like (from a recent nightly):

https://aus5.mozilla.org/update/6/Thunderbird/69.0a1/20190526233640/WINNT_x86-msvc-x64/%LOCALE%/%CHANNEL%/Windows_NT 6.1.1.0.7601 (x64)/ISET:SSE4_2,MEM:32101/default/default/update.xml?mig64=1

The important pieces from a Balrog perspective:

  • build target: WINNT_x86-msvc-x64 that indicates an x86 build running on x64 OS
  • RAM: MEM:32101 (in MB, must be > 2048 to trigger the upgrade)
  • opt-in: mig64=1

I've got this working on the "nightlytest" update channel. You have to start off with a build < 20190604091847. You will get two updates, the first will go to Build 20190604091847 which will set the magic registry value, then on the next update if you meet the criteria you should go to Build 20190605101101 for win64.

I can put this on the regular nightly channel if desired.

Do we need to set the magic registry value also on the next, or one of the next, TB 60 updates to make it possible to update from 32bit TB 60 to 64bit TB68?

(In reply to Richard Marti (:Paenglab) from comment #5)

Do we need to set the magic registry value also on the next, or one of the next, TB 60 updates to make it possible to update from 32bit TB 60 to 64bit TB68?

Is there a process in place to go from 32 bit TB60 to 64 bit TB60? THAT would be the most logical first step; to only change one thing at a time. Otherwise, if something breaks, there are too many variables.

We could flip the registry bit for esr60 on the next release to get the process going. It doesn't do anything except send another parameter to the update server. Balrog will ignore it and continue sending win32 downloads unless we tell it otherwise.

Attached file win32Towin64_balrog.py

Updated script, works with a little less interaction from user now.

Attachment #9069658 - Attachment is obsolete: true

Just updated to 60.8.0 (32-bit). Still 32 bit.

(In reply to Worcester12345 from comment #9)

Just updated to 60.8.0 (32-bit). Still 32 bit.

Patience grasshopper. This bug is not fixed, so of course this is expected. Migration won't happen until the balrog piece described by this bug is done.

I think I read comment 4 and comment 5 together very quickly, and somehow thought this was done. Thanks for working on it.

This test document assumes a watershed for Windows users at 60.8 and that the win64 migration happens on 68.2.
I just verified that the script to create the special migration release in Balrog still works.

Attachment #9091141 - Flags: feedback?(vseerror)
Comment on attachment 9091141 [details]
Win32 to Win64 Automigrate Testing.html

I think win64 for 68.2 is reasonable, so SGTM.  I'd just double check with Magnus, so adding NI.

We still have Bug 1509918 - "use thunderbird as default client" prompt on every startup on WIndows 7 using TB 64bit.  However the issue also appears with 32bit Thunderbird so I don't think it blocks this bug - but we should still commit to fixing it.
Attachment #9091141 - Flags: feedback?(vseerror)
Attachment #9091141 - Flags: feedback?(mkmelin+mozilla)
Attachment #9091141 - Flags: feedback+
Comment on attachment 9091141 [details]
Win32 to Win64 Automigrate Testing.html

Looks good. 
While testing that migration works, can we also at the same time add an item to check that it found the existing profile after migration?
Attachment #9091141 - Flags: feedback?(mkmelin+mozilla) → feedback+

This title looks whacky.
"Implement balrog rule to update 32-bit Windows Thunderbird users running 64-bit OS"

Is this what it really wants to say?
"Implement balrog rule to update 64-bit Windows OS users who are running 32-bit Thunderbird"

You need to log in before you can comment on or make changes to this bug.