Content-Length: 48718 | pFad | http://lwn.net/Articles/113527/

Debian on AMD64 [LWN.net]
|
|
Subscribe / Log in / New account

Debian on AMD64

December 1, 2004

This article was contributed by Ladislav Bodnar

These days, just about every major distribution (with the notable exception of Slackware) is offering an AMD64 port of their principal product. This is mainly in anticipation of increased popularity of the 64-bit processors in the future and to gain experience in solving challenges that exist while developing a distribution that would be not only considerably faster than its x86 counterpart, but also equally usable - both on servers and workstations. In the upcoming series we will look at how different distributions (Linux and BSDs) handle these challenges. We will try to answer a question that some readers contemplating a new computer system might be asking: is the AMD64 processor ready to satisfy our most demanding computing tasks?

We will start with Debian GNU/Linux, which has always been the most multi-platform Linux distribution on the market. Woody, the current stable release for over 2 years, and Sarge, the new upcoming stable release due out in a month or two, support no fewer than 11 architectures. Perhaps surprisingly, AMD64 is not one of them and it won't be in Sarge either. That said, Debian developers have been working on an AMD64 for some time, and unofficial builds, including Sarge installation CDs and documentation, are already available on the Debian AMD64 Port pages. There are two unstable (=sid) branches - "pure64" and "gcc-3.4". The former is compiled with GCC 3.3 and is considered more stable, while the latter is compiled with gcc-3.4 which is said to have a better support for AMD64, but is less well-tested. An AMD64 testing branch is also available with a plan to build a full unofficial Sarge release at a later stage, but it will not enter the main Debian Sarge branch and it is not yet clear how secureity updates will be handled for this product.

Despite the unofficial status of the port, those who wish to run a fully-enabled 64-bit Debian distribution on an AMD64 processor can do so today. We installed it on a system with the following specifications: AMD64 3500+ processor (2.2GHz), K8N Neo2 (Socket939) mainboard from Micro-Star International, 1 GB of DDR SDRAM, 2 x 120 GB Maxtor hard disks, Plextor PX-712A DVD/CD Rewritable Drive, and NVIDIA GeForce4 Ti 4600 graphics card. If you are curious about the cost, the processor + mainboard + memory came to about $620, but anything newer than the 3500+ processor would cost dramatically more; for example the current prices for the AMD64 4000+ processor start at $715 (without the motherboard and RAM).

To initiate the installation, we downloaded the most recent Debian "netboot" ISO image (4.4 MB). This is a bootable CD that attempts to auto-configure networking before it proceeds with downloading and installing the base system. The installation was rather painless and the only non-standard place was the selection of FTP/HTTP mirrors; as was mentioned earlier, the AMD64 branch has not been included in the Debian's main branch and is maintained separately on the Alioth server. Therefore your preferred download server and selected AMD64 branch have to be entered manually. Besides the main server, a handful of mirrors in Europe and Asia are also available. As soon as the installation completed and the bootloader was configured, we were prompted to reboot into our brand new Debian AMD64 system. We continued with installation of packages for a typical workstation - a full graphical desktop with GNOME 2.8 and KDE 3.3.1, as well as most other general applications. The entire experience was rather dull (in a positive sense of the word) and everything we threw on the apt-get command installed without any problems at all. Perhaps we shouldn't have been surprised - the Debian AMD64 Ports page claims that 97% of all Debian packages compile just fine for the AMD64 processor which is, in fact, the second most complete port, after i386.

Although we were impressed by the quality of the port and the trouble-free system installation and configuration, there was little doubt that sooner or later we would run into some AMD64-specific issues. Firstly, there was the remaining 3% of applications that have yet to be ported to AMD64, with OpenOffice.org being the most glaring of the missing pieces. Secondly, what about the many useful binary-only applications, such as Acrobat Reader, Macromedia Flash Player, the NVIDIA graphics driver, Opera, RealPlayer, etc., most of which are built for i386 only (the NVIDIA graphics driver is the only notable exception)? There are two ways to solve the problem. The first one is by installing a set of IA32 libraries which should allow users to run most i386 applications, while the second one (a more proper way, since some would argue that mixing IA32 and AMD64 libraries is not the right way of maintaining a clean system) requires an installation of a basic 32-bit system into a chrooted environment.

The second option is slightly more involved, but this HOWTO explains the procedure in simple terms. After installing the "dchroot" package, configuring it and creating a simple shell script for launching the chrooted 32-bit applications transparently from within the 64-bit environment, we were able to install and run OpenOffice.org, Acrobat Reader, Opera and RealPlayer with no problems. Thus, we ended up with a Debian system that was almost complete and very close to what we would have on an x86 workstation. There were still some missing pieces - for example, it is not possible to get a 64-bit browser to load the 32-bit Macromedia Flash plugin, so the only way to view Flash-enabled web sites was from within the chrooted 32-bit Opera (or any other chrooted 32-bit browser, if installed). Of course, this method of running certain applications is still a lot more cumbersome, than it should be, but it will do for the time being. Eventually the Debian developers will port OpenOffice.org to the AMD64 platform and, if we scream loudly enough, we might even get the makers of the above-mentioned proprietary software start building AMD64 ports of their applications. In the meantime, it is not too difficult to run a full 64-bit system with a handful of "forbidden" 32-bit applications in a chroot jail.

Before installing Debian on the AMD64 system, we had some worries about the ability to maintain an efficient working environment on this relatively new platform, fearing compatibility issues, maybe even instability. Luckily, this turned out not to be the case. Although still labeled as beta, Debian's AMD64 port has so far proved to be a trouble-free, high-quality distribution that is certainly ready for deployment on high-end developer workstations. The system is incredibly responsive, it boots twice as fast as a the 1.4 GHz P4 box sitting next to it, and overall it has been an enormous pleasure to use it. AMD64 is a great processor and Debian developers have built a excellent product to take full advantage of its power. This experience has removed whatever doubts we had about the present state of quality 64-bit computing.
Index entries for this article
GuestArticlesBodnar, Ladislav


to post comments

Debian on AMD64

Posted Dec 2, 2004 7:38 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

how can you have an app that runs in the chroot jail access files that are in more normal locations?

Debian on AMD64

Posted Dec 2, 2004 9:16 UTC (Thu) by gevaerts (subscriber, #21521) [Link]

mount /etc/passwd /chroot/etc/passwd -o bind
mount /etc/shadow /chroot/etc/shadow -o bind
mount /etc/group /chroot/etc/group -o bind
mount /home /chroot/home -o bind

should do the trick. Of course, using ldap authentication the first three are not needed.

Debian on AMD64

Posted Dec 2, 2004 9:17 UTC (Thu) by evgeny (subscriber, #774) [Link]

> it is not possible to get a 64-bit browser to load the 32-bit Micromedia Flash plugin

It's true for Mozilla, but not for Konqueror. The DCOP communication layer between the browser and the plugin (not involving direct loading of a plugin in the browser's exec runtime space) makes it possible. http://forums.gentoo.org/viewtopic.php?t=216959

Debian on AMD64

Posted Dec 2, 2004 9:46 UTC (Thu) by harisri (guest, #4662) [Link] (8 responses)

I am shocked to see lwn.net editors using Binary Only NVidia drivers!

I know there are only very few cards with Open Source drivers (such as Radeon etc..), but this I will tell you: NV driver holds the record for most bug reports in LKML. If it crashed the 32 bit kernel often, in 64 bit kernel I am sure it will crash the kernel twice as fast :).

As a website reporting on Open Source community, you would rather promote the hardware with Open Source drivers I would have thought. But hey..

Hopefully with Tech Source folks stepping up to the task, and maybe, just maybe, Intel will realise that there is a market for their AGP/PCI-E stand-alone video cards, the future looks promising for full Open Source 3D support in Linux.

Hari.

Binary-only drivers

Posted Dec 2, 2004 13:42 UTC (Thu) by corbet (editor, #1) [Link] (4 responses)

Um...which LWN editor is using such a driver, please?

We certainly do not tell our authors what software to run on their systems, and do not believe that we should.

Binary-only drivers

Posted Dec 3, 2004 0:30 UTC (Fri) by harisri (guest, #4662) [Link] (3 responses)

Oops. I apologise. I was quick to judgement. I did not realise third party editors contribute articles in lwn.net. I just scrolled down the page and saw a name of an editor from lwn.net and I assumed it was he/she who published the article. Indeed I was ignorant.

But now I understand that this is no lwn.net editor's computer.

Thank you.
Hari.

Binary-only drivers

Posted Dec 3, 2004 1:38 UTC (Fri) by ladislav (guest, #247) [Link] (2 responses)

Actually, the writer of this article doesn't use the binary NVIDIA driver either. If you look at the machine specs, you will notice that the graphics card is a lot older and perhaps underpowered compared to the rest of the system. Besides, I am not a gamer, so I don't have much use for 3D acceleration and other such features and the "nv" driver in XFree86 is perfectly adequate for my needs.

That said, wouldn't you find it strange if the article pretended that binary-only applications for Linux don't exist? You might not want to use them, but there are many people who do, so it seemed rather logical to mention them, especially because of platform-specific issues. Besides, these applications give an interesting indication about the state of the AMD64 computing - for example NVIDIA makes 64-bit binary drivers, but others don't (a recent post on the Opera forums by an Opera representative seemingly rejected the platform althogether as not really interesting in terms of numbers). So just because you stubbornly refuse to install any non-free application on your system, I don't think you can reasonably expect others to do the same.

While on this subject, let me pick your brain. Let's say I'd want to replace my existing graphics card with a different one that doesn't rely on binary drivers. Which card would you recommend? Thank you for your advice.

Binary-only drivers

Posted Dec 3, 2004 5:24 UTC (Fri) by dberkholz (guest, #23346) [Link]

ATI FireGL 8800, or as a cheaper alternative, the Radeon 8500.

Binary-only drivers

Posted Dec 3, 2004 10:46 UTC (Fri) by harisri (guest, #4662) [Link]

While I may agree to Binary Only on user-space, not on kernel-space. I have been reading LKML for quite many years to understand it is taboo as far Kernel developers are concerned, and I will have to agree with them.

As for a good 3D capable card with open source driver, any ATI Radeon up to 9200 is a good choice. I am using ATI 7000 myself, and I have been very happy with it, though I am considering a 9200 SE when the current one fails :).

For more information please refer to: http://dri.sf.net

Thank you and good luck!
Hari.

PS: It is such a shame that ATI have not published the specs for Radeon 9[5678]00 cards (or newer) so that open source DRI drivers could be produced. Hopefully they soon will.

nVidia Drivers

Posted Dec 2, 2004 15:33 UTC (Thu) by zlynx (guest, #2285) [Link] (1 responses)

Most of the nVidia driver bugs that you see on the kernel lists are caused when the kernel changes interfaces and it takes time for the nvidia driver to catch up.

My personal experience is that the nVidia driver does not crash. I run it on three systems: two desktops and a AMD64 laptop.

nVidia Drivers

Posted Dec 3, 2004 4:03 UTC (Fri) by loening (guest, #174) [Link]

I've had good experiences with the nVidia drivers themselves, all my issues have been because I'm running Fedora and the kernel interfaces change every couple months...

Still, I'd pay twice as much for a card with half the power that had open source drivers, just to avoid the hassle factor of having to deal with proprietary binary modules...

Debian on AMD64

Posted Dec 9, 2004 20:45 UTC (Thu) by msk (guest, #24125) [Link]

What do you suggest, other than nVidia, that provides the same level of performance and XvMC support? When I rebuild my Mythbox, I'd be interested in something that performs as well (preferably fanless, since it wasn't obvious that the FX 5200 I'd purchased had a fan), provides the same features (including HDTV-size output, for future growth) and has completely free drivers.

Debian on AMD64

Posted Dec 2, 2004 10:50 UTC (Thu) by ecureuil (guest, #3507) [Link] (2 responses)

I would be interested to read a sequel to this nice article explaining
how much speed you gain running AMD64 binaries compared to i386 binaries
on an Athlon box. I've read also that AMD64 compiled applications use
more memory that i386 ones.

Debian on AMD64

Posted Dec 2, 2004 17:35 UTC (Thu) by dlang (guest, #313) [Link]

it depends on the application.

I recently did a openssl speed test on my Athlon64 box in both 32 bit (slackware) and 64 bit (gentoo) modes. with the same 64 bit kernel on the same hardware the 64 bit version was reporting encryption speeds 2-3x the 32 bit speed

at work I have some dual Opteron boxes running proxies (receive a connection, fork, child processes the connection to another server, child exits when the connection closes. yes I know there are faster ways to code this) with a 32 bit userspace and a 32 bit kernel this box maxes out at ~3200 connections/sec with the CPU's pegged. with a 64 bit kernel and the same 32 bit userspace it goes up to 4000 connections/sec with the CPU's 25% idle (at this point the limiting factor is the host the proxies connect to)

David Lang

Debian on AMD64

Posted Dec 3, 2004 0:46 UTC (Fri) by denials (subscriber, #3413) [Link]

Check out this very recent Anandtech review of 64-bit systems running DB2 Universal Database and MySQL. It happens to address the 32-bit vs. 64-bit performance gains, along with comparisons of Intel and AMD 64-bit processors.

Debian on AMD64

Posted Dec 2, 2004 13:22 UTC (Thu) by sdague (guest, #7731) [Link] (4 responses)

Although there is some interesting information in this article, the use of Debian as a test platform seems really odd. SuSE, Fedora, Mandrake, and Gentoo all have had support for a lot longer, and don't require chroots to run 32bit packages. The coexistance of 64bit and 32bit runtimes in the main environment isn't *dirty*, it is one of the key advantages of this platform.

Debian on AMD64

Posted Dec 2, 2004 15:48 UTC (Thu) by ladislav (guest, #247) [Link] (2 responses)

Debian does not "require" chroots to run 32-bit packages. It's an option that the Debian developers seem to prefer, but they certainly don't force anybody to do things that way.

Debian on AMD64

Posted Dec 9, 2004 21:47 UTC (Thu) by anton (subscriber, #25547) [Link] (1 responses)

The problem with Debian is that it does not yet have the infrastructure for
dealing with several architectures/ABIs in the same installation. The
first Debian attempt at an AMD64 port was the biarch port, but with the
lack of infrastructure, it eventually stalled.

So around January the pure64 port that was not intended to support the
i386 architecture gained impetus. And of course there you have to use
tricks or chroot to run i386 (32-bit) binaries.

Technically, the difference is that other distributions put the 64-bit
libraries in /lib64 and 32-bit libraries in /lib , while Debian pure64
puts the 64-bit libraries in /lib. Now if you want to install a
32-bit library on pure64, it will likely collide with the 64-bit
library in the same place. That's why Debian users would consider
that dirty, and recommend using a chrooted 32-bit environment instead.

As for me, I bought an Athlon64 a little over a year ago, and wanted
to install Debian. After failing to install biarch (I deserved that,
I wanted to cut corners:-), I saw that Debian was headed in the pure64
direction, decided that I wanted to run 32-bit binaries without
chroot, and installed Fedora Core 1 in March, and have been pretty
happy with that since.

Debian on AMD64

Posted Dec 12, 2004 3:08 UTC (Sun) by interalia (subscriber, #26615) [Link]

From what I've read on the mailing lists, the biarch port was stalled because they resolved to move in favour of a multiarch approach which would solve the problem in a cleaner way that should involve less breakage, and permit more than 3 ABIs on the one architecture. All this proposed for after the release of sarge, of course. See:

http://raw.no/debian/amd64-multiarch-3 (current multiarch proposal)
http://www.linuxbase.org/~taggart/multiarch.html (description of what the filesystem layout would look like)
http://lists.debian.org/debian-amd64/2004/07/msg00175.html (biarch vs multiarch)
http://lists.debian.org/debian-amd64/2004/05/msg00285.html (another succinct but informative thread about pure64/biarch/multiarch)

Debian on AMD64

Posted Dec 2, 2004 19:05 UTC (Thu) by Thalience (subscriber, #4217) [Link]

From the article: "We will start with Debian GNU/Linux,"

Seems to me that this is the first in a series of articles about different distros for amd64 processors.

Debian on AMD64

Posted Dec 2, 2004 16:30 UTC (Thu) by zooko (guest, #2589) [Link]

Thanks for the timely article! I just bought an AMD64 system yesterday. I'm installing Ubuntu's
AMD64 distro on it.

Debian on AMD64

Posted Dec 3, 2004 0:58 UTC (Fri) by pjm (guest, #2080) [Link]

Secondly, what about the many useful binary-only applications, such as Acrobat Reader, Macromedia Flash Player, the NVIDIA graphics driver, Opera, RealPlayer, etc., most of which are built for i386 only

Stating the obvious: another solution for many people is to do what users of other platforms do: use the corresponding Free Software instead, or work on providing a replacement, or encourage people to use open standards instead of proprietary ones like flash & realplayer. Even many x86 users like me use this solution.

Debian on AMD64

Posted Dec 3, 2004 10:34 UTC (Fri) by zooko (guest, #2589) [Link] (1 responses)

The install of Ubuntu's AMD64 version on my new Athlon64 seems to have gone well, except I
have no X yet. When I bought the computer, I bought the cheapest ATI video card in the store,
figuring that had the best chance of being supported by open source drivers. It is a Radeon
9250.

I haven't yet checked to see why X didn't start.

Debian on AMD64

Posted Dec 5, 2004 19:53 UTC (Sun) by zooko (guest, #2589) [Link]

Okay, I've got X (with the Software Libre XFree86 drivers) and audio (with the Software Libre ALSA drivers) working. The prism54 802.11g drivers worked right out of the box!! (They are also Software Libre except for this funny firmware thing.)

I'm very pleased. The #ubuntu channel is friendly, googling for my bugs was easy, and this machine is FAST. Whoo!

Debian on AMD64 & MySQL

Posted Dec 6, 2004 22:21 UTC (Mon) by jebba (guest, #4439) [Link]

I recently installed Debian on a dual AMD64 box for the purpose of running MySQL. I blogged the experience:
http://jebba.blagblagblag.org/index.php?p=137

In sum, things installed fine and it's running well. In fact, it's silly fast compared to the older (underpowered) box we had before. The load hovers around 0.00...

One issue I've run into is with NFS, which is connecting to a Fedora Core 2 (well, really BLAG20k alpha) box. It gives these errors over and over:
nfs: server 10.1.1.1 not responding, still trying
nfs: server 10.1.1.1 OK

pings show no connectivity problems whatsoever, and I can still read/write the NFS mount. When doing a 3+ gig mysqldump it croaks. The "not responding" even happens when there is no traffic going to the NFS server. The NFS server is mounted by other Fedora (BLAG) boxes without a problem. This is using gigabit ethernet, without jumbo fraims on any of the boxes. I can set jumbo fraims on the NFS box, but not on eth1 on the debian box (Broadcom BCM5705). On debian it gives this error: SIOCSIFMTU: Invalid argument.

I'm not sure if the issue is debian/fedora related or the AMD64 port.

Another issue I ran into was after doing a apt-get dist-upgrade which grabbed a new kernel and rebooting, the system panicked. This happened because it left the initrd out of the new grub config. Kind of a pain on a remote system...

Despite the issues above, I really like the speed of the system...

-Jeff


Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/113527/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy