Closed Bug 661455 Opened 13 years ago Closed 13 years ago

help->update does not maintain Hardware platform, grabbing 32bit version for 64 bit version

Categories

(AUS Graveyard :: API, defect)

Product:
AUS Graveyard
Component:
API
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mfoxdogg, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0a2) Gecko/20110601 Firefox/6.0a2
Build Identifier: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0a2) Gecko/20110601 Firefox/6.0a2

I am running a 64bit version of aurora and when i run the updater it downloads and applys a 32 bit version

Reproducible: Always

Steps to Reproduce:
1. Download 64bit version of firefox
2. go to help->about firefox/aurora
3. apply update

Actual Results:  
version running now is actually 32bit version

Expected Results:  
to be still running a 32 bit version
(In reply to comment #0)
> Expected Results:  
> to be still running a 32 bit version

sorry meant to be, to be still running a 64 bit version
The info is provided by the client to the update server so this is likely a problem with the update provided by the server. Moving to the associated product and component
Component: Installer → API
Product: Firefox → AUS
QA Contact: installer → api
Version: unspecified → 2.0
The useragent in comment #0 implies the build is 32bit, but running on 64bit. What does about:buildconfig have to say about the Build platform's target ?
Let's verify that the client code is using the correct url.

With a 64 bit installation perform the following.

Type about:config in the url bar and click the button to display the content. Type app.update.log and double click it so its value is true. Restart Firefox and open Tools -> Web Developer -> Error Console. Click the Clear button. Open the About window. Please copy / pastes the entry that starts with "AUS:SVC Checker:getUpdateURL - update URL:" into into this bug report. Thanks
Interesting. Please do the check in comment #3 too
Modifying the buildID in comment #6 gets me a complete mar at 
 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/06/2011-06-01-04-mozilla-aurora-l10n/firefox-6.0a2.en-GB.linux-x86_64.complete.mar
which has
libxul.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

So what makes you say you have a 32bit version after an update ?
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0a2) Gecko/20110601 Firefox/6.0a2

target: x86_64-unknown-linux-gnu

also, since filing this bug i have redownloaded the 64bit version, didn't think it would have been gotten onto this so fast.

also i updated to 64bit yesterday when i realised i was running 32bit, so there may have been an update pending.

I know i am using 32bit instead of 64 is that it uses wrong gtk version, wrong flash version, generally wrong sys libs being used
Did you extract or copy / move on top of an existing install?
on top of existing install
That might have been the cause if there was an update downloading or already downloaded. That isn't a supported method for installing with tar's or zips though I haven't checked that it is documented in the release notes for several years. Just in case, please delete the installation directory and re-extract the tar into the same location.
OK, thank you all for your help, it says its up to date now for some reason. i will keep an eye on this, incase it flares up again
Michael, I'm closing this out as invalid since the most likely cause is installing on top of an existing install. If this happens again feel free to reopen or file a new bug. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.