TCLP 2012-02-12 Switching My Wife Back to Linux

This is a feature cast, an episode of The Command Line Podcast.

If you are going to be in the North Eastern part of the US in March, check out North East Linux Fest and LibrePlanet. Thanks, Jonathan, for pointing these out to me.

Listener feedback this week is from Lachlan and Steve both of whom wrote in response to my feature on hackish assumptions. Lachlan also questioned why hackers should cultivate some awareness of public policy. Steve is in favor of my proposed talk for Ohio Linux Fest. I hope to have a beta of the talk at Balticon in May.

The hacker word of the week this week is footprint.

The feature this week is the story of how and why I switched my wife back to use Linux full time..

View the detailed show notes online. You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.u

Impressions of the Archos 43 Internet Tablet

On Monday, I finally received the Archos 43 internet tablet I ordered from Amazon back in the middle of October. The device is Android powered and primarily intended as a personal media player. I picked it because it is an excellent price for the specs which include a 4.3 inch screen, 16GB of internal storage, a micro-SD card slot, and a 2 megapixel camera. It sports a 1Ghz ARM chip with an integrated DSP so also is a nice speed bump over my two year old iPod Touch. My requirements are very specific and sadly seem unusual. I do not want a phone (I hate the interruption factor), but want a screen size that is almost exclusively used in phones. I want something that will easily fit in a jeans or coat pocket, so definitely not a seven or ten inch tablet.

Specifically I wanted an Android based personal media player (PMP) or mobile internet device (MID) to be able to severe my last tie to Apple’s proprietary software ecosystem. I’ve documented the process of installing Linux for everyday use on my Mac Pro. I have been itching to install Linux on my Macbook Pro. With a substantial iTunes library and the idiotic proprietary sync mechanism of the iPod, my laptop has been relegated to an iPod peripheral. I actively avoid using it out of the sheer frustration arising from losing OS X muscle tone and my newly ingrained Linux reflexes constantly leading me to tap the wrong booster keys and generally fumbling the Apple interface conventions.

The Archos PMP/MID devices all are capable of mounting as mass storage devices over USB which works with all the popular desktop OSes. No need for any proprietary anything to get my music library onto it. I can simply use rsync if I want an exact copy of my main music library mirrored to my portable device. Of course, I can also use a file manager, music buying and sharing apps, and network storage services like DropBox to manage my media collection even more powerfully if I want. Like using Linux on my desktop, the move to Android provides a lot more possibilities.

After several days, I’ve got a good sense of the drawbacks and benefits of this new device. My iPod Touch is currently cleaning itself out preparatory to handing it down to my wife. My Macbook Pro is busy copying my iTunes library to my Linux desktop where I will sift through it deciding what to pull into Amarok and onto my Archos. All of that is simply to say that on the whole I am very happy with the Archos, with only a couple of qualifications.

Costing only 250 USD it is clear where Archos cut costs with the 43 IT. The performance of the touch screen is inconsistent. Some times it works very smoothly, as smoothly as my iPod Touch. Other times it freezes for several seconds, being utterly non-responsive. Another portion of the time, it simply mis-registers touches, double tapping or tapping somewhere else on the screen. This is frustrating but not enough so that I am looking to return the device. Most of the time, it simply sits in my pocket or on my desktop, playing media. The flaky screen is irksome when pushing status messages out to my social network but to be honest, the tiny onscreen keyboard and inconsistent landscape support under iOS was just as frustrating. I am hopeful that the problem is software and will improve with firmware updates from Archos.

Speaking of the firmware, the device did not arrive with FroYo, Android 2.2 as advertised. There is a footnote, now that I double check, and some clarification in the support section of Archos’ site. The device is FroYo capable and a new firmware build based on 2.2 is scheduled to ship this quarter. Looking at past firmware updates from Archos, they clearly invest extra effort to polish the Android builds to work better with their hardware, an effort I appreciate. I’ll post a follow up after it arrives.

Also on the software front, the biggest question everyone has is whether the Archos tablets include the Android Market. They do not. If you read the CCD, it is pretty clear why–they lack a GPS and compass as well as hardware buttons for home, menu and back. Archos confirms this in their FAQ. I think Archos’ handling of the buttons in software that the CCD requires to be hardware is actually much nicer. Most of the time, the soft buttons are present and actually change orientation when the screen turns. With video playback and viewing slideshows of pictures, they disappear altogether. I have only noticed one app, Aldiko, where the available screen area is a bit off because of the soft buttons. (Aldiko, an ebook reader that supports ePub, is thoughtfully one of the bundled apps.)

If you search, as I did, you’ll find ways around the lack of the Market. I cannot endorse or condone this as it is pirated and illegal software. I really wish Google would just let me buy my own way into the Market with the understanding that some apps may not work right, without a cell modem or GPS. The vast majority of them are agnostic of the hardware specifics, it is very odd that the compatibility definition is so tied to a minority of applications. The process od Installing apps of any kind exposes what capabilities of the device the apps may use, both in software and hardware. It would seem to be a simple enhancement to also have this address less capable devices and possible hardware compatibility issues. Until then, if you do choose to break the law, just be aware that your mileage may vary and that Google undoubtedly has some visibility into unauthorized devices using the Market.

The only other frustration is the camera quality. Given the size of the optics, it is understandable. The default quality setting in the picture taking software exacerbates the noise arising from the small glass and tiny sensor. On the maximum quality setting, with bright lighting, the photo quality is quite good. It drops off very rapidly in darker conditions, reminding me of an old Casio point-and-shoot I had with really stinky low light performance. The lack of a flash makes this more of a problem. However, to supplement proper cameras, either point-and-shoot or DSLR, I am entirely happy. I rarely carry a camera outside of specific, planned occasions, so even a lower quality camera is better than none at all as I carry my MID with me everywhere. Having it on the network, ready for posting to social networks, microblogs, and photo sharing sites also offsets the lesser quality considerably. I also plan on experimenting with the micro-SD card, shooting with my point-and-shoot using the standard SD card adapter then using the MID is a quicker means of sharing than downloading to my desktop library.

If, like me, you primarily are looking for a media player, I think the Archos is a solid buy, especially for the price. I consider the apps and other capabilities as bonuses. If you are looking for something more, you may want to wait for future iterations or devices from other vendors. Maybe hanging onto my 1G iPod Touch has set my personal expectations very low. I love having physical volume buttons, an external speaker, and a camera, all things the original Touch lacked. The bundled media apps are very nice, back porting some features from what my friends have shown me to be standard in FroYo. The included app market is OK, though no real replacement for the Google Market. You can also install standalone packages, like I did with the Firefox Mobile beta (review pending). My usage patterns minimize the frustrations I’ve noted though your mileage may vary.

I am also hoping that my order helps send a market signal that there is strong demand for non-phone, non-tablet (that is smaller than 7 inches) internet devices powered by Android. I choose to think that the long time it took my order to be filled is due to the high volume of orders, a reason for optimism. In the meantime, the Archos 43 IT is pretty much what I hoped it would be, a very pleasant way to step into the Android space without tying myself to a cell carrier.

TCLP 2010-10-13 Monologue: Switched Back

This is a feature cast, an episode of The Command Line Podcast.

In the intro, just a heads up that due to a volunteer commitment, there may not be a news show this weekend.

The hacker word of the week this week is firefighting.

The feature this week is a book end to my switching to Linux feature from back in June. I mention the tag I used on the blog to track my incremental progress. I also refer to one of my earliest rants, on the subject of geek fatigue. The audio software I mention, the one written by Paul Davis and with the very active community, is Ardour.

View the detailed show notes online. You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Linux Switch: A Git for My Scripts

I offered when discussing my feed management and audio encoding to clone the git repo in which I hacked together my various scripts. A couple of people expressed an interest so I went ahead and cleaned everything up to make it presentable for sharing. Feel free to fork my project at github and customize for your own use. I’ve licensed everything under a BSD license which pretty much only requires attribution.

If you have any suggestions, I’d be glad to hear them. Bear in mind this is totally a self-interested project. None of the scripts assume anyone other than me will use them. I may generalize them to make them more friendly for any random podcaster to use but right now it isn’t a priority. I am sharing them more to illustrate what I do and with the pre-granted permission to use them however you like.

Linux Switch: Encoding Audio

Putting out a podcast in multiple formats can sometimes be a bit of a drag. Under OS X, I would send a finished episode to iTunes twice, once each for MP3 and AAC, and send it an additional time to disk as raw audio. For the two iTunes encoded formats, I had to manually add in the genre field since GarageBand doesn’t include anything of the sort in its limited metadata. For the MP3 format, iTunes also didn’t bring over the cover art from GarageBand. Rather than set it when I filled in the missing genre field, I used an ID3 tagging application, called unimaginatively enough ID3 Editor, to add the missing cover art and to populate the copyright field which iTunes doesn’t expose.

For the two open formats I produce, I used the flac and vorbis-tools packages from MacPorts. For the metadata in the Ogg Vorbis file, I cobbled together an AppleScript that copied metadata from one of the files in my iTunes library and pushed it through calls out to the vorbis-tools comment utility.

This hodge podge of tools isn’t very elegant but it got the job done. Bear in mind that I added each of the four formats I produce at different times. There was never any one time I sat down and thought about how I might take a single, raw audio input and mechanize turning that into four formats with as complete metadata as possible.

There wasn’t, any way, until now. Under the auspices of moving my podcast production completely to Linux, I had to re-build my encoding work flow entirely from scratch. Further, I had to find replacements for all the just-so tooling I had accumulated in cruft-wise fashion under OS X.

For flac, I still use the flac package but dug into the documentation much further. I realized that flac supports metadata just as well as any other format, including cover art. Once I cut over on the 3rd, anyone enjoying the full quality audio in flac will see that all of the usual fields are now populated.

In reading up on the vorbis-tools in that same spirit of improving what I had been doing previously, I realized encoding from flac would automatically copy most of the metadata data from the source flac file. It doesn’t save me any time, it actually takes a bit longer to encode from flac, probably because it has to decode back to raw in memory before running the lossy encoding for Ogg Vorbis. It does make my script tidier and all but guarantees that the flac and Ogg Vorbis metadata will be entirely consistent.

The cover art is the only field that oggenc doesn’t copy over from flac, probably because the conventions for attaching pictures to Ogg Vorbis files recently changed. The folks at Xiph have standardized on a base 64 encoded version of how flac packs in images. Using metaflac, it is trivial to read out the binary block from the flac file, base 64 encode it, and set it as an appropriately named comment on the Ogg Vorbis file. Only newer players will support this means of adding images but the Xiph documentation was clear this is now the standard.

The AAC format has proved especially challenging to figure out under Linux. Early on a listener thankfully recommended faac, which is available in the Ubuntu repositories. faac is pretty comparable in the options it takes to lame, the most popular MP3 encoder under Linux. It take a little trial and error to get the quality, bandwidth and bit rate arguments set right (100, 44100, and 96 respectively) to get the resulting file to match the quality/compression result iTunes produces. faac can add all the metadata that used to flow from GarageBand to iTunes, everything except the chapter marks.

I had resigned myself to just dropping the chapter marks, arguably the most valuable aspect of offering an AAC version of the show. As I mentioned in my update to the changes that will go live on the 3rd, my friend Jay clued me in to a set of tools, mp4v2, for working with AAC files. That includes a little utility called mp4chaps. The documentation is non-existent and the text file it takes has a hard coded name and a just-so format. In the end it was pretty easy to figure that all out with Jay’s help and add appropriate logic to the new shell script I’ve put together to drive encoding.

Lastly MP3 presented some surprising challenges. There are a couple of choices for ID3, namely v1 and v2 (technically three as there are two common versions of v2), so it took some examination to figure out which version iTunes was and was not setting. The Linux version of lame has no way to set the cover art of the resulting file. There is some version, somewhere, that has a flag for it (–ti), but not the version that comes with Ubuntu. None of the ID3 utilities I initially found in the Ubuntu repositories could set cover art either. Finally I found eyeD3, arguably the most capable dedicated ID3 tagger. It not only let me set the cover art but with the Wikipedia entry for ID3 in hand, I figured out how to set the copyright field from the command line, something none of the other tools even hinted was possible.

The end result is a shell script that tops out at just over one hundred lines, including comments, that runs out all four formats I am already producing from a single WAV file input. The audio quality should be the same and the metadata on each encoded file an improvement over my old tools. Better yet, there are no manual steps whatsoever. Under OS X there were about a half dozen things I needed to do, from start to finish, at various points across all four files. Now it is a single command line invocation then on to my upload step.

This shell script lives in the same git repo where I developed my feed management script. If anyone is interested in seeing either script, let me know and I’ll clone the project to github and post a separate announcement when that is available. Like the feed script, it has hard coded values for my own use but it would be trivial to fork and customize as needed for your own purposes.

Update on Podcast Feed and Audio Changes on October 3rd

Since I posted my original announcement there has been one change for the better to the plan. I mentioned that chapter marks would be disappearing from the enhanced feed due to an apparent lack of tools under Linux for setting chapter marks on an AAC/MP4 encoded audio file. I was very pleased to be proven wrong on this point today.

Listener, friend and some time code collaborator Jay posted a comment with a pointer to the mp4v2 project at Google Code. One of the utilities in that project, mp4chaps, can consume a plain text file and set chapter marks on an existing audio file. I’ve done some minimal testing and it looks like it should be trivial to enhance my encoding script to include this step. Even better, I can very easily extract the time offsets and text from my note taking format for the show streamlining my overall production process just a little bit further.

So come Sunday the 3rd, the only effect of the cut over will be a one time re-download of old episodes in the feeds. I am thrilled that my change to using Linux and all open source and free software for producing the show will be virtually unnoticeable from the outside. That may seem like an odd sentiment but remember that it isn’t a priority at all for me to convince anyone else to adopt open source or free software.

Don’t get me wrong, I think there are plenty of practical advantages in addition to the matters of principle that inform my own choice. I just think it makes more sense to have low drama conversations about relative merits, to provide a good example free of the usual zealotry, and ultimately respect everyone else’s choice to use whatever they wish.

In that vein, taking a hard line on producing only Ogg Vorbis and flac encoded audio is incompatible with my views. I think it is far better to keep offering the choice I have always offered (as long as the relevant patent holders make that feasible anyway) and be available to discuss rationally and quietly how unencumbered formats compare to their encumbered counterparts.

Linux Switch: Podcast Feed Management

One of the pieces of producing my podcast that was bound up in OS X specific software was feed management. WordPress with the PodPress plugin does an OK job of producing a single feed. I never could come up with a simple way to use WordPress to produce multiple, dedicated feeds for each of the format specific feeds I maintain though. I would not be surprised if it is possible to find a way to do so but early on I found a proprietary, low-cost application on the Mac that made maintaining multiple feeds relatively easy. By relatively easy I mean that while the process I used was inherently manual, it was mostly of copying, pasting and make a few small edits.

A listener suggested I take a look at listgarden, an application built in Perl and OS agnostic. If I was starting my feed management today, with my first episode, it might be a good choice. However, with dozens of episodes archived in my feeds its lack of an import option rules it out for my use.

To be honest, there is no good reason for me to be using any tool, portable, proprietary or otherwise that requires any manual steps, as Feeder did and listgarden would. The slight changes I make when copying an episode from my main site feed to the dedicated feeds are exactly the same every single time. That sort of exact repetition is a strong signal that something can be automated with a little bit of code or scripting.

Last week, I finally got off my notional tuckus and wrote a little bit of Python to scrape the latest podcast episode out of my site feed, tweak it just so, and repeat for each of the audio formats that have their own dedicated feeds. The combination of the feedparser and BeautifulSoup libraries made incredibly short work of this task. The last handful of episodes in all three feeds (AAC/enhanced, MP3 and Ogg Vorbis) were updated using this script.

I only today ran into my first issue with this script and it wasn’t with the script itself, per se. Apparently, the Google Listen app for subscribing to podcasts in Android is very finicky about the type you specify for media files in your feed. If you don’t tag an Ogg Vorbis file correctly as audio, it won’t play the file back. Once spotted, this was a trivial fix and should be correct for all episodes going forward from here. (I’ll hand edit the two or three episodes in that one feed with less than ideal types, a one time additional fix.)

The script in question is highly specific to my podcast but if anyone is interested, I would be happy to clone my git repo to github so it can be read or forked and modified for use with other podcasts.

Linux Switch: My Mixer Works under Linux!

The last time I discussed my ongoing project to switch back to using Linux fully in my lab/home office, it was to apologize for not having much interesting to share since my initial travails getting everything installed on my Mac Pro. Rather than being a complete bum today after I decided to skip tonight’s podcast episode, I figured I’d spend at least a little bit working on the next big task on my list–namely getting my mixer working under Linux.

I have an Alesis MultiMix 8 FireWire, a piece of audio gear no longer being produced. Early on I found the ffado project which aims to support firewire devices under Linux. I even found and bookmarked a page there claiming the firewire versions of the MuliMix boards do work with ffado despite Alesis’ lack of explicit support.

I had previously installed the Ubuntu Studio meta package on my stock Kubuntu 10.4 system. It included pretty recent builds of jack, a low level audio driver and utility, and ffado, the two pieces minimally necessary for being able to capture and playback audio in Audacity and presumably other programs with my mixer. At first I followed the recommended compilation instructions linked to from that first page. The ffado build stalled out on a missing dependency which seemed odd to me as I should have had everything necessary with the pre-compiled libffado installed for Ubuntu Studio.

I decided I’d dig around and see if there was a simple permissions or configuration issue needing sorting to get the pre-built versions of ffado and jack working together. I found several recommended fixes, none of which helped on their own but are good to check and fix if you are also trying to get a firewire mixer working.

  • Find the Ubuntu Studio Controls in your desktop menuing system. In KDE, you can simply search for it. There is a simple checkbox for enabling raw1394. Reboot after you make and save this change.
  • Add yourself to the “audio”, “video”, “disk” and “plugdev” groups. This will make sure you have read and write permissions to the various 1394 based devices under udevfs. Either do this before rebooting for the raw 1394 change or log out and back in for the group change to take effect normally.
  • Make sure you have a /dev/raw1394 entry. If not, install libraw1394 with your package manager.
  • Grep the files in /lib/udev/rules for the string “raw1394″. If there is no reference to that text in any of those rule files, add a file named 50-raw-firewire.rules with the line
    KERNEL==”raw1394″,NAME=”raw1394″,GROUP=”audio”
    You’ll need to restart udevfs after making this change. A simple reboot will also do the trick.
  • Check in /etc/security/limits.conf for a line like
    @audio – rtprio 99
    This gives members of the audio group sufficient privilege to make use of the real time features of the kernel. It isn’t strictly necessary, I think, to get a mixer working but without it, you may need to disable the real time option in jack. On my system, the audio group already had this privilege.

There are several useful commands to diagnose your device, ffado, and jack. modprobe -l or lsmod will tell you if the various 1394 modules are loaded. You can grep specifically for “1394” to filter the output down to these. lspci should have some information about your OHCI host, that is the chip set in your computer to which the firewire devices connect and communicate. Mine is a TI which works but knowing the host’s chipset may help in sieving through the ffado and jack forums. ffado has its own diagnostic tools, including ffado-diag which outputs detailed info about the buses on your system and ffado-test which takes a number of commands. In particular, the ListDevices command will tell you if ffado sees your mixer (make sure it is turned on when running ffado-test).

Ultimately, I could not get the pre-built packages working so went back to trying to compile from source. The missing dependency turned out to be libconfig++, a simple “sudo apt-get libconfig++8-dev” cleared that up. With the next step, compiling jack from source, I noticed the output of the config step said alsa was not enabled. Adding the –enable-alsa flag to the configure script didn’t help. I had to install the libasound development package, then configure reported that alsa support would compile. Finishing out the compile as instructed worked without error.

I didn’t have any luck getting the recommended ffado-dbus-server running but it isn’t necessary for jack. Once I completed my compile and install of jack, I was able to run jackd -dfirewire successfully. As a more convienent way to start and stop jack as needed, I ran the JACK Control application from my application menus. If you open up the preferences, there is an option to run it from the system tray so you can right click and start jack after turning on your mixer and stop it before turning it off when you are done. (My mixer gets rather warm, I don’t like to run it any more than necessary for recording and editing.)

As you can imagine, I am thrilled to have my beloved studio gear working properly. I did some quick test recording in Audacity and everything appears to work a treat. Of course, now I have to learn Audacity and the other audio programs under Linux that can make use of my now working hardware. I won’t say that my next podcast episode will be produced entirely under Linux but now I can tackle that much easier and more enjoyable challenge.

Stalled Progress on Linux Switch

Since it is a slow news day, I thought I’d share some thoughts I’ve been meaning to post but have been taking a back seat to my usual blogging and podcasting.

When I made the decision to try to move my daily activities in my home office, aka The Lab, back to an all open stack I promised regular updates. Since that first weekend, though, I haven’t found much time to make actual progress. I still have a laundry list of things to look into, mostly device and driver compatibility work to be able to do more of the podcast production under Linux. Unfortunately, none of my audio gear works with the latest stock installation of Ubuntu, not even with the Ubuntu Studio meta-packages installed.

My mixer uses FireWire which seems poorly supported for anything other than mass storage. There is a dedicated driver project, ffado, that claims compatibility with a model similar to my mixer. The pre-compiled version doesn’t work, my mixer doesn’t show in my KDE system settings audio device section. I do see the ffado drivers available in Audacity and Ardour but they simply don’t work. I am hoping that compiling from the latest sources may fix this.

As an alternative, I did try to fire up Audacity with my USB portable recorder. My H4n can drive my studio mics, has decent preamps, and can be connected as a multi-channel audio interface. Hooking the recorder up worked. At least until I stop recording on a track and tried to start recording again. The error I got from the crash seems to indicate I may need to get a bleeding edge version of port audio compiled.

Both these lower level audio compiles will probably kick off a cascade of other re-compiles for the applications that make use of them. It’s hard to see how I can carve off an hour or two of this effort to pursue every odd weekend. That has held me back from even trying. I guess my fear is that if I get an hour or two in and want to stop for the day, doing so may not be possible if I’ve wrecked my system in some way. If I had another Mac on which I could try things out without fear of horking my main system, I suppose that would help. Maybe I need yet another internal hard drive to triple boot to do just that.

To be fair, talking in such detail about these obstacles doesn’t paint a representative picture of my daily use of my Linux install. All of the communications and social applications I use work beautifully and my morning routine has been smoothly re-tooled so I can enjoy my coffee and my morning catch up without any hitches. My daily writing tasks also have been undertaken almost exclusively on Linux since the switch with no hiccups or complaints. The only time I write on OS X is when I want to work on my laptop on which I haven’t even considered installing Linux because of the ensuing hassles that would arise from my aging iPod which still needs at least one Mac with which to sync.

Speaking of the iPod, I did see news this morning that Samsung may be releasing a new Android based personal media player under their Yepp brand. According to what little information I could find, the player may essentially be a Galaxy without the phone components. It certainly would be smaller than the Dell Streak, which I have been contemplating. There is no US release date or price information. The version that is out overseas lookes like it is running Android 2.1 and from the screen shots appears to have the Market icon, two huge advantages over the Streak. If Samsung releases this gadget stateside, my personal media player may be the next bit of gear to receive some Linux love.

Setting aside my qualms about Apple’s mobile platform, I am getting tired of the increasing quirks of my aging iPod and would be glad of an updated device regardless of the make. I have even been contemplating just getting a dead nuts simple media player that is Linux friendly, usually entertaining the thought when my iPod’s touch screen goes out to lunch for no apparent reason.

Linux Switch: Install Notes

The first big step in my move to run an open stack in the lab was getting Linux installed on my workstation. Being a pragmatist, I wanted to find the most cost effective way of doing this with the hardware I already have on hand. Using the Mac Pro I already have also suggests a dual boot, letting me incrementally switch over tools and processes from OS X to Linux. I’ve run a dual boot on my Mac Pro before to boot into Linux when working from home so as to have the same environment for work development as at the office.

I decided I didn’t want to fool around with re-partitioning my existing drive. I did that last time and it was really just a hassle. Given how cheap drives have become, I went ahead and ordered a 2nd internal drive. I figured this would give me some more flexibility if I got to a point where I felt I could ditch OS X altogether.

After the drive arrived, I set aside a Saturday morning to do the installation work. I actually invited my friend, John Taylor Williams, over to observe as we are planning to perform a similar installation on his Mac Pro down the road. I expected things to go very smoothly but unfortunately, that’s not exactly how things unfolded.

The first problem I encountered was with my ATI video card. With my previous dual boot, the video card under Jaunty and Karmic worked without complaint. The Lucid installer dropped to a black screen when trying to switch over to the graphical installer. I posted status messages about my problem and @claudiom offered the vital clue that helped me get past this particular issue. The ATI Radeon HD cards are known to have a problem setting modes. If you hit F6 at the initial menu on the install disc, you can add the “nomodeset” option. For good measure, I edited the boot line to add the kernel parameter, “radeonhd.modeset=0″.

Post installation I had a little more trouble getting these kernel parameters permanently configured. First, the install disc doesn’t actually add “nomodeset” to the editable boot line when you set it. I was trying to boot with only adding the Radeon specific parameter to the Grub boot entry. Once I realized I needed “nomodeset”, I was able to update /etc/default/grub to add “nomodeset radeonhd.modeset=0″ to GRUB_CMDLINE_LINUX and run “update-grub” to merge that change into the boot configuration.

I hit a known bug with the standard installation disc when trying to install to a disk other than the first hard disk installed. There is a simple fencepost error in the menu code. If you try to select the second drive when you get to the disk partitioning step, you get an array index out of bounds error. I ended up using the alt install iso to get past this. The resulting system is identical but the alt image uses ncurses so doesn’t run afoul of the bug in the GUI installer.

The last problem I encountered was some confusion on Grub’s part with my two bootable disks. This was perhaps the most panic inducing as at various points, my system appeared to be unbootable into either OS X or Linux. The problem is that Grub was trying to set up to boot from the 1st drive in my system, what it labels as hd0. The config it was using was correct except that hd0 is my OS X drive, so the pointers to config files and paths simply were looking at the wrong drive. I tried to intercede with Grub’s powerful boot editor, like I had for the video parameters I needed. Nothing I tried worked to get Grub to recognize that hd1 was the actual Linux drive.

Thankfully, another online acquaintance stepped in to help, @eeefak. He recommended I run the disk tool under rEfit, the alternate EFI boot loader. Doing so resulted in an extra, non-bootable option showing in rEfit’s menu from that point on. Small price to pay as fixing the suggested drive activation in that tool sorted out the Grub confusion making the Linux and OS X boots both work as required.

Once I got the video and Grub issues resolved, well after JTW had to leave, I encountered no other problems with my fresh install. I was able to quickly get my usual tools set up and running, primarily Firefox with my preferred add-ons and Thunderbird plus Enigmail pointed at my Gmail account. I haven’t had time yet to dig into my next project on the list, getting my FireWire mixer to work, so for now I am booting back into OS X to recorder, master and publish podcast episodes.