Tag Archives: Secure boot

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.