Hi, all -

I'm using the ATI proprietary driver (I built debs && installed it w dpkg && module-assistant as per ) w etch on an amd64 box; it "just worked".

I would very much like to upgrade my kernel to something other than the 2.6.18 one that etch ships with; I'm using 2.6.21 everywhere else (with the CK (Colin Kolivas) patches), no problems w that kernel.

My question is, if I rebuild the .deb 's after installing a new kernel, should I expect that they'll build (anyone else tried this?) or bomb?

Also, if the driver won't build out of the box w a newer kernel, how much of a project is it to make it work?

Last part to this question is if I did build a new kernel & the video driver wouldn't build, I could always just boot up into the original kernel && use the driver (fglrx.ko) I built for it, right?

Thanks,
Larry

Last question first:
The answer to that is, "Yes."

If you're going to build your own kernel with the -ck patches, you can only try the various kernel source packages for fglrx and see if they work. They probably will, although I've heard that some people have problems with kernel 2.6.21 and some versions of the proprietary driver.

People who want to upgrade their Etch kernel without rebuilding it themselves should be aware of backports.org which provides upgraded kernels (among other things) for Etch. I believe they are currently providing 2.6.21.

Also, besides the current driver available from ATI, from which you can build .deb packages, you can also download and use already Debianized packages from the repositories. (Currently 8.38.6-2 in Lenny and Sid; and 8.39.4-1 from Experimental.) I prefer using those packages unless there is some compelling reason to build the ATI provided ones. I have not tried the Experimental version since 8.38.6 is currently working flawlessly on both my 32 and 64-bit systems ... with kernel 2.6.22

When the kernel went from 2.6.18 to 2.6.21, a number of minor-but-annoying things changed that caused the then-current ATI drivers to not compile; I dealt with that when building a kernel for RedHat/Fedora. I ended up backporting several macros into the new kernel source et voila. It's been a while; wasn't sure if that had been dealt with in the driver, or if other, less trivial incompatibilities had made their way into the kernel source. Guess I'm about to find out.

Thanks for that; I had never heard of that repository. I noticed that they have what seems to be a java plugin for AMD64; looks like the sun java package has been rebuilt to include a plugin for that platform (finally). Anyone know if that's true?

About the one thing I didn't see was kernels, though; I didn't see a "search" either. I need certain functionality that == rebuilding my own kernel anyway, but, for curiousity's sake, anyone know where they're located?

I also noticed that they have a newer version of kernel-package (the package that includes make-kpkg); what I didn't see was the "why" I ought to be using that version as opposed to the stock one. Anyone know where the rationale for that package, or the packages on backports in general, is?

Dammit... I specifically didn't do that as I'd been told that (a) the fglrx packages in the repositories were way out of date, which they're obviously not, and (b) not to mix and match packages from unstable && experimental && stable - which might be a good general rule, but not an absolute one, apparently.

How did you get the various pieces to put them together; I wouldn't want to add unstable && experimental to sources.list - I can't see how that wouldn't end up making a mess of things - would you mind posting some specifics as to how you went about doing that?

Thanks again
- Larry

You can add sid only temporarily. I had to do it to get the nvidia drivers to install. I Put the sources for sid in sources.list, ran apt-get update, installed the drivers and I finally disabled sid again.

This just occurred to me - if ATIs fglrx won't compile when I upgrade etch's kernel, is there any reason why running the installer like this:

sh ./ati-driver-installer-8.39.4-x86.x86_64.run --buildpkg Debian/lenny
or
sh ./ati-driver-installer-8.39.4-x86.x86_64.run --buildpkg Debian/sid
etc.

either wouldn't work, or would cause other problems?

Unless someone can think of a reason why it would mess something up, I think that might be the path of least resistance (in my case, anyway).

Thanks again,
Larry

In Debian, the kernels are named "linux-image..." (and "linux-headers...") rather than "kernel-image..."

It appears to me that you are capable of figuring out the module installation. Once you get a newer kernel installed, my recommendation would be to follow jay73's advice a above ...

Add a line for testing to your sources.list file including the contrib and non-free repos, then...
# aptitude update
# aptitude install fglrx-amdcccle fglrx-control fglrx-driver fglrx-kernel-src

Comment out (or delete) the sources.list line for testing, then...
# aptitude update

...and you'll be safely back in Etch.

Use module-assistant then to build the kernel module.

Ah, ok. Thanks.
I'm in the process of transitioning away from RedHat/Fedora after having used that distro as the basis for everything, pretty much, including our own distribution, for over 5 years; I had never planned on becoming so "distribution centric", but ...

At any rate, if it seems like I'm treading lightly / treating this with kid gloves / etc., that's why; I am - my goal here is to make as much forward progress as is possible before managing to trash whichever OS install I'm working with.

Pretty much everything I've run up against with Debian so far has been wonderfully straightforward, with one exception: packages and the module assistant. That's part of the reason I/we are moving away from RedHat; I've had it with RPM, having just had an errant package trash an installation of Fedora. The "module assistant" is the exception to the rule; or, at least, it seems to be - while I'm fairly confident that, in time, it'll be a non-issue, in the short run, for whatever reason, I just cannot seem to get the hang of it. I've written a number of device drivers, and am a lot more comfortable building and installing out-of-tree kernel modules with "make"; however, I've done that over a thousand times...

"apt-get", etc. won't trash a .conf file that already exists, right? Will dpkg or apt-get or any of the tools recognize the presence of a manually installed package and either warn or abort? For ex., if I d/l'd && built && installed xvid, which later turned out to be listed as something another package was dependent on, are the Debian tools smart enough to figure out that I already have the thing installed (like GNU automake, for example, will; usually, anyway), or will they only recognize software that they themselves have installed?
Thanks; I think I've got a fairly decent handle on it now... I'm just still not 100% on what, exactly, the package mgmt tools are up to behind the scenes, and probably won't be until I've used them for a while.

I am going to give the Debian tools a go, but if I run into anything like the problems I've had with RPM over the last several years, that's it; it's either going to get built from source or it's not going on one of my machines.

If you can think of anything I ought to know about apt, or dpkg, etc. (or anything else) please point me to a reference or otherwise let me know...

Thanks very much,
Larry

You get some sympathy from me because I started out with Redhat 6 and stuck with it through Fedora Core 4. Then one day I decided to try installing Debian on an extra machine I had sitting around, and within a month, all my systems had Debian, and I've never looked back.

That's not to say that everything on Debian is easier or works better than Fedora, but in my experience, once you learn the basics, there is no comparison in the stability and ease of upgrades.

module-assistant (m-a) simply replaces the ./configure and make routines for kernel modules that have been Debianized. In other words, they have been packaged in an official .deb package. The big advantage there is that you don't have to worry about getting each component into the directory in which Debian expects to find it. That same principle goes for all .deb packages.

.deb packages can be installed using dpkg, but there is usually no reason to do so, unless you are getting the package from an unofficial source. With 20,000+ packages in the official repos, that need does not arise often. The disadvantage to using dpkg is that it does not update the Apt history files, so Apt does not know about them. That can lead to issues that are best avoided when possible.

During package installation, Apt will generally warn you before overwriting a configuration file, but it may not do so in the case of an application that you have modified. Such applications can be protected using a technique called "pinning" or by strategic version numbering of your modified application.

Apt has two methods currently in use for package management: apt-get and aptitude. Stating point-blank that one is better than the other can start a vicious flame war, but most people do believe that one or the other is superior. I'm an aptitude person, myself.

The book, The Debian System, by Martin Krafft, is generally considered to be scripture as far as understanding just how Debian is different from other distros.

I have written a couple howtos on the Debian Forums intended to explain some of the key pieces of knowledge needed by people new to Debian, but not to Linux.

How to Have a Pleasant Installation (for Debian Newbies)
Howto: Set up and Maintain a Mixed Testing/Unstable System

You also need bookmarks on the Apt Howto and the Aptitude User's Manual.

I choose to use Aptitude strictly as a CLI tool.

Wow - terrific - thank you... That's about exactly what I needed...

That's the direction in which things are going here... To me, the beauty of the other distro - I started using it back at version two something - was that it was infinitely customizable; you weren't locked into any one way of doing things. My, how times have changed...

At the point I was forced to do things one particular, specific way - like use CUPS, for example, instead of lprng - they lost me. Whichever distro I'm using, I need to be able to take it apart, adjust it "as needed", and put it back together, with a minimum of grief. I also don't much care for pre-packaged software, and avoid it whenever and wherever I can; not having to type "./configure; make; make install" isn't a real big selling point as far as I'm concerned. That's not to say I don't understand why it's important to have, nor is it to say that I expect everyone else to want to build their own systems piece by piece. It's just not my bag.

I started using Debian about a month and a half ago when I inherited a G4 mac mini; it'd been a while since I used anything but RedHat/Fedora, so I decided to give etch/ppc a shot. I can honestly say that I've not once considered putting Fedora 7 on the thing; yeah, I had a few fits and starts getting everything going, but wow - there's nothing on it that I don't want on it; I've found Debian to be extremely configurable and I certainly don't feel like I'm locked into any one set way of doing things. In a lot of ways, it reminds me of everything I liked about RedHat 5+ years ago. Within two days, I had everything working (networking, all my peripherals, etc.) && had replaced the stock kernel with my own configuration, v. 2.6.21. By and large, I haven't had to do anything but use it since I originally set it up and configured it; it's incredibly stable, and doesn't suffer from "bloating"...

At any rate, thank you very, very much for the info; that clears up a lot. The links are terrific, too; I think I'm pretty much set now. As you pretty much guessed, there was just that one little piece of whatever that I needed to be off and running. Again, thanks.

- Larry

This is a follow-up on the question I originally asked - thanks again to rickh and jay73 for their assistance - as of yesterday, the workstation I was contemplating upgrading in my original post completed its first full day running Debian etch / AMD64 with both kernel 2.6.22 - patched and otherwise "tweaked" according to my own specifications - and ATI (now AMD)'s proprietary fglrx video drivers.

Performance is better than I had hoped; the system compiled a kernel in 28 minutes from start to finish, while running Celestia (a pretty processor-intensive 3D app), with no noticable performance lag at the command line or on the desktop (eg., I clicked the mouse, I got a response). Granted, the machine's an AMD Athlon-64 4200 x2; however, an stock install of either Debian GNU/Linux or Fedora (versions 4 and 6 tested) - and I tried this test in both x86 mode, and amd64 (x86_64 mode) - took 70+ wall-clock minutes to perform the kernel compilation.

This kernel configuration has been tested thoroughly on kernel 2.6.21 and tested - though not quite as thoroughly, as 2.6.22 hasn't been "out" as long - on 2.6.22, and is rock solid stable; it's suitable for both workstations and for servers. Three variants of it exist: x86, amd64, and ppc. The .config and patches which were used to build the kernel were developed internally over the course of almost a full year of intensive testing of various combinations of parameters, patches, etc. They've been in production use for nearly three full months now, with no reported issues or problems.

Oh yeah - the ATI/AMD fglrx driver build/install process did work "out of the box" with the 2.6.22 kernel. All I had to do was run "sh ./ati-driver-installer-8.39.4-x86.x86_64.run --buildpkg Debian/etch", install the .deb's it produced, and run m-a to build && install fglrx.ko.

- Larry