Why I’m using the closed Catalyst driver for Linux instead of the open Radeon driver

I’ve been using Fedora Linux for the greater part of this year, starting with F18 and upgrading via Fedup to F19. For most of that time, I’ve used the closed-source AMD Catalyst driver as packaged by RPM Fusion instead of the open Radeon driver that ships by default with Fedora and most every other Linux distribution.

I’m not proud of it. But the differences in performance are too big to ignore.

Things that stink with both drivers: Neither the open- nor the closed-source driver will resume my HP Pavilion g6-2210us laptop after suspend. (The machine uses the AMD A4-4300M APU with AMD Radeon HD 7420G graphics.)

Things that stink with the open driver: Only the Catalyst driver delivers working 3D acceleration, meaning without it I can’t run GNOME 3 at all, most games look like hell, and a certain wonkiness crops up here and there on various web pages.

With Catalyst, my glxgears frames per second are 100 times greater than with the open driver. I don’t know what glxgears fps numbers really mean, but 5,200 has got to be better than 50.

Things that stink with the closed driver: In Xfce, many application windows have lost the borders on the left and right sides. I can’t explain it.

I also cannot successfuly use UEFI secure boot with the Catalyst-enabled kernel, though I can do so without Catalyst installed. It’s not Secure Boot itself that is stopping the boot. It just hangs at some point — after some IP tables lines in the dmesg, I think. The solution is keeping EFI but turning off Secure Boot.

When Xubuntu and Debian fail, Fedora it is for HP Pavilion g6-2210us laptop

I’ve spent just about a month with this new HP Pavilion g6-2210us laptop that shipped with Windows 8. That means UEFI and Secure Boot.

And new hardware. We all know how difficult Linux can be with new hardware.

During the aforementioned month, I did a lot of work in Windows 8. I sent up my whole environment. Even installed Perl. And Python. (It’s not like I’m a big-time hacker or anything, but I aspire.)

But it’s time for me to get back to Linux. Except that I’m having issues.

Video: EFI in Debian with Steve McIntyre at DebConf 2012

Kilt-wearing Debian Developer (and former Debian Project Leader) Steve McIntyre talks about the state of EFI in Debian in this DebConf 2012 video.

I have done an EFI installation of Debian Wheezy, and while the installation was ultimately not successful, the EFI part went smoothly.

Given that pretty much all new PCs will ship not only with EFI but with Secure Boot, it’s vitally important that Linux handle EFI — and handle it well.

I’m not sure what the state of Secure Boot is in Debian at this point. I know that Secure Boot did not make it into Wheezy, though there’s some kind of solution where you enter your own key (a solution I know nothing about).

Let me just say that UEFI is both the present and the future, and any operating system that wants to stay relevant in the coming years needs to support it.

Holy crap: Xubuntu 13.04’s Secure Boot fail and Fedora 18 with Xfce’s Secure Boot success

I still can’t believe it.

I’m testing distros on my HP Pavilion g6-2210us, which has optional Secure Boot for Windows 8, and I’ve run into a huge problem.

Xubuntu 13.04 boots from a DVD just fine with Secure Boot switched on. The image has no problem booting to the live desktop and doing the install.

But when I reboot into my new Xubuntu system on the hard drive, the kernel (or whatever else is involved) won’t validate, and the system won’t start. The only thing I can do is go into the laptop’s setup and turn off Secure Boot.

This is the Beta 2 image. I don’t know if there was a fix before the final release yesterday, but not being able to start an installed distro with Secure Boot is a pretty huge bug. Even though 3D video performance is extremely poor at this stage for this hardware, I’m downloading an Ubuntu 13.04 final ISO to see if the bug persists in Ubuntu proper.

I confirmed that it wasn’t my hardware by installing Fedora 18 with Xfce from live media. The ISO booted fine, the install went fine (even though the new Anaconda is more awkward than not), and the system started right up upon reboot. With Secure Boot enabled.

I’m doing a huge update right now in Yum Extender, an application I’ve never heard of before. But it’s not a bad GUI front end for Yum. You get a whole lot more information on the screen than with PackageKit in GNOME.

If I can get Skype running in Fedora 18, this is pretty much a done deal.

And a working (and working-under-Secure Boot) Fedora system is a powerful incentive not to screw with what sure looks like success.

Linux on the HP Pavilion g6-2210us — today’s tests: Debian Wheezy and Xubuntu 13.04

I swapped an old hard drive into the HP Pavilion g6-2210us and gave a few Linux distros a spin today.

Why a separate drive? I’m not at all confident about a successful Linux-Windows 8 dual boot. For those keeping score, this laptop features an AMD A4-4300M APU processor with AMD Radeon HD 7420G graphics. The wireless NIC is by Atheros, and the wired NIC is a Realtek. (I’ll report later on specific NIC chips for wired and wireless Ethernet.)

First up was Debian Wheezy. I had to turn off Secure Boot because Debian doesn’t support it. That was no problem. You can toggle Secure Boot on this HP Pavilion g6, and you can also toggle UEFI and “legacy” BIOS mode. So really I’m only limited by what “works” with the hardware itself. Given my angst lately over video (no GNOME 3 due to shaky 3D acceleration support for this newish AMD chip), that’s cold comfort.

Debian seemed to install perfectly. Except that, early in the install, it wanted me to supply nonfree firmware for the wired networking port (a Realtek NIC) on removable media. I actually got the nonfree .deb package (all Wheezy firmware is here, unpacked it and put the required files on a USB flash drive (formatted as FAT), plugged it in and continued with the install. That didn’t work. Debian didn’t “see” the firmware.

Give what happened later (the laptop stalled during boot), this was strange because the system continued installing from the netboot image — using that very NIC to download all of the required files.

I knew I would have trouble with the 3D acceleration in GNOME 3 (and I later confirmed that the proprietary 3D driver for ATI/AMD does not work on this video card), but I was doing a test install and could always bring in Xfce later.

That wouldn’t matter.

I did the entire installation. But as I hinted above, Debian Wheezy wouldn’t reboot into the new system. It hung during configuration of the wired Ethernet port. I guess I can try again with install media that includes the nonfree firmware.

Later: I did look at the installation guide for Wheezy, where I saw that you need to leave the firmware in .deb package form. I also found install images with the firmware included.

Next up was Xubuntu.

The install went fine with Secure Boot turned on. But on reboot, I had to turn off Secure Boot to get the system up and running. It could have had something to do with the fully encrypted LVM option that I chose during the install. I’ll have to do an install without encrypted LVM to see if it makes a difference in Xubuntu’s ability to run with Secure Boot enabled.

Everything looked good once I was in the system. I installed a boatload of updates. I brought in Skype with the service’s own .deb package. I managed to get audio working in Skype. But upon reboot it was not to be. The audio left Skype, as did the configuration options I had to choose from to make it work in the first place. it might come back on the next boot. Who knows?

Unfortunately I need Skype to work at the moment. I never had such trouble in Debian Wheezy on my now-dead Lenovo G555. Until it died, that is.

Otherwise I was happy with audio. That was a major concern of mine. However, I was able to boost audio levels with the Pulse Audio Volume Control, and audio was every bit as good as it is in Windows 8.

Alas, the day’s experimenting had to come to an end. I swapped back in the Windows 8 hard drive, re-enabled Secure Boot and had a working Win 8 system once again. Yep, it’s as exciting as you thought it was.

Secure boot and restricted boot in the eyes of Matthew Garrett

One of the most important people in the Linux world regarding secure boot is Matthew Garrett, recently of Linux giant Red Hat, now with Nebula, who writes about the nuances between secure boot and restricted boot in this post.

Here is a meaty quote:

The x86 market remains one where users are able to run whatever they want, but the x86 market is shrinking. Users are purchasing tablets and other ARM-based ultraportables. Some users are using phones as their primary computing device. In contrast to the x86 market, Microsoft’s policies for the ARM market restrict user freedom. Windows Phone and Windows RT devices are required to boot only signed binaries, with no option for the end user to disable the signature validation or install their own keys. While the underlying technology is identical, this differing set of default policies means that Microsoft’s ARM implementation is better described as Restricted Boot. The hardware vendors and Microsoft define which software will run on these systems. The owner gets no say.

And, unfortunately, Microsoft aren’t alone. Apple, the single biggest vendor in this market, implement effectively identical restrictions. Some Android vendors provide unlockable bootloaders, but others (either through personal preference or at the behest of phone carriers) lock down their platforms.

I’m no expert on UEFI or secure boot. I do know that the traditional BIOS has had its day and then some, and for that reason I believe that UEFI is a step forward that we should all welcome.

The whole secure-boot part of the equation is more troubling, since it’s Microsoft in control of the keys — literally — and it seems both complicated and cost-prohibitive to strike out on one’s own with secure-boot keys.

That’s where guys like Matthew Garrett come in: He was untangling this for Red Hat and hopefully will continue to do so — and to keep us up to date in his blog.