Debian amd64: iceweasel with i386 plugins, outside a chroot

Posted by CarloWood on Mon 10 Mar 2008 at 06:22

If you weren't already convinced that closed source sucked before, then surely the experience of trying to browse the net with an amd64 machine will have won you over; I could ponder on how much Microsoft is paying Adobe not to release a 64-bit version of their flash plugin— but why Sun is categorically refusing to address our cry for a 64-bit java plugin for mozilla based browsers for this many years is beyond me.

There are three approaches to work around this conspiracy:

  1. Install everything in a 32-bit chroot and run the browser there.
  2. Use the 64-bit version of the browser and use a wrapper for the 32-bit plugins.
  3. Use a 32-bit version of the browser without chroot (a bi-arch approach).

I used option 1 (the chroot) for a while, but that approach has several annoying disadvantages:

  • Every external application started by iceweasel necessarily also runs inside the 32-bit chroot. It is neat that you can assign programs to handle files with certain extensions, but in most cases you want to run those applications in your normal 64-bit environment of course (ie xmms, azureus, mplayer).
  • If you download a file, you can only download it to the 32-bit chroot. Of course you can bind mount several directories like your home directory - but not every directory can be shared like that, and all too often I found myself downloading to my home directory just to make the file accessible, having to manually copy it in to it's final destination from a 64-bit shell.

I tried option 2, but it was a horror. Maybe some day that option will mature, but right now it's just not working for me.

That leaves option 3. However, the main disadvantage of that option is that you simply can't install i386 debian packages on an amd64 system. Therefore you have to fall-back to tar-balls and install everything manually. I tried this too, with as result that anti-aliasing didn't work anymore and java simply froze iceweasel.

The Best Of Both Worlds

The approach that I chose in the end is as follows: I installed everything that has to be of i386 architecture in a 32-bit chroot (as in option 1), using apt-get (or aptitude or whatever you like) and used a small wrapper and environment variables to run the browser in the 64-bit environment with a linux32 personality (as in option 3).

This turns out to a simple and painless procedure.

First, create an i386 chroot inside of which we will later install iceweasel. This chroot will be much smaller than that of option 1 above, because we won't need to install libraries that are already available from ia32 packages for the amd64 architecture.

You'll need some packages:

sudo apt-get install debootstrap

Creating the chroot

Choose the root of the chroot and it's handle:

CHROOT="/opt/firefox-chroot";   # The directory of the chroot.
CHROOTNAME="firefox";           # The name as listed by schroot -l.

We need these too. You can set them to whatever works for you but the following should set them automatically (as usually, in my HOWTO's, just copy&paste the whole block to your (non-root) shell prompt):

HELPVAR=$(apt-cache policy coreutils | egrep '^[[:space:][:digit:]]*http:' | \
    sed -r 's/^[[:space:]]*//;s/[[:space:]]+/,/g' | sort -rn | head -n 1)
SUITE=$(echo "$HELPVAR" | cut -d, -f 3 | sed -e 's%/.*%%')
DEBIANMIRROR=$(grep "^deb $(echo "$HELPVAR" | cut -d, -f 2).*$SUITE" /etc/apt/sources.list | \
    sed -r 's/^[[:space:]]*//;s/[[:space:]]+/,/g;s%/,%,%g;s%,%/,%g' | cut -d, -f 2)

This should set $SUITE to something like 'lenny' and $DEBIANMIRROR to something like ''.

If SUITE is 'unstable', 'testing' or 'stable' then debootstrap won't work without providing the current codename. Therefore, try to extract that:

if test ! -e /usr/share/debootstrap/scripts/$SUITE; then
  CODENAME=$(sed -ne 's/^Codename: \([a-z]*\)$/\1/p' /var/lib/apt/lists/$(echo "$DEBIANMIRROR" | sed -e "s%http://*%%;s%/%_%g")dists_"$SUITE"_Release)

Create the new directory and install the base system into it:

sudo mkdir "$CHROOT"
sudo debootstrap --arch i386 $SUITE "$CHROOT" $DEBIANMIRROR /usr/share/debootstrap/scripts/$CODENAME

This installs about 180 MB in $CHROOT.

Since we won't run iceweasel inside the chroot, there is no need to do (bind) mounts, or install home directories or whatever— but we still need a few more packages to be installed.

Enter the chroot as root:

sudo chroot "$CHROOT"

Before running apt-get, you might want to fix a few things:

In order to get rid of the message "WARNING: The following packages cannot be authenticated!", run the following command:

apt-get update

This will retrieve the missing Release.gpg.

If you want to get rid of the warnings:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

then run the following commands (this installs an additional 18 MB):

LANG= apt-get install locales
eval `locale 2> /dev/null`
sed -ri 's/^([^#].*)/# \1/;s/^# ('$LC_CTYPE'($| .*))/\1/' /etc/locale.gen

[ If you don't want that, then you can temporarily suppress these messages by doing instead:

eval `LANG= locale`

but you'd need to do that every time you enter the chroot for maintenance. ]

Next, edit /etc/apt/sources.list and add a line for security updates (as usual, just copy&paste the whole block to the shell prompt (outside the chroot)):

exit # Leave the chroot
if ! grep 'security\.debian\.org' $CHROOT/etc/apt/sources.list; then
  sudo sh -c 'echo "# Security updates." >> '"$CHROOT"'/etc/apt/sources.list; \
  echo "deb '"$SUITE"'/updates main contrib" >> '"$CHROOT"'/etc/apt/sources.list'

Also add contrib and non-free, as we'll need that for the plugins later on:

sudo sed -ri 's/^(deb '$(echo $DEBIANMIRROR | sed 's/\/$//;s/\([$/.]\)/\\\1/g')' '$SUITE' main)$/\1 contrib non-free/' $CHROOT/etc/apt/sources.list

and update the chroot

sudo chroot $CHROOT apt-get update
sudo chroot $CHROOT apt-get dist-upgrade

A More General chroot

If you are just creating the chroot for running iceweasel, then you can skip this paragraph. However, I can imagine that some people are using this page to set up a more general chroot, for other purposes; therefore I decided to add this paragraph that describes how to finish the chroot so it can be used in general, just to have all information in one place.

First you'll want to bind mount a few directories. Add the (output of) the following to your /etc/fstab (the real one, not the one in the chroot!).

exit # Leave the chroot
cat << EOF
# $CHROOTNAME chroot
/proc    $CHROOT/proc    none    bind     0 0
/dev     $CHROOT/dev     none    bind     0 0
/tmp     $CHROOT/tmp     none    bind     0 0
/home    $CHROOT/home    none    bind     0 0

and possibly other directories. Try to avoid any directories that debian installs files in however, or the chroot will overwrite your system files (and vica versa) of course.

WARNING: If you 'rm -rf' the $CHROOT directory then everything (still) bind mounted will be deleted as well! A 'bind mount' is not normally visible with 'df', you will need to do 'df -a' to see it (I lost my home directory this way, while doing tests in order to write this howto)!

After adding those lines, they are still not mounted until you reboot; so mount them manually this time:

sudo mount $CHROOT/proc
sudo mount $CHROOT/dev
sudo mount $CHROOT/tmp
sudo mount $CHROOT/home

Note that you can also bind mount from the command line without adding the extra configuration lines to /etc/fstab. You'll need --rbind for /dev, because otherwise /dev/pts isn't included. For example,

sudo mount --bind /proc $CHROOT/proc
sudo mount --rbind /dev $CHROOT/dev
sudo mount --bind /tmp $CHROOT/tmp

You'll want to use schroot to switch to the chroot as a normal user:

sudo apt-get install schroot

Finally, fix your /etc/schroot/schroot.conf and possibly setup a little wrapper and symlinks as is described in Running applications inside a chroot using schroot.

Okay, back to installing iceweasel.

Installing Iceweasel

Enter the chroot and install iceweasel (this drags in another 130 MB) and fix /usr/lib/iceweasel/iceweasel not to be anal about where it's installed:

sudo chroot $CHROOT
apt-get --yes install libgconf2-4
apt-get --yes install iceweasel
sed -i 's/^MOZ_DIST_BIN=.*/MOZ_DIST_BIN="$(dirname $0)"/' /usr/lib/iceweasel/iceweasel

Setting Up A Wrapper

Leave the chroot and install some needed libraries:

exit              # Leave the chroot
sudo apt-get install ia32-libs-gtk

Installing iceweasel already dragged in so many libraries into the chroot, that ia32-libs-gtk is only really need for /usr/lib/gtk-2.0/2.10.0/engines/ I can imagine that it's possible to remove (a lot of) libraries from the chroot because they are already installed as some ia32 package in your amd64 environment, but at this moment I'm too lazy to look into that (for the few cents worth of diskspace).

Next, create the wrapper to start iceweasel; for example, create a file /usr/local/bin/firefox as follows:

sudo sh -c 'cat > /usr/local/bin/firefox << EOF
export GTK_PATH="/usr/lib32/gtk-2.0"
export LD_LIBRARY_PATH="/lib32:/usr/lib32:\$CHROOT/lib:\$CHROOT/usr/lib"
linux32 "\$CHROOT/usr/lib/iceweasel/iceweasel" "\$@"
sudo chmod +x /usr/local/bin/firefox

This should create a file with content like the following:

export GTK_PATH="/usr/lib32/gtk-2.0"
export LD_LIBRARY_PATH="/lib32:/usr/lib32:$CHROOT/lib:$CHROOT/usr/lib"
linux32 "$CHROOT/usr/lib/iceweasel/iceweasel" "$@"

At this point everything should work except plugins: It's using your normal home directory, and thus ~/.mozilla and thus your bookmarks, preferences, cookies, passwords etc. Also anti-aliasing should work fine already at this point, as well as "File Type / Download Actions" (Preferences -> Content -> File Types, Manage...), which will run your external applications as 64-bit applications now.

Note that the wrapper sets LD_LIBRARY_PATH to both, [/usr]/lib32 as well as $CHROOT[/usr]/lib, both containing 32-bit libraries. The latter are needed because not all needed 32-bit libraries are provided by ia32-libs and ia32-libs-gtk. But why prepend the path with the lib32 ones? Surely every needed 32-bit library could be installed in the chroot? The reason for this is that some of the libraries contain hardcoded paths, or should I say, one library contains a hardcoded path... $CHROOT/usr/lib/ contains the hardcoded path /usr/lib/gtk-2.0/2.10.0/loaders. This causes it to read the files in /usr/lib/gtk-2.0/2.10.0/loader-files.d, which contain libraries paths in /usr/lib, 64-bit libraries. Therefore it is needed to load libraries from /usr/lib32 before $CHROOT/usr/lib.

Installing Plugins

Installing plugins, which are loaded when the browser is already running, should be easy. The only remaining problem might be hard-coded paths for externally run programs (like java_vm). Flash should not give any problems, so lets start with that.

Installing The Flash Plugin


Flash applications often use Microsoft core fonts, and simply don't display any text if you don't have them (which can be very confusing). Therefore, you better install them as well (in the amd64 root):

sudo apt-get install msttcorefonts

After you installed the plugin, you can test if that worked here. Besides TEXT1, TEXT2 and TEXT3, you should see a TEXT4.

The whole point of the chroot is to make it easy to install and update the plugins. So, just enter the chroot and install the plugin the debian way:

sudo chroot $CHROOT apt-get install flashplugin-nonfree

Unfortunately the debian "maintainers" decided to remove this plugin from debian as of lenny. The plugin is now only available if you're using etch or when you're using unstable. See for their reasons.

If the above didn't work then you'll have to use the package from unstable (codename: sid). Once lenny has become stable, and you are using stable you should use the backport (see below).

If you're using testing— then you might want to create the backport yourself, because is for 'stable', following the instructions below (adapted from 6.4.10 Port a package to the stable system from the debian reference manual). However, you might want to try to just use the 'stable' backport (hoping your libs are compatible; what they usually should be because 'testing' is newer than 'stable').

In order to compile the backport yourself do the following:

exit # Leave chroot
if ! grep '^deb-src.*unstable' $CHROOT/etc/apt/sources.list; then
  sudo sh -c 'echo "# Sources from unstable." >> '"$CHROOT"'/etc/apt/sources.list; \
  echo "deb-src '"$DEBIANMIRROR"' unstable main contrib non-free" >> '"$CHROOT"'/etc/apt/sources.list'
sudo chroot $CHROOT
apt-get update
apt-get --yes install build-essential fakeroot devscripts debhelper;  # Installs 65 MB.
cd /usr/src
mkdir flashplugin-nonfree
cd flashplugin-nonfree
apt-get source flashplugin-nonfree
cd flashplugin-nonfree-*
apt-get --yes build-dep flashplugin-nonfree
dpkg-buildpackage -rfakeroot -us -uc
dpkg -i ../flashplugin-nonfree_*_i386.deb
apt-get purge build-essential fakeroot devscripts debhelper
apt-get autoremove;                                             # Free 65 MB again.
cd /usr/src
rm -rf flashplugin-nonfree

A disadvantage of this method is that it won't upgrade flash when a new release is available.

In order to use do the following (adapted from here). I'd urge you to use pinning so that upgrading later on will be automatic.

exit # Leave chroot
STABLECODENAME=etch;  # Change this if needed!
if ! grep '^deb http://www\.backports\.org' $CHROOT/etc/apt/sources.list; then
  sudo sh -c 'echo "# Stable backports." >> '"$CHROOT"'/etc/apt/sources.list; \
  echo "deb '"$STABLECODENAME"'-backports main contrib non-free" >> '"$CHROOT"'/etc/apt/sources.list'
sudo chroot $CHROOT
apt-get update
wget -O - | apt-key add -
sudo chroot $CHROOT apt-get --yes --force-yes -t '"$STABLECODENAME"'-backports install flashplugin-nonfree

Since the support from debian is basically gone, you might also opt for the alternative to download the flashplayer from Adobe yourself and simply drop it in ~/.mozilla/plugins/

Note that flash player 9.0 r115 (which you will get if you download it now) and later have stricter policy files which can cause your client to not be able to connect anymore to certain servers. See for example here and Adobes article on the matter. Version 9.0 r48 and r31 work fine for me. You can obtain the version of your current with:

strings $CHROOT/usr/lib/iceweasel/plugins/ | grep -e "^Shockwave Flash [.\d+]*" | sed -e "s/Shockwave Flash //g"

The version is also visible in about:plugins

Download install_flash_player_9_linux.tar.gz from and save and extract the tar-ball, change directory to the extracted content and run as non-root:

linux32 ./flashplayer-installer

to install the plugin in ~/.mozilla/plugins, or run as root to install system wide (the wrapper must be system wide too then, of course). In the latter case enter <CHROOT>/usr/lib/iceweasel as browser directory, where you should replace <CHROOT> with the value of your $CHROOT.

Finally, you want to test it of course. Try this cool site.

Installing An Embedded PDF Viewer Plugin

I wasted two days trying to get acroread to work, but it's broken. Seriously, this is not incompetence; Adobe's acrobat reader really sucks.

Fortunately, there is an open source alternative and that means that if that doesn't work, we can fix it!

Firstly install mozplugger in the firefox chroot, and evince on your amd64:

sudo chroot $CHROOT apt-get --yes install mozplugger
sudo apt-get install evince

This should immediately allow you to watch movies inside the browser (provided you have mplayer installed in your amd64 environment); try to open some .avi from your harddisk with the browser. Also have a look at about:plugins again. Wait, ... watching PDF and postscript works too. It just all works! I love open source.

Installing The Java Plugin

More closed source... Yes, java is open source these days, but the plugin isn't: Sun refuses to release a 64-bit plugin for java, and when that was really open source, it would have been ported long ago.

The following commands will make java work:

sudo chroot $CHROOT
apt-get --yes install libnss-mdns
export LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun/jre/lib/i386/jli
apt-get --yes --force-yes install sun-java6-bin

The export is needed as work around for bug #435293 in the Debian bug tracking system. The package libnss-mdns is needed because otherwise java just hangs firefox with 100% cpu usage. You don't want to know what I all needed to do to find that THAT was needed! Unfortunately, I still don't know WHY it is needed, rather unsatisfactory.

Finally, we need:

exit # Leave chroot
sudo update-alternatives --install /usr/lib/mozilla-firefox/plugins/ $CHROOT/usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/ 100
sudo update-alternatives --set $CHROOT/usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/

The first update-alternatives command (see man update-alternatives) creates (or appends to) a group with generic name /usr/lib/mozilla-firefox/plugins/ and possible value $CHROOT/usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/ The group is created in automatic mode, using the (arbitrarily chosen) priority 100. The second update-alternatives command sets the group in manual mode and permanently links it to the given value. In effect, the result is that a symbolic link /usr/lib/mozilla-firefox/plugins/ points to /etc/alternatives/ which in turn points to $CHROOT/usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/

So why is this needed? Well, when run, iceweasel tries to load all shared libraries in $CHROOT/usr/lib/mozilla-firefox/plugins, the installation of sun-java6-bin in the chroot created an alternative with the name /usr/lib/mozilla-firefox/plugins in the chroot that points to /etc/alternatives/, exactly as we just did thus (and even if it didn't do that; firefox simply loads everything from /usr/lib/mozilla-firefox/plugins in the amd64 root!). Therefore, either by reading the link $CHROOT/usr/lib/mozilla-firefox/plugins or by reading a hardcoded path /usr/lib/mozilla-firefox/plugins, it is refered to /etc/alternatives/ in the amd64 root! Hence, we need to add this alternative/symlink and point it back to the correct shared library in the chroot. There is a minor problem with this however. Suppose one day you run 'apt-get update & apt-get upgrade' in the chroot, and it changes the symbolic link— then our manually added link will not change along and java will simply not work anymore. In that case you will have to update this alternative manually. It is unlikely that it will change however: the name of the package is sun-java6-bin, containing the '6', so at most the 'ns7' part might change one day to 'ns8'?

The most up to date version of this HOWTO can be found on my home page, together with more debian related HOWTO's from myself.

Regards, Carlo Wood



Posted by paulgear (124.171.xx.xx) on Mon 10 Mar 2008 at 06:53
Why would anyone want to wreck their beautiful clean 64-bit browser with Flash and Java? :-)

Seriously, lack of Flash support is a *feature* as far as i'm concerned.

[ Parent | Reply to this comment ]

Posted by Anonymous (204.31.xx.xx) on Mon 10 Mar 2008 at 17:36
I conccurr, we use open source software for a support open source software :P

[ Parent | Reply to this comment ]

Posted by paulgear (124.171.xx.xx) on Mon 10 Mar 2008 at 19:59
My comment was nothing to do with supporting open source, but on purely aesthetic grounds - i hate animated advertising that you can't just right click and choose ignore.

[ Parent | Reply to this comment ]

Posted by CarloWood (77.248.xx.xx) on Tue 11 Mar 2008 at 01:10
Well, if you get a birtday e-card -- it contains flash. If you want to watch videos on youtube, you need flash. And I play flash games to recreate myself on a daily basis. I'm pretty sure that those games won't work with the current open source flash implementations; but if anyone writes a HOWTO the will allow me to test it out without losing AGAIN a lot of time, then I will certain want to try and see if my favourite games work.

[ Parent | Reply to this comment ]

Posted by paulgear (203.206.xx.xx) on Tue 11 Mar 2008 at 03:57
Sorry if i sounded dismissive, Carlo - your howto is a very valuable resource. I will certainly use it to create a Flash-enabled browser. I just find Flash's absence in my day-to-day browsing a great advantage.

[ Parent | Reply to this comment ]

Posted by Anonymous (74.235.xx.xx) on Wed 12 Mar 2008 at 04:17
Hi, I found your article very informative. You are very knowledgeable. I have watched many videos using mplayer or xine on youtube. The flv formats are playable with players that use ffmpeg and it is legal. The hardest thing is actually finding the true link to the flash video but there are tools for this in debian. I also would like to add the icecat project is working towards a .xpi flash plugin using gnash but I don't know how he proposes to solve the software dependences of gnash. Seems like mplayer with ffmpeg would be the logical solution. While all you big boys are running systems at the speed of light I am still mostly terminal based. So the smaller and cleaner the code the better. I have three 64 bit systems (one alpha, one sgi mips, and one powerpc ) and they run better with really clean code in "c" as most 64 bit systems do. I would use a "free" alternative to anything offered by adobe. You are talking about your freedom. Thanks for your article. Try using mplayer from source if needed.

[ Parent | Reply to this comment ]

Posted by Anonymous (79.46.xx.xx) on Mon 28 Jul 2008 at 13:58
You don't need a chroot for flash, only for java. You can use nspluginwrapper for flash.

[ Parent | Reply to this comment ]

Posted by peterhoeg (193.163.xx.xx) on Mon 10 Mar 2008 at 14:51
Now, I've never tried the full chroot option, but I cannot imagine that the proposed solution should be easier.

If I was using a 64bit box, I would run a stripped down 32bit Ubuntu in virtualbox for the sites, where I needed this.

[ Parent | Reply to this comment ]

Posted by CarloWood (77.248.xx.xx) on Mon 10 Mar 2008 at 16:55
It is not easier, but it has the benefit of NOT running firefox inside a chroot. As said in the introduction, that means that if you download a file you can save it to your normal root, and if you start an external program it will run as 64-bit.

[ Parent | Reply to this comment ]

Posted by Anonymous (78.102.xx.xx) on Mon 10 Mar 2008 at 15:37
Well, I use x86_64 (tarbals from contrib) Mozilla Suite (SeaMonkey) on my amd64 lenny without problems with adobe flash plugin (via nspluginwrapper).
Nothing horrors with chroot.
If I need java, i send this page to konqueror (via launche extension) with native amd64 java support...

[ Parent | Reply to this comment ]

Posted by Anonymous (130.126.xx.xx) on Mon 10 Mar 2008 at 16:44
I've mentioned before, the best way I have found for firefox is to use swiftfox

swiftfox is a build of firefox (32 bit) that is designed to run out of a single directory. So download swiftfox, untar to your home directory, and fire it up. No messing with packages, no installing, no chroot... you just need to install ia32-libs, and swiftfox runs fine.

As far as java, java has now been released as open source so you have a 4th option to just run a 64bit java plugin.



the debian build instructions say you can just download the ubuntu package, and use dpkg-buildpackage -b -rfakeroot

Then you get a 64-bit java plugin.

[ Parent | Reply to this comment ]

Posted by Anonymous (85.214.xx.xx) on Mon 10 Mar 2008 at 22:06

Better options have been suggested. This article seems to be using chroot to solve a problem better suited to virtualization. I have a lot of reservations about maintaining the security of a setup like this, not to mention the performance loss by having to load a bunch of 32-bit libraries in addition to all the 64-bit libraries. I'd suggest 2 other options:

4. Run amd64 only with Gnash or Swfdec for flash. Yes both are far from perfect but they are getting better. You can use gcjwebplugin for java.

5. Use your virtualization solution of choice (VirtualBox would be my suggestion as easiest to setup and use) to run a 32-bit OS.

Either one of these options requires far less work in setup and maintenance than the steps described here. Mixing 32-bit and 64-bit on the same system has never been a good idea in my opinion. That's the perfect scenario to utilize virtualization, or to try and ditch the 32-bit requirements altogether.

[ Parent | Reply to this comment ]

Posted by CarloWood (77.248.xx.xx) on Tue 11 Mar 2008 at 01:07

I can't comment on other methods because I'm not aware of an existing HOWTO that would explain to me step by step how to set it up. However, this setup requires no work as you seem to think. I wasn't easy to find out how to get it to work, but now this HOWTO exists, it's no more than a copying and pasting all the commands to ones shell prompt. You choose and set a CHROOT environment variable and the rest could be executed automatically by a script. The reason I choose for the current form, where every few commands an explanation is inserted, is because I believe that such a thing is far more valuable than a black-box script.

I'd be very interested in trying out other setups. Please add a link to a HOWTO that describes in detail how to set THOSE up.

[ Parent | Reply to this comment ]

Posted by Anonymous (217.216.xx.xx) on Thu 13 Mar 2008 at 19:52
There's an easier way through

[ Parent | Reply to this comment ]

Posted by distances (82.234.xx.xx) on Sun 27 Apr 2008 at 01:12

I can imagine that it's possible to remove (a lot of) libraries from the chroot because they are already installed as some ia32 package

Well, indeed, it is: only the libnss-mdns package (or lib32nss-mdns to install in /lib32) is really necessary --

[ Parent | Reply to this comment ]

Posted by Anonymous (71.130.xx.xx) on Mon 28 Apr 2008 at 04:44
I tried this HowTo out on a HP AMD64 with a fresh Etch install. Iceweasel starts fine and will access my local network. But if I try to access the internet it can't find any servers.

Internet access works fine from within the chroot however.

Any ideas how I can fix this?

Gary (witscher AT gmail DOT com)


[ Parent | Reply to this comment ]

Posted by CarloWood (77.248.xx.xx) on Mon 28 Apr 2008 at 13:18
Hi Anonymous. I can't help you with this, but please note that this page is a copy of the original at that contains a section "Trouble shooting" that I left out in this article. It might be helpful for you to debug the problem.

[ Parent | Reply to this comment ]

Posted by Anonymous (217.74.xx.xx) on Wed 21 May 2008 at 09:34
You have probably found solution for your problem, but in case if you didn't, i can say that i have had a similar problem (networking worked from shell (ex. ping), but in iceweasel still got 'can't connect'), until i installed the libnss-mdns package. After then everything works nice. I didn't investigate if it is this package, which solved the problem, or if it is some of it's dependencies.

[ Parent | Reply to this comment ]

Posted by manawiz (67.153.xx.xx) on Thu 12 Jun 2008 at 22:08
I've followed all the instructions and have the 32-bit iceweasel running outside the chroot using the wrapper, the 32-bit flash plugin works, but the java plugin does not.

I've verified the correct firefox is running and it is 32-bit, have verified all of its libraries are 32-bit, either in ia32 compatibility or in the chroot, by using /proc/pid/maps, have run the 32-bit iceweasel in gdb, but can find no messages or errors concerning the java plugin at all. about:plugins shows that only the flash plugin is loaded. Mozplugger is loaded according to /proc/pid/maps, and I get a warning about no mozpluggerrc, but the pdf/evince mapping does not work.

There are no messages, no libraries, nothing, about the java plugin. Java is enabled in Preferences, and sits in in the same plugins dir as flash and mozplugger, but just isn't there. Whenever I try to load a java applet iceweasel says there is no plugin for it.

The missing mozpluggerrc is suspect because it does exist in the chroot. I do not use mozplugger in the amd64 base system (using acroread instead, which works great), and /proc/pid/maps shows it is coming from the chroot, but for some reason it does not look for mozpluggerrc there.

I have lenny and found two issues in the how-to wrt my setup: the code to process /etc/apt/sources.list does not work correct if you use ftp: sources in your base system instead of http: sources, and the plugins are in /usr/lib/mozilla/plugins, not /usr/lib/mozilla-firefox/plugins. (I added links from /usr/lib/mozilla-firefox/plugins just in case Java needed to be there for some strange reason, but that was not the issue.) Both of the issues are trivial to fix.

Anybody have an idea why Java would silently be absent? Anybody gotten Java working with these instructions?

[ Parent | Reply to this comment ]

Posted by Anonymous (194.97.xx.xx) on Thu 18 Sep 2008 at 10:45
I had this setup working beautifully .. until I tried to do it on a newer machine (both machines are debian/unstable) .. now I have this error message when I try to call my wrapper script :
$ /usr/local/bin/firefox
/emul/ia32-firefox/usr/lib/iceweasel/iceweasel: line 147: /emul/ia32-firefox/usr/lib/iceweasel/firefox-bin: No such file or directory
/emul/ia32-firefox/usr/lib/iceweasel/iceweasel: line 147: /emul/ia32-firefox/usr/lib/iceweasel/firefox-bin: Success

Any clues about this ?


[ Parent | Reply to this comment ]

Posted by Anonymous (194.97.xx.xx) on Thu 25 Sep 2008 at 19:25
I should learn that removing libc6-i386 isn't a good thing ;)
after reinstalling this package, everything went back to it's normal :)

[ Parent | Reply to this comment ]

Posted by Anonymous (190.246.xx.xx) on Fri 5 Dec 2008 at 15:57
Its just a detail but there is a mistake here:
This should create a file with content like the following:

export GTK_PATH="/usr/lib32/gtk-2.0"
export LD_LIBRARY_PATH="/lib32:/usr/lib32:$CHROOT/lib:$CHROOT/usr/l ib"
linux32 "$CHROOT/usr/lib/iceweasel/iceweasel" "$@"
should read:
This should create a file with content like the following:

export GTK_PATH="/usr/lib32/gtk-2.0"
export LD_LIBRARY_PATH="/lib32:/usr/lib32:$CHROOT/lib:$CHROOT/usr/l ib"
linux32 "$CHROOT/usr/lib/iceweasel/iceweasel" "$@"

the only difference is
CHROOT="/opt2/firefox-chroot" ---> CHROOT="/opt/firefox-chroot"

Thanks for the HOWTO, even thought im still fighting :P


[ Parent | Reply to this comment ]

Posted by Anonymous (190.246.xx.xx) on Fri 5 Dec 2008 at 16:14
I have followed your HOWTO (until the "Install Plugins" part), with the exception that I did everything as root instead of using sudo and when I run firefox i get and then execute

:~$ ps --forest aux | grep -A3 '[f]irefox'

I get this

1000 8624 5.5 2.6 737876 220164 ? Sl 13:32 2:09 /usr/lib/iceweasel/firefox-bin -a iceweasel
1000 8751 0.1 0.3 287240 28056 ? Sl 13:40 0:03 gnome-terminal
1000 8753 0.0 0.0 19288 836 ? S 13:40 0:00 \_ gnome-pty-helper
1000 8754 0.0 0.0 21820 3572 pts/1 Ss 13:40 0:00 \_ bash
1000 24927 0.0 0.0 10672 900 pts/3 S+ 13:52 0:00 | \_ less /usr/local/bin/firefox
1000 24935 0.0 0.0 21820 3592 pts/4 Ss 13:57 0:00 \_ bash
1000 25125 0.0 0.0 17272 1128 pts/4 R+ 14:11 0:00 | \_ ps --forest aux
1000 25126 0.0 0.0 6300 800 pts/4 S+ 14:11 0:00 | \_ grep -A3 [f]irefox

That means that I am still using the 64-bit firefox, right? could you give me a hand?

Thanks a lot


[ Parent | Reply to this comment ]

Posted by Anonymous (190.246.xx.xx) on Sat 10 Jan 2009 at 16:48
Now that a 64 bits version of java is out I need to undo all this stuff, could you tell me how do I do it? thanks

[ Parent | Reply to this comment ]

Posted by CarloWood (24.132.xx.xx) on Mon 12 Jan 2009 at 15:38
Basically, remove what was added to /etc/apt/sources.list, umount every bind mount of your CHROOT (make very sure you have no (bind) mounts left) then delete the 32bit CHROOT directory. And finally delete the wrapper (/usr/local/bin/firefox).

[ Parent | Reply to this comment ]

Sign In







Current Poll

Will you stick to systemd as the default in Debian?

( 910 votes ~ 35 comments )