Last May I bought an ATI Radeon HD4830 video card for my music/gaming system. I would have gone with nVidia, but my last laptop had an nVidia graphics driver and I got quite frustrated with trying to keep the binary drivers up-to-date on it (even using RPM Fusion, I would run into odd problems every now and then).

I wanted a card that would have open drivers. Now, I knew when I bought the 4830 that it wasn’t supported by the open radeon driver, but I also knew it would be ready soon, and I figured I could use the closed drivers until then.

And that’s when I found out that ATI’s closed-source binary Catalyst driver is so poorly maintained, it makes Windows 95 look up-to-date. It took several months for AMD/ATI to put out a Catalyst driver that would support Fedora 11, and they still haven’t put out a Catalyst driver that supports Fedora 12.

The driver also is extremely buggy. Any release after 9.8 wouldn’t work with my original motherboard (see this bug), and after upgrading to a new Intel motherboard and processor a couple of weeks ago, I had random crashes that ranged from once every couple of days to once every fifteen minutes.

If I could ssh into the computer (which was only about half of the time), I’d see some message about an “ASIC hang”. Googling it didn’t give much information. I originally thought it had something to do with the power supply, but even a brand name power supply didn’t fix the problem.

Yesterday, I finally had enough. I wiped the hard drive and did a clean install of Fedora 12. Yeah, Catalyst won’t work, but I’d been hearing good things about mesa-drivers-experimental, so I decided to give it a go.

So, first the down side to switching:

• Nexuiz runs much slower. With the binary drivers, I was able to run the game at 1920×1080 ultimate quality at 50-60 fps. With the experimental driver, it’s down to 3-4 fps (though medium quality works great at 50-60 fps).
• XBMC ProjectM visualizations are slow. Again, with the binary drivers, the ProjectM visualizations ran at full speed, while with the experimental drivers, they run at 5-6 fps.

But, the good news is:

• I can play my 3D games just fine. Even though I can’t run them at full quality, I can still play my games.
• XBMC movies run at full speed. Even with the cool effects that XBMC uses for its controls, movies work perfectly.
• XBMC slideshows work fine, with panning and zooming. The slideshow work the way they are supposed to with no delays at all. In fact, I may be imagining it, but I think there was the occasional slight delay in catalyst that isn’t there now
• THE SYSTEM DOESN’T HANG/CRASH. I haven’t had a single system hang since switching. And that is worth far more to me than the best Nexuiz framerate ever.

Using the open experimental drivers brings me back to the reason I bought ATI in the first place, and I can finally say that I’m glad I bought ATI. Binary drivers are a pain to keep up with, and I’m so glad I don’t have to deal with that any more. I’m hoping to see things running even better in Fedora 13.

Update: The story continues here.

I’ve had a request for an explanation on how we use PXE and syslinux in our school. In a previous post, I talked a bit about chain-loading pxe, but didn’t explain much on how our system is set up.

So here goes…

Our primary goal in setting up a PXE environment was to have some way of imaging our computers without having to screw around with an ancient version of Norton Ghost and without having to put a floppy in every computer.

The problem was that we really didn’t want students to be able to reimage the computers whenever they wanted to, and there were other tools we wanted to use that we wanted restricted.

The solution was PXELINUX’s simple menu, and it works beautifully! This post will walk you through the process of setting up PXELINUX (and gPXE while we’re at it).

For this post, I am assuming that you already have a DHCP server and a web server set up.

There are three things we need to set up:

1. TFTP server
2. gPXE
3. Syslinux

The first step is to set up a TFTP server to carry our gPXE images.

1. Run

   yum install tftp-server
   

2. Edit /etc/xinetd.d/tftp and change the line that says

   disable = yes
   

   to

   disable = no
   

3. If this is the initial installation of xinetd, you may need to run chkconfig --levels 2345 xinetd on

   service xinetd start
   

   at this point. Otherwise, it might be a good idea to run

   service xinetd reload
   

Now, for the next step, we need to download our gPXE images. gPXE is an extended version of PXE that allows you to load images over http and https in addition to the usual tftp. As most (all?) network cards don’t come with gPXE drivers, we will be using PXE to download and bootstrap our gPXE drivers.

As mentioned in my previous post, some of our motherboards seem to have issues mixing PXE and their normal PXE UNDI drivers, so I prefer to use gPXE’s native drivers rather than its UNDI driver.

However, we have four computers whose network cards just don’t work with gPXE’s native drivers, so we will direct those four computers to the gPXE UNDI driver.

So let’s grab and setup these drivers:

1. Go to ROM-o-matic and choose the latest production release
2. For output format, choose “PXE bootstrap loader image [Unload PXE stack] (.pxe)”
3. Choose NIC type “all-drivers”
4. Click on “Customize”
5. Check the box that says “DOWNLOAD_PROTO_HTTPS”
6. Click on the button that says “Get Image”
7. Save file to /tftpboot/gpxe.pxe
8. Change NIC type to “undionly”
9. Click on the button that says “Get Image”
10. Save file to /tftpboot/undi.pxe

I’m assuming you’re running the ISC dhcp server (dhcp package on both Fedora and CentOS). If not, you’ll have to work out these next steps yourself.

You need to edit /etc/dhcpd.conf and add the following lines:

next-server     ip address;

if exists user-class and option user-class = "gPXE" {
    filename "http://webserver/netboot/pxelinux.0";
} else {
    filename "/gpxe.pxe";
}

Where ip address is the ip address of your TFTP server and webserver is the name/ip address of your web server.

If you have some computers that won’t pxeboot using gPXE’s native drivers (you’ll be able to tell because the computers will show the gPXE loading screen, but won’t be able to get an IP address using DHCP while in gPXE), change the last five lines above to:

if exists user-class and option user-class = "gPXE" {
    filename "http://webserver/netboot
} else {
    if binary-to-ascii(16, 8, ":",
       substring(hardware, 1, 6)) = "mac address 1"
    or binary-to-ascii(16, 8, ":",
       substring(hardware, 1, 6)) = "mac address 2" {
        filename "/undi.pxe";
    } else {
        filename "/gpxe.pxe";
    }
}

Where “mac address 1” and “mac address 2” are the MAC addresses of the computers that don’t work with gPXE’s native drivers. Please note the MAC address are without leading zeros (i.e. 00:19:d1:3a:0e:4b becomes 0:19:d1:3a:e:4b).

At this point, if you boot any computer on your network off the NIC, you should see something like this:

The next step is to setup PXELINUX, a part of the Syslinux Project. PXELINUX is a small bootloader designed for booting off a network.

1. On your web server, create a directory called “netboot” in your web root (normally /var/www/html on Fedora/CentOS).

2. Run

   yum install syslinux
   

   or, as an alternative, build a newer version of syslinux. I recommend at least 3.75 (the version in Fedora 12), though I’m using 3.82 at the school.

3. Copy (at minimum) chain.c32, menu.c32, vesamenu.c32 and pxelinux.0 to “netboot” in your web root. (These files will be located in /usr/share/syslinux if you installed the package using yum.) At this point, you’ll probably want to check for other modules that might have some potential. We use ifcpu64.c32 to decide between 32-bit and 64-bit Fedora on the computers.

4. Run:

   yum install memtest86+
   cp /boot/elf-memtest86+-4.00 \
   your_web_root/netboot/memtest
   

   (Note that “your_web_root” will most likely be /var/www/html)

5. Download this picture and save it to your_web_root/netboot

6. Change directory to your_web_root/netboot

7. Run

   mkdir pxelinux.cfg
   cd pxelinux.cfg
   

8. Create a file called “default” that contains the following:

   default vesamenu.c32
   timeout 40
   prompt 0
   noescape 1
   menu title Boot Options
   menu background menu.png
   menu master passwd $4$tek7ROr8$xzFCb2QVEWsc2msx3QsErbRuo0Y$
   
   label local
   menu label ^Boot from hard drive
   kernel chain.c32
   append hd0
   
   label admin
   menu label ^Administrative tools
   kernel vesamenu.c32
   append pxelinux.cfg/admin
   menu passwd $4$tek7ROr8$xzFCb2QVEWsc2msx3QsErbRuo0Y$
   

9. Create a file called “admin” that contains the following:

   default vesamenu.c32
   timeout 40
   prompt 0
   noescape 1
   menu title Administrative Tools
   menu background menu.png
   menu master passwd $4$tek7ROr8$xzFCb2QVEWsc2msx3QsErbRuo0Y$
   
   label memtest
   menu label ^Memory tester
   kernel memtest
   

If you boot any computer on your network off the NIC, you should see something like this:

So now you have a double layered menu system with a password required to get to the second layer. For reference’ sake, the current password is “purple”, and you can generate your own password by running sha1pass (included in the syslinux package).

If you wanted to add other administrative tools, you would add them to the file “admin” in netboot. For more information on how to add items to the menu, see this page.