October 2010 Archives
I'm running a daily build of Debian Sid (yep, the "unstable" branch, running pretty solidly by the way) in live form from an 8 GB USB flash drive (see my entry from earlier today on how to easily transfer an .img of Debian or any other system to a USB drive).
Debian is fast. It's always been so. I've run Debian on a half-dozen different machines since I downloaded my first Etch installer in April 2007. At the time I had just started getting interested in Linux, and the release of Etch just happened to dovetail with my growing ability to grab ISOs and try them out on test machines. I eventually spent considerable time running both Etch and Lenny on both Intel (Pentium II, Celeron and VIA C3) and PowerPC (Mac G4) architectures. (I could never get Sarge onto my Sparcstation 20, not that I didn't try. I still don't have enough geek skills for that one.
Debian is great with older hardware. Whatever desktop environment you happen to run, chances are it'll run quicker in Debian. And while I've had my share of problems with the upstream components of Debian (OK, mostly Xorg ...), I can usually tap both the Debian and Ubuntu communities, as well as the unusually helpful Arch community, for tips, hints and plain ol' answers.
Now that I have a laptop that boots from USB, I've been using IMG images instead of ISOs when I can to test new Linux and BSD systems because they're so easy to deal with.
I built an IMG of Debian Sid in IMG form with the custom-build portion of the better-then-ever Debian Live site. They're in the usb-hdd/ directory when you're on the site looking for images to download.
Putting the IMG on a USB Flash driver is easy using the dd command in Unix/Linux. I got the easy instructions from the Debian Live manual, but it's just easy to turn to that most helpful of Linux distros, Arch, for easier-to-digest instructions. (I've gotten so much help from the Arch Linux community over the last couple of years — I can't thank them enough. From forums to wikis, they've pulled me out of countless jams in Ubuntu, Debian and Fedora.)
Arch's wiki has the user running the dd operation in his/her own shell. But in Fedora 13 I needed a root shell (or I could have used sudo).
First figure out where your USB Flash drive is in the /dev hierarchy. I generally do this by running the command dmesg and looking for the output that corresponds to my flash drive.
$ dmesg
This is the relevant output:
[ 6.728884] scsi 2:0:0:0: Direct-Access A-DATA USB Flash Drive 0.00 PQ: 0 ANSI: 2 [ 6.729496] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 6.732117] sd 2:0:0:0: [sdb] 15771759 512-byte logical blocks: (8.07 GB/7.52 GiB) [ 6.732623] sd 2:0:0:0: [sdb] Write Protect is off [ 6.732627] sd 2:0:0:0: [sdb] Mode Sense: 00 00 00 00 [ 6.732630] sd 2:0:0:0: [sdb] Assuming drive cache: write through [ 6.735373] sd 2:0:0:0: [sdb] Assuming drive cache: write through [ 6.735416] sdb: sdb1 [ 7.105693] sd 2:0:0:0: [sdb] Assuming drive cache: write through [ 7.105736] sd 2:0:0:0: [sdb] Attached SCSI removable disk
So my flash drive is at /dev/sdb
I've already downloaded my .img file from either Debian or whatever project happens to be offering their distributions/projects in that format.
In Fedora, as I said above, I need rootly privileges to do this. In your system you may be able to do this as a user. In this example I'm using the IMG file from a daily build of Debian Squeeze as the .img file and my particular flash drive as the target. In your case use the name of your .img and location in /dev of your flash drive:
# dd if=debian-live-squeeze-amd64-gnome-desktop.img of=/dev/sdb
In this case dd is copying a lot of bits, so it will take awhile for the job to complete.
Once it does you can reboot your machine and boot from your newly created bootable USB Flash drive running, in this case, Debian Squeeze.
It's a great way to test out new releases (or daily builds, or anything in this format) without needing to burn a CD/DVD or use an app such as unetbootin or Fedora's liveusb-creator to put an image on a USB drive. You just go straight from downloading an .img file to copying it to the drive and then booting from it. Every Unix/Linux system has dd, and it's nice to put it to good use.
Here is normal copy.
 |
| Here is a caption. |
Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy.
Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy.
Here is the entry copy. Here is the entry copy. Here is the entry copy. Here is the entry copy.
This fakery comes from here: http://blogs.uscannenberg.org/wendy_m_chapman/2009/08/easy-photo-with-caption-in-mov.html
Right now I'm testing a recent daily build of Fedora 14 via the Fedora Live USB Creator with persistent storage. Theoretically this should allow me to modify the live Fedora image on the USB and test how the release runs on my hardware with whatever fixes need to be applied in order to make things actually work.
At this point that means the fglrx driver direct from ATI/AMD, which I'm installing right now, and the creation/modification of /etc/modprobe.d/alsa-base.conf to allow for speaker muting when headphones are plugged in.
If these changes do in fact "persist" after a reboot, it makes the Fedora Live USB Creator app (available in Fedora, in case the name didn't give that one away).
Again, for those who either dislike or haven't read my extremely repetitive and continual but nonetheless evolving posts on the matter, I'm trying to get around trouble with the open-source xserver-xorg-drv-ati driver in the kernel-mode-setting era that won't work with my ATI Mobility Radeon 4200 HD chip, with KMS on or off, and the more troubling Conexant 5069 sound chip with software-enabled muting for the microphone and speaker — muting that doesn't happen to work out of the box in any Linux or BSD system (and I've tried many) but will work with some configuration in distributions that offer a full ALSA 1.0.23+ sound environment.
This is the state of things on this Lenovo G555 laptop, which I managed to buy for $329 from Fry's a few months back, and which has been running Fedora 13's Xfce spin since pretty much the beginning.
A positive outcome for this test of Fedora 14 would mean either an in-place upgrade or total reinstall of the distribution, which is scheduled for final release next week.
Overall I've been pretty happy with Fedora and would like to stick with it. Ubuntu 10.10 runs well on this hardware, too (I'm testing it on another USB stick with a "traditional" installation), but Fedora offers features that are harder (and less reliable) to come by, the most important of which is the availability of newer builds of software in the Koji Build System that can be installed and tracked with Yum (and which don't come from potentially unreliable third parties like the PPAs in Ubuntu).
Update: Adding the fglrx driver from ATI/AMD's script didn't work. Now there's no display at all, with or without KMS.
After considerable hand-wringing over the past few days in my writing about Fedora, I spent the afternoon working in Fedora 13 with Xfce. This is a very nice system, and I do have it working as well or better than I ever have during the 3 1/2 months I've been running Fedora as my main distribution.
So despite the video issues, I very well might look at Fedora 14 for this machine.
Today I booted the Debian Squeeze daily build I grabbed recently, used rescue mode to put GRUB on the root partition (instead of the Master Boot Record of my primary drive, which runs Fedora 13 and Windows 7) and booted into the Debian Squeeze installation on my 8 GB USB Flash drive.
Thus far everything is working well for the most part. I'm using Epiphany now, and Squeeze ships with Gnash, which right now is eating more CPU than it should. In my opinion Gnash isn't ready to be shipped in the default of any distribution. Better to let the user choose it than foist it upon them at this stage of development (that stage being Gnash's unsatiable appetite for CPU).
As I've noted recently, I find it interesting that at this stage in the cycle (close to release, presumably), Debian Squeeze ships with the mono-powered Tomboy Notes and the Shotwell photo archiving app (which Ubuntu is also shipping).
Squeeze includes not only Shotwell but the GIMP and Inkscape. It also includes OpenOffice and what's known as GNOME Office, the latter including Abiword and Gnumeric.
I'm running a big update right now, and I'll see how the system reacts after that.
Later: Squeeze was super slow while running from the USB Flash drive, but I did manage to test the sound situation. I couldn't get the speakers to mute, no doubt due to the ALSA 1.0.21 bits that co-exist with the 1.0.23 version of the sound system. Full 1.0.23 generally means I can get the Conexant 5069 chip to mute the speakers when headphones are plugged in. I still think I can make this happen in Debian Squeeze, but it'll take a bit of doing.
I had a bit of a problem with NetworkManager. The Debian installer never configures (or even uses) this particular network properly. I then had to force NetworkManager to actually manage the wired Ethernet interface, and every subsequent boot NM reverted to the unmanaged default, which couldn't be edited. I could subsequently change to the "good" wired configuration, but needing to do this every boot would be a pain. This is yet another thing I'm sure I could figure out ...
Video was great, probably due to Debian's conservative choice of kernel and Xorg packages. I forgot how fast the open-source ATI driver could be with my chipset.
Squeeze remains a definite possibility for my system. It's a very nice, lean implementation of GNOME, just as it's always been.
I was doing an installation of Debian Squeeze to a USB drive, and unfortunately the Debian installer was eager to drop its own GRUB on the Master Boot Record — not on the drive to which I was installing Debian but to the first hard drive on the system, which contains Fedora 13 and Windows 7.
So I had a dead GRUB on the Master Boot Record of my drive.
How to get GRUB back
For this recipe (thanks to Bob of Fedora Forums) you can't use the Fedora 13 live CD, you need either the first installation CD or the install DVD.
- Get that first CD or DVD burned to a disc, then boot from it and use the arrow keys to select "Rescue installed system."
Your computer will now boot from the live image.
You'll get a blue screen (but not of death). Wait for the system to finish booting.
You will soon be in a typical text-only install environment (ncurses, I think they call it). Use arrow keys to navigate, Enter/Return to select an option and space bar to check boxes.
- Choose your language (mine is English; no, really) and keyboard type (I picked US).
I chose not to start the network since it's not needed to restore GRUB.
- When you get to the "Rescue" menu, Continue will be highlighted. Click Return.
- My drive is encrypted, so I was prompted for the passphrase, which I entered. I used the space bar to select "This is a global passphrase," because it is in my case, then I arrowed down to OK and clicked Enter/Return.
Now you wait a bit.
- The "Rescue" menu appears again. The box says, "Your system has been mounted under /mnt/sysimage. Press
to get a shell. If you would like to make your system the root environment, run the command: chroot /mnt/sysimage ... The system will reboot automatically when you exit from the shell." Don't worry about entering these commands just yet. They'll be in the recipe below. - The OK button should be highlighted. Hit Enter/Return to select it.
- At the First Aid quickstart menu, "shell Start shell" should be highlighted. Click Enter/Return, and you will get a root shell:
- If your first hard drive goes by the designation sda, run these commands (substitute hda if that's how your systems' drives are recognized by Fedora):
bash-4.1# chroot /mnt/sysimage
bash-4.1# grub-install /dev/sda
bash-4.1# exit- Then, back in the quickstart menu, arrow down to reboot, click Enter/Return, and your system should reboot with your newly restored GRUB bootloader.
I realize that all the problems I'm having with Fedora 13's new 2.6.34.7-61 kernel are potentially (and probably actually) of my own making. I've gone outside the Fedora and RPM Fusion repositories only when I absolutely needed to do so to bring or restore functionality to my system, but that's probably what made my particular system hard to upgrade thereafter.
Think of this as a) a cautionary tale on running Fedora in production, b) a wild, geeky ride, c) sort of a learning experience (and I've got more to learn if I ever hope to make this all work correctly in the future), or d) all of the above.
Fedora is just now pushing a bunch of updates to my Fedora 13 installation, and they include an updated 2.6.34.7-61 kernel that should fix the problem with NetworkManager disappearing after resuming from suspend.
I'm going to install this and a bunch of other updates right now, and I'll test the suspend/resume vs. NetworkManager situation as soon as possible.
Now if Fedora could manage to keep the headphone-jack muting working on my sorry Conexant sound chip after a resume ... AND fix the open-source ati driver so it would actually work with my graphics chip, I'd be one happy Linux user.
It's a bit of irony, I guess, that there's no easily invoked option to encrypt the /home partition in the OpenBSD installer. I call it irony because the project is all about security and encryption, yet the developers seem to have a reason why encrypted user data isn't an option in the installer itself. Not that encryption of any given partition isn't available after the fact. It can be done, and I believe /swap and /tmp are encrypted by default. But if I can't easily figure out how to encrypt my entire /home partition, I'm at a bit of a loss in this regard. (I'm really a whole lot less geeky than I seem.)
That's why I tend to run Linux distributions on my laptops — they often provide either encrypted /home (Ubuntu's live CD) or fully encrypted LVM (logical volume management).
I'd love to run Linux Mint or Zenwalk, but they don't offer easy-to-figure-out encryption in the installer.
The Debian installer (and the "alternate" Ubuntu installer that's pretty much the same thing) offers a fully encrypted LVM option, and Fedora goes further, with LVM as the default and encrypted LVM easily invoked by checking a box.
That's what I'm running now: Fully encrypted LVM in Fedora 13's Xfce spin. Before that I had Debian Lenny with fully encrypted LVM, and before that Ubuntu 8.04 through 10.04 with encrypted /home.
To be honest, I haven't felt any performance hits in regular desktop use.
What about backups? My "compromise" with either full encryption or encrypted home is to keep an unencrypted but physically separate and secure backup. That way there's no chance of the encryption failing.
(For those who want to know, I use rsync for backups, and when I run OpenBSD or FreeBSD I rsync to a Linux filesystem, generally ext3, so I can easily restore the files to a Linux box if and when the need arises. I even use rsync on the Mac's OS X, where that OS's seeming inability to read Linux filesystems has prompted me to send the backups to a FAT partition on my backup drives. I would back up to an HFS+ partition, but I've had no luck in gParted with mixing HFS+ and anything else; the Mac refuses to read the HFS+ partitions I've created. I stick with FAT.)
I like everything encrypted, or at least /home, /tmp and /swap encrypted, because if my hardware is lost or stolen (which happens more often than we might think or admit), I know that my data is safe from prying and thieving eyes.
It's a big hunk of peace of mind. Hardware, especially the kind of hardware I have, is just hunks of plastic that's not worth worrying about. Data, however, is another matter, and it shouldn't be out there where any-damn-body can get at it.
So when I'm contemplating which operating system to throw onto my non-testing systems, the inability to encrypt my data is a deal-breaker (and yes, I'm aware that my Mac is not encrypted, and I'm not at all happy about it).
Sure, there are solutions to encrypt Mac and Windows systems, but one of the things that should drive potential users toward Linux is the ability for the average user to keep all their data encrypted.
Even though I'm actively testing Ubuntu 10.10 (installed to a 4 GB USB flash drive) and find it extremely compatible with my current hardware (Lenovo G555), I expect I'll be sticking with Fedora 13 for at least the next few months. Everything's working too well to upset this particular apple cart.
That said, things I'll be looking for include return of a working open-source ati/radeon driver (not exactly holding my breath on that one), newer kmod-catalyst packages from RPMFusion that actually work with the current F13 kernel (who knows when/if this will happen) and seeing how everything involved in this Fedora 13 build works the next time there's a kernel update (and there hasn't been one for awhile).
So far I'm not encouraged by my Debian Squeeze tests. I'm worried ALSA won't allow for the headphone jack to mute the speakers due to some ALSA 1.0.21 bits alongside the 1.0.23. It's hard at present for me to test this thoroughly — I didn't install Debian to a USB drive; instead I transferred the .img to the stick and booted it that way, as a live image, which means I can't modify the settings and have it work differently on a reboot. I guess I'll have to do a reinstall to the stick to see how things really work.
If you've done a Debian installation lately, meaning in the Squeeze era, it's sort of startling how it looks exactly like Debian Lenny. That might be a good thing, depending on your point of view. I figure there will be a new wallpaper when Squeeze goes stable, but settings-wise the GNOME desktop looks no different than it does in Lenny. If you like shiny and new and don't mind purple/orange, Ubuntu 10.10 does offer a lot more from an aesthetic standpoint.
But I'll tell you, if Debian provides more functionality in a particular situation, the stability of a Debian release is not something to be ignored. It'll generally run faster, too.
As I said at the beginning of this entry, I'll very likely spend at least a few more months in this Fedora 13 Xfce environment since it's working so very well (and I've cranked through most of the configuration-related surprises and arrived at a pretty good place audio, video and suspend/resume-wise).
I wiped and reinitialized my Mac-controlled iPod 30 GB player (circa 2005, it does play video) the other day to be controlled by an iTunes instance on a Windows PC so I could have a FAT filesystem and then ... are you still with me?? ... manage it in Linux, which really doesn't like to write to the HFS+ filesystem that Macs dump onto an iPod.
So I've been using Rhythmbox to drop stuff on the iPod, and I put a few albums encoded in the freedom-loving ogg format.
I didn't expect them to play, but they do.
I Googled for iPod and ogg, and this doesn't seem possible. So I dug a little deeper and started poking around the iPod's filesystem. You can do that sort of thing with an iPod in Linux.
At some point, I don't know where, either Rhythmbox or the iPod itself are converting the ogg files into MP3s. That's what's on the iPod: The audio files that live as oggs in my Fedora system can be dragged into the iPod in Rhythmbox and subsequently played on that iPod. Except that what I'm hearing through the iPod's headphones are MP3 audio files that somehow, somewhere were converted to MP3.
Maybe that's why it took so long to transfer an album's worth of oggs to the iPod.
Does anybody out there know what's going on?
Nobody writes much about the Debian Live Project, which went from a bunch of stable images for Intel architectures to offering stable and testing images not just for i386 and amd64 but also for PowerPC, the latter in a time when many distributions (Fedora, Ubuntu) have abandoned the Power architecture almost entirely.
Users of i386 and amd64 can also choose from monthly, weekly and daily builds of Debian Live with GNOME, KDE, Xfce, LXDE or the standard install, and there's also a Web-based utility to build a custom Lenny, Squeeze or Sid image.
Aside from the usual ISO images, there are also .img files for USB drives (don't ask me exactly how to make us of them, because I haven't yet figured that out). There is a manual for Debian Live. It's pretty geeky, but I have a feeling I'll be able to drop a live, bootable image on a USB flash drive without taking the interim step of burning an ISO to a DVD-RW and using it to install Debian Live to the flash drive, which is the way I've been doing it until now.
I'm very much in favor of live CD/DVDs with which users can try out an operating system before committing to a full installation. This is what made Ubuntu into a giant, and I probably would have never run Fedora had I not been able to see how it worked in the live CD environment beforehand. I also use Jggimi's OpenBSD live images to put that OS through its paces before deciding on a full installation. And PC-BSD's failings on my current hardware (graphics suffering just as they do in Linux with the open-source ati/radeon driver) have made me leery of a FreeBSD install on the same laptop.
Until the Debian Live Project, there was no way to do this with Debian, the distribution upon which Ubuntu is based — and which can be better in many situations (including machines on which Ubuntu either won't install or doesn't run properly).
At this point, I'm testing Ubuntu 10.10 installed to a 4 GB USB flash drive, and every thing is working perfectly. I'd like to do the same thing with a daily build of Debian Squeeze, and one way (.img file copied to a USB drive) or the other (traditional ISO installation to the same USB drive) I will do just that.
While on the subject of my next distribution, I'm still running Fedora 13 x86_64 with Xfce. I've figured out just about every issue (sound and video now working well) except for headphone-jack muting of the speakers dying upon resume (as does NetworkManager, but I know how to get that service back up and running).
Since I've never made extensive use of suspend, this isn't a deal-breaker, but it's nice to know there's a distribution (Ubuntu 10.10) or two (can Debian Squeeze do this just as well?) that go ever further in hardware compatibility for my Lenovo G555 laptop (AMD Athlon dual-core 2.1 GHz CPU, ATI Mobility Radeon 4200 HD graphics, Conexant 5069 audio, 3 GB RAM).
Now that I definitively know how to make the graphics work (using the proprietary fglrx driver in post-kernel-mode-setting OSes) and speakers mute properly when headphones are plugged in (ALSA 1.0.23 is essential, as is the proper config line in /etc/modprobe.d/alsa-base.conf), I can recommend the often-$329 Lenovo G555 as a good cheap-laptop alternative for use with Linux. I can also recommend it for OpenBSD now that I know how to get the wired Ethernet port working.
Hopefully these hacky solutions for the Lenovo G555 will fade away in the near future as the Linux kernel, Xorg, ALSA and distro worlds figure out how to make this stuff work automatically; just the same, I bet the alc driver for FreeBSD and OpenBSD eventually works without tweaking the media settings on this Atheros AR8132 network interface.
I didn't want to do it, but I had to move from the 2.6.33 kernel to 2.6.34 to make both sound and video behave properly in Fedora 13 on my Lenovo G555 laptop with ATI Mobility Radeon 4200 HD graphics and Conexant 5069 sound.
In order for the "standard" fix to work for sound, I needed 2.6.34 and the full ALSA version 1.0.23 to go with it. Unfortunately, I had to get the missing ALSA bits — meaning the ALSA-driver — from another repo, as they're not in Fedora 13's official repository (and seemingly not needed to have working ALSA for reasons that continue to elude).
Also unfortunately, the fglrx proprietary ATI driver from RPM Fusion is super slow, and I used the "hotfix" script directly from ATI to install the driver. Performance is better than the fglrx in RPMFusion but slightly worse than the open-source xorg-drv-ati in Fedora 13. But since I can't get anything but blurry and wavy video from xorg-drv-ati in 2.6.34 with KMS on or off, and I couldn't get the ALSA 1.0.23 driver without moving to that kernel, the quest for muted speakers when headphones are plugged in led me to the kernel/video/sound upgrade.
All in all, I'd prefer all of this to be done within the distribution itself, or at the very least via the RPM Fusion repository's non-free section. But it just wasn't happening. a href="http://download1.rpmfusion.org/nonfree/fedora/updates/13/x86_64/repoview/kmod-catalyst-2.6.34.6-54.fc13.x86_64.html">RPM Fusion is still behind Fedora 13 on kmod-catalyst, and I'm still getting errors like this in the boot messages:
Checking kmods exist for 2.6.34.7-56.fc13.x86_64 [ OK ] Ignoring catalyst-kmod as it failed earlier [WARNING] Hint: Some kmods were ignored or failed to build or install. You can try to rebuild and install them by by calling '/usr/sbin/akmods --force' as roo t. Checking for module fglrx.ko: [FAILED] fglrx.ko for kernel 2.6.34.7-56.fc13.x86_64 was not found. [WARNING] catalyst DRI will not be enabled until one is found. [WARNING]
I did try to force this upgrade, but since the kernel in Fedora 13 is 2.6.34.7 and the kmod-catalyst package is built against 2.6.34.6, it didn't work.
I thought the lack of fglrx.ko was the reason for the slowness of the driver from RPM Fusion, but with the "hotfix" method of installation, video from the proprietary ATI seems much faster (though fglrx.ko remains AWOL).
I'd much rather be running the open-source ATI driver (xorg-drv-ati in Fedora), but as I mention above (and repeat here because I'm a lazy editor), it's pretty much broken now that kernel mode setting is here for ATI. With or without KMS, video is blurry and wavy. The workarounds are to remain with the ati/radeon driver in 2.6.33, or use the proprietary fglrx/catalyst driver in 2.6.34. Ubuntu 10.10 also requires the proprietary driver for this video chip, but it's easy to install, and performance seems better than even this "fixed" fglrx installation in Fedora 13.
There is a detailed solution involving the "hotfix" and a newer kernel on the Fedora Forums, but it's way too complicated for me. I just ran the "hotfix" script as root, and things improved enough to keep me happy for the time being.
I hate doing this kind of thing. I really prefer to stick with the "official" repositories and maybe a single "nonfree" repository just to keep things from spinning out of control.
Eventually I hope to run the following and actually have it work:
$ sudo yum install kmod-catalyst
That should stop the kernel warning messages from appearing every boot.
Again, I can't say enough that I'd much prefer to use the open-source driver. This is looking more like a rabbit/rat-hole with every off-the-reservation tweak. Still, it is working — for now, anyway.
Anyway, let's get to sound. The problem I've been having with the Conexant 5069 chip in this Lenovo laptop is that plugging in headphones does not mute the speakers. That's a problem.
To fix this, you need the following (in 64-bit Linux anyway):
- Install alsa-driver-1.0.23-84.fc13.x86_64.rpm from ATrpms
- With root privileges, create /etc/modprobe.d/alsa-base.conf and add the following line:
options snd-hda-intel model=thinkpad
This only works with the 2.6.34 kernel (meaning it won't work with 2.6.33). Boot into the "new" kernel with these fixes, then start a sound application and plug in headphones. You should hear sound from those headphones and not from the speakers.
I can't begin to explain this, but (again, as I mention above and keep here due to lousy editing) for some reason there is no alsa-driver package in stock Fedora 13. Or at least I couldn't find one in the Fedora repo. As a result, even with everything in stock Fedora 13 updated to ALSA 1.0.23, the output of /proc/asound/version continued to be ALSA 1.0.21 — not enough to get this done.
Adding the alsa-driver package from ATrpms, creating /etc/modprobe.d/alsa-base.conf with the line options snd-hda-intel model=thinkpad AND using 2.6.34 were what needed to happen to get the headphone jack to work properly.
And that's what prompted me to go back to the fglrx video driver. I was sticking with 2.6.33 and the open ati driver just so I could get that cool boot screen that goes away with turning off KMS in 2.6.34, and since the open driver won't deliver usable video for this ATI chip, I felt that a little potential video pain and proprietary bits were worth it in exchange for the "privilege" of muting the speakers when using headphones.
My coworkers will thank me, since starting today they won't have to hear the output when I'm editing podcasts with Audacity in Fedora 13.
I'm unsure enough about the video situation in Fedora that I will eventually be moving on to another distribution. I based the solutions to my video/audio problems in part on solving those same issues in the new Ubuntu 10.10, where the proprietary video driver is likewise required for this video chip to be non-blurry/wavy, as is the line in /etc/modprobe.d/alsa-base.conf to properly mute the speakers. But video performance seemed faster, and that might carry the day.
If/when I do leave Fedora, I'll miss the ability to install newer versions of apps directly from the Fedora Build System, which I trust more than all those PPAs in Ubuntu. The Fedora Build System was my source for gthumb 2.11.90 (it's now up to 2.12, but I'm holding steady with 2.11.90 due to its working flawlessly). Ubuntu still has 2.11.5, I believe, which has some bugs that directly affect my work in the application.
I continue to believe that grabbing bits from here and there to make a Linux distribution work properly weakens the entire system. It makes updates difficult and can really hurt stability. I had to do it to make everything work right in Fedora 13, but it's not something I like to spend my time on.
I still continue to enjoy working in Fedora 13. My one remaining issue is losing networking when bringing the laptop out of suspend. Maybe 2.6.34 will improve that situation. I'm sure you're all dying to know, aren't you?
The next day: A short suspend/resume doesn't seem to have much in the way of ill-effects, but a longish suspend/resume mucks up NetworkManager, killing networking, and kills the ability to mute the speakers when headphones are plugged in.
Short of rebooting, the NetworkManager situation can be remedied in a console:
# service NetworkManager restart
I'm thinking of putting that line in the resume script if I can figure out exactly where it's living in the system.
I haven't figured out a fix for the sound, but I imagine it's a similar variation on "stop, then start this service," whether it be ALSA or PulseAudio.
At this point the solution is not to use suspend/resume, which I can live with.
While some users of the Lenovo G555 laptop and its Atheros AR8132 Ethernet interface report no trouble with networking in OpenBSD using the alc driver (courtesy of FreeBSD) that made its debut in version 4.7 of the operating system, that wasn't the case for me.
The wired Ethernet interface shows up in the dmesg as alc0 but doesn't "light up."
I've since determined with the jggimi live CD of OpenBSD 4.7 and an install on a 4 GB USB flash drive of OpenBSD 4.8 from snapshots that I must specify the media type to make the interface "light up" and go from "no carrier" to ... carrier, I suppose you call it.
In the OpenBSD configuration file /etc/hostname.alc0, I have the following:
dhcp media 100BaseTX mediaopt full-duplex
I was told in the Daemon Forums thread I started that it shouldn't be necessary (nor is it desirable) to specify media type, but this is what worked. I'm not sure whether or not I need the "mediaopt full-duplex" part for my network, but it is working.
After beating my head against the wall over the problem (meaning many unfruitful Google searches) I got the idea from a search for the alc driver on the FreeBSD Forums. That got me 80 percent of the way to figuring it out. Then I saw how it was done in OpenBSD in this portion of the FAQ.
Before I continue, let me say how cool it is to have a laptop that boots from USB. Why I waited until this particular moment to try loading full operating systems onto 4 GB flash drives I can't say. It might have something to do with my finding a spare 4 GB flash drive in a pile somewhere. Hell, I remember running a 80386 SX 25 MHz PC with something like 2 MB of RAM and an 80 MB hard drive. Now we (meaning me) find 4 GB flash drives mixed in with the pens, sticky notes and piles of newspapers.
Back to OpenBSD and the vicissitudes of the Lenovo G555's Atheros NICs and ATI video:
I can also confirm that OpenBSD 4.8 does nothing to harm the perfect video I'm getting out of OpenBSD 4.7 on the Lenovo G555's ATI Mobility Radeon 4200 HD video chip, which isn't playing well with the open-source ati driver and post-2.6.33 kernels in Linux (which tends to bring kernel mode setting into the picture).
I've unfortunately had similar video trouble in PC-BSD 8.1.
The installation of OpenBSD 4.8 to the USB key went without a hitch, and it was easy thereafter to fix the networking for the alc driver.
I tried to install FreeBSD 8.1 to the same 4 GB USB flash drive but ran out of room midway through. This was with documentation but no additional applications. The fact that a full Ubuntu distro will fit on the same key (more on that later) says something about all of this.
But never mind that. The takeaway from this little experiment is that OpenBSD 4.8 remains a very viable alternative for my Lenovo G555 laptop (AMD Athlon II dual-core 2.1 GHz CPU, 3 GB RAM), the torments of kernel mode setting in Linux be damned.
I've had trouble. It's no secret. It's all over this blog. Some have even complained about my complaining. Just give me a working system with no showstoppers and I'll sing sweetly about your distribution/project/fantastical machine.
Getting a new laptop — and I'm a person who doesn't buy anything new (and usually plain doesn't buy anything at all, getting perfectly good machines from others trash) — has been more painful than it should be in Linux and BSD over these past few months. Wasn't it my old hardware causing all the trouble? Wouldn't the latest and greatest (OK, the least expensive latest/greatest) solve many problems instead of create them?
Nope.
I decided to run Fedora 13 as my first Linux distribution on this Lenovo G555 laptop, and things seemed to be going exceedingly well. Video was perfect, and certainly I'd be able to figure out why plugging headphones into the headphone jack didn't mute the speakers and instead sent sound to both speakers and headphones. It couldn't be that hard to figure out, right?
Well, it's been months, and while I've been very happy with Fedora and learned a lot (as one must after years in Debian-derived apt-based distributions). But then things started to crumble a bit. In the 2.6.33 kernel, all was well, but with updates entering the Fedora 13 ecosystem from all sides, first my video went south in the 2.6.34 kernel (why Fedora is changing kernel versions in an existing release, that's a question all right), and the only way to get the blurry/wavy to go away was either the fglrx driver (which for some reason was slower when it was supposed to be faster) or sticking with the open driver and the 2.6.33 kernel (which one has to go to some [but very little] pain to keep around in Fedora's three-kernels-for-every-boy/girl world). I chose the latter, and to this day I still have the final 2.6.33 kernel. Too bad the rest of the system seems optimized for 2.6.34.
One of my favorite tech writers, Bruce Byfield, puts the whole "Is Ubuntu doing the right thing" debate into fine perspective in his Datamation article, Ubuntu's real contribution to free software.
He points out that Ubuntu isn't Red Hat, and that while the latter contributes to desktop development despite not having much of a dog in that fight (commercially speaking), Ubuntu is really pushing for more desktop users and a better desktop experience. And in his mind (mine too), that most definitely counts for something:
... if my memories are correct, Ubuntu can claim a long string of firsts on the desktop. I believe that it was first major distribution to place the menu at the top left, where the eye falls on it first, instead of imitating Windows and placing it on the bottom left. Ubuntu was certainly the first to make tools for switching to multiple keyboards part of the standard installation -- or to add the fonts needed to use different layouts.More recently, Ubuntu has incorporated more detailed help into the shell and into desktop applications. It has also introduced tools for managing software sources and updates as well as (in a triumph of pragmatism over ideology) restricted drivers. Once you start tallying, the list of Ubuntu's innovations quickly becomes a long one.
Just as important, behind these practical improvement has been Shuttleworth's constant discussions of interfaces and usability. You might think that Shuttleworth's challenge a couple of years ago to equal or outstrip Apple tinged was by jingoism or that his enthusiasm for Ubuntu's latest color scheme makes too much out of too little -- and, at times, I would have to agree with you.
Yet the point is that, by talking about usability and interfaces, then backing up the talk with concrete options, Shuttleworth and Ubuntu have made the free software community aware of these issues in a way that it had not been before.
Byfield acknowledges and at times details Ubuntu and SABDFL Mark Shuttleworth's missteps, which are regretful but not enough to blot out the rest of what the distribution is doing for the cause of spreading free, open-source software to new, non-fanboy users.
Now that thing are somewhat stable in the "hates kernel mode setting" world of Intel i810 video in Linux (sort of), and I've moved on from 2002-era hardware to 2010-era hardware in the form of a laptop with ATI Mobility Radeon 4200 HD video, my problems with the evil evilness that is kernel mode setting should be over, right?
Not so much.
The Lenovo G555 laptop (purchased a few short months ago for the bargain price of $329) that ran so well with Ubuntu 10.04 and Fedora 13 (with 2.6.33, not 2.6.34) and the open-source ati driver (and now sluggishly with the proprietary fglrx driver in 2.6.34 with KMS turned off) is pretty much unusable in the betas for Ubuntu 10.10 and Fedora 14 (and many other distributions I've tried).
So I upgrade my hardware and am almost immediately right back in KMS hell?
I'd like to know what's so great about kernel mode setting for the rest of you that it's had to cause me such pain on not one but two video platforms.
And whose fault (and it is SOMEBODY's fault) is this anyway? Does the pain come from the kernel, Xorg, the video driver, or somewhere else?
All I know is that this is a lousy way to treat any segment of users.
And no, with the open ati driver, passing nomodeset or radeon.modeset=0 at the boot line is NOT working (although that is what makes the fglrx driver work; too bad I can't drag a window across the screen using this proprietary driver without it taking three times as long due to video lag; and why wouldn't I want to stick with the open-source driver anyway?).
I've opened some bugs on this, but until somebody — or a lot of somebodies — with this particular video chip make a lot of noise or actually possesses the skills required to single-handedly and -mindedly code their way through this situation, it seems those of us who do have this hardware will be forced to:
- Stay in the releases that aren't affected (Ubuntu 10.04, Fedora 13 with 2.6.33, and Debian Squeeze so far; among those I've tested anyway)
- Suffer with fglrx (which is supposed to be faster but on my hardware/software is somehow is much, much slower)
- Go back to Windows (where even the sound issues of the crappy Conexant 5069 in the Lenovo G555 are dealt with; all of Linux and BSD can't seem to mute the speaker when something's plugged into the headphone jack; and again, I've filed bugs and tried the various workarounds, none of which have any effect in Fedora 13 ... and yes, I do blame the hardware vendor, but that gets me exactly nowhere).
Here I go again. Complaining. Yep, I'm not a developer (and in the minds of many that makes my complaints go directly to /dev/null). You got me there. To avoid these kinds of problems, we all should buy Linux-running laptops preloaded from those companies that sell them. ZaReason, you have my future PC-buying business, for sure. But in the case of the Lenovo G555, $329 was a price I couldn't pass up. ...
I hope the video and even the audio issues on my machine will somehow be solvable in the next year (and as usual, whichever distro makes this possible/doable/easy is the one I'll be using on this laptop).
(end rant ...)
The topic, "Should I try OpenBSD/FreeBSD?" came up recently on the Fedora Forum, and while I answered there, my answer is sufficiently long-winded enough to spin into a blog post here:
I've done quite a bit of experimenting/learning with BSDs over the past couple of years, and I definitely recommend that Linux users set aside a box, do some installs and take some time to configure and use BSD.While I've run both FreeBSD and OpenBSD as desktops, I've spent most of that time with OpenBSD, which was my main desktop for six months. I had a machine on which I was having CD-ROM issues, which I later solved, but at the time OpenBSD 4.4 was fairly easily installed from a single floppy (yes, I installed an OS in 2009 from a floppy disk), and I was able to build it up enough to get most of my work done on it.
I recently returned that particular laptop to OpenBSD 4.7 and am playing around with it.
I did run FreeBSD 7.3 and 8.0 on it before that. With the customary varying degrees of success.
The documentation of the BSD projects (and I'm talking here about Free-, Net-, Open-, and DragonFlyBSD) in the form of huge FAQs and comprehensive (and way better than Linux) man pages make the BSDs great platforms to learn Unix and how Linux/Unix systems go together.
In both OpenBSD and FreeBSD, getting things to work like they do in Linux often takes extra configuration, and in the process you learn more about what goes on "behind the scenes" in a way you don't often need to in the average Linux distro.
I now know a lot more about things like CUPS, and how Thunderbird, Firefox, GNOME and Xfce work solely because everything isn't done for you like it is in distros such as Debian, Fedora and Ubuntu.
But now I run Fedora as my main desktop. It's not as easy or quick to get a desktop together, nor to maintain its applications in FreeBSD or OpenBSD. And there are problems with things like Flash (you can't go past version 7 in OpenBSD, and that's with Opera and in i386 only, and while Flash 10 works in FreeBSD, it's nowhere near as smooth).
But if your needs are met by what one of the BSDs have to offer, or you have a particular itch to scratch, I'd say give as many BSDs a try as you want.
I do agree with the idea of trying PC-BSD. That way you get a full desktop, the convenience of PBI packages, less building of ports (the thing I hate most about FreeBSD is that it's really oriented toward ports, and updating every port on your system can take many days), but you can pretty much do all the FreeBSD things with ports if you want to.
After using OpenBSD for a few years running just the standard releases, I finally figured out how to download the kernel and system source and run the periodic patches that keep the system at -stable instead of -release. And FreeBSD now has a simple binary update mechanism to do the same thing.
Applications are a different story: With the exception of PC-BSD and its PBIs, you pretty much have to give up the Linuxian notion of continual binary application updates. In OpenBSD they update the application packages with the project itself every six months. The only way to keep everything "current" is to run -current, which most hardcore OpenBSD users do. Then you build everything from ports and can update them periodically.
Just like in OpenBSD, there are FreeBSD packages for just about everything, but for FreeBSD I was never able to get a handle on just what its updating policy was. FreeBSD also has -release and -stable branches, but there's also more than one release at a time, and it gets complicated.
My FreeBSD 7.3 box running GNOME was going along fine until I tried to upgrade it. I did a ports upgrade, and after three continuous days I couldn't take it anymore. I stopped the upgrade and tried to save the install, but the whole thing pretty much blew up.
I'll chalk it up to operator error. At some point I'll try FreeBSD again.
I threw OpenBSD 4.7 on my test machine recently because I'm just more comfortable with the way the project works. I like the default install, quirky as it is with things like Fvwm2 as the default window manager (and X in the default install, while FreeBSD's base doesn't include it) and a highly modified Apache 1.3 in a chroot.
If you're thinking about running a BSD, start at the project websites. Download and read the FAQs — FreeBSD's is about 1,000 pages. That'll keep you busy. Read the forums and mailing lists (I use http://marc.info to keep an eye on OpenBSD's lists), and start experimenting with installs (a dedicated test machine or two helps; I haven't yet explored VMs, so that's how I do it).
At the very least, running a BSD adds greatly to your perspective of open source in general and Linux in particular. Seeing just how portable (or not) the applications we run in Linux are is, in my opinion, a very good thing to do.
Links
Those of us who write for the insular world of the open-source-software enthusiast don't often think about how the rest of the planet looks at Linux and other free software.
Courtesy of Sean Michael Kerner's Internetnews.com article, Red Hat Linux is Mad Money, here is a video from CNBC "Mad Money," hosted by dog-and-pony, literal-bells-and-whistles purveyor Jim Cramer interviewing Red Hat CEO Jim Whitehurst about how and why the company does what it does and is so successful in the actual doing of it.
Note Cramer's question on why Red Hat isn't a desktop player (even though Red Hat Enterprise Linux indeed has a desktop product) and Whitehurst's answer that desktop software should be free and costs exactly that much in the form of the Red Hat-sponsored Fedora Project.
If you've read this blog with any frequency, you'll know I've been running Fedora 13 as my main desktop for the past few months after a few years that were heavy with Debian/Ubuntu in that role.
About this blog
Recent Comments
Monstra on CMS and blog software without databases: Monstra CMS is the best flatfile CMS ever! (!) Easy to install, upgr ...
Chris on Running OpenBSD in a live environment with MarBSD-X : Jggimi isn't developing his images anymore. If you want an updated Ope ...
Peter Ljung on Review: DragonFlyBSD 3.0.1 -- the longest DragonFlyBSD review ever -- Part 5: Comparison to OpenBSD 5.0 and closing comments: I have also been fascinated by the Hammer file system and think it wou ...
Anonymous on Review: DragonFlyBSD 3.0.1 -- the longest DragonFlyBSD review ever -- Part 2: My BSDistory: Can you just get to the actual review? ...
Bill Callahan on SugarSync is working on a Linux client, but I'm not unhappy at all with Dropbox: I've been very happy with SpiderOak. It has a native Linux client as w ...
AJ on Debian Stable -- set it and forget it -- spoils me for fresh Linux Mint 12 on some very nice ZaReason hardware: Gnome 2 is still standard in the upcoming SolusOS (Currently at RC 2). ...
Niki Kovacs on Debian Stable -- set it and forget it -- spoils me for fresh Linux Mint 12 on some very nice ZaReason hardware: Since I've moved to Debian stable - with a few tweaks - I've not only ...
Earl on Debian Stable -- set it and forget it -- spoils me for fresh Linux Mint 12 on some very nice ZaReason hardware: I use Mint 12 and LMDE based on Debian testing. Both are plagued by G ...
Alan Rochester on Debian Stable -- set it and forget it -- spoils me for fresh Linux Mint 12 on some very nice ZaReason hardware: "mint does have a separate xfce edition afaik.." The Debian version o ...