492511 - DNS lookups/name resolutions fail on Linux x86_64 (Ubuntu 9.04); can browse by IP address; system DNS works

Status: RESOLVED DUPLICATE of bug 414197

(Firefox :: General, defect)

Description

[Edgar D'Souza]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

Downloaded and untarred FF3.5b4, and ran `./firefox -P` in the untarred directory. Created a new profile to avoid conflict with FF3.0.10 which is working fine. When FF3.5b4 comes up, it instantaneously displays the "Server not found" page - "Firefox can't find the server at en-us.start3.mozilla.com." ... ... etc.


DNS lookups are otherwise working fine on the system - I can browse normally with FF3.0.10 (installed via system packaging); running `host` in a terminal works fine: 
edgar@edgar-laptop:~/ff3.5b4/firefox$ host en-us.start3.mozilla.com
en-us.start3.mozilla.com is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.153.104
I'm actually running bind9 locally, and /etc/resolv.conf points to 127.0.0.1 as nameserver; this works fine, as mentioned above.

I do not have any proxy server between the machine on which I'm running 3.5b4, and the Net. I have tried changing Connection Settings from 'Use system proxy settings' to 'No proxy' and back, but there is no difference.

If I take the IP address from lookups (like done above) and paste into the FF3.5b4 address bar, it fetches the page with no problem (and with blazing speed - wow!). Of course, clicking any link(s) in the page fails, because name resolution is not happening. I also tried browsing my ADSL modem's admin UI pages (links are relative, without any FQDN) and it works absolutely beautifully, and at amazing speed. 

Thus, I'm concluding that only the DNS lookup part is not working for me.


Reproducible: Always

Steps to Reproduce:
1. Download and untar FF3.5b4 on Ubuntu 9.04 x86_64 install
2. Run `./firefox -P` in the untarred directory.
3. Create a new profile to keep beta separate from main FF installation.
4. Choose this profile and click OK. The main window will try to load the default/home/start page.
5. Enter any other URL (e.g. www.google.com) into the address bar and try to load it.
Actual Results:  
When FF3.5b4 comes up, it instantaneously displays the "Server not found" page - "Firefox can't find the server at en-us.start3.mozilla.com." ... ... etc. The same occurs for any other URL I type in.

Expected Results:  
Should have performed name resolution of the default/home/start page URL, and loaded the page.


When starting FF3.5b4, I see the following warning/error message output. I don't know if it is relevant (doesn't look like), but pasting anyway:

edgar@edgar-laptop:~/ff3.5b4/firefox$ ./firefox -P
Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64
/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
/usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64
/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
/usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
LoadPlugin: failed to initialize shared library /usr/lib/totem/gstreamer/libtotem-cone-plugin.so [/usr/lib/totem/gstreamer/libtotem-cone-plugin.so: wrong ELF class: ELFCLASS64]
LoadPlugin: failed to initialize shared library /usr/lib/totem/gstreamer/libtotem-gmp-plugin.so [/usr/lib/totem/gstreamer/libtotem-gmp-plugin.so: wrong ELF class: ELFCLASS64]
LoadPlugin: failed to initialize shared library /usr/lib/totem/gstreamer/libtotem-mully-plugin.so [/usr/lib/totem/gstreamer/libtotem-mully-plugin.so: wrong ELF class: ELFCLASS64]
LoadPlugin: failed to initialize shared library /usr/lib/totem/gstreamer/libtotem-narrowspace-plugin.so [/usr/lib/totem/gstreamer/libtotem-narrowspace-plugin.so: wrong ELF class: ELFCLASS64]

There are no error lines written to the console when the DNS lookups fail.

This lookup failure occurs on a freshly untarred copy of FF3.5b4; no themes, add-ons etc installed except whatever's already in the tarball.

Comment 1

[Kevin Brosnan]

This is likely an issue with you running a 32-bit version of Firefox in an x64 distro. Google '32-bit chroot' for help with running 32 bit apps in a x64 environment.

Using a 32-bit distro this works for me Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.1b5pre) Gecko/20090511 Shiretoko/3.5b5pre

Comment 2

[Sylvain Pasche]

could you try setting network.dns.disableIPv6 to true
and see if it helps. That may be bug 414197.

Comment 3

[Edgar D'Souza]

(In reply to comment #2)
> could you try setting network.dns.disableIPv6 to true
> and see if it helps. That may be bug 414197.

Fantastic! thank you very much for the tip-off.

I changed network.dns.disableIPv6 to true, and DNS lookups worked.

I then visited the bug you referred (414197) and found your comment "without the lib32nss-mdns package, the libc can't load the mdns4_minimal module and aborts the resolution."
I therefore installed the lib32nss-mdns package on my x86_64 Ubuntu 9.04, and changed network.dns.disableIPv6 back to false, and tried lookups - it continues to work. Therefore, installing the missing package solves my problem too.

Thanks very much for your help. I have marked this bug as a duplicate of 414197.

Comment 4

[sooners123]

Sweet!  I upgraded to 3.5 a couple of weeks ago and had the same problem.  Same situation too (9.04, x86_64, works by ip address).  Installing the package 'lib32nss-mdns' fixed it for me too.