The actual instalation process, for the most part, wasn’t a whole lot different from the steps I followed to install it on the laptop. But there were a few subtle differences in what was required. And naturally, they were just tricky enough that the easiest way to implement those differences was to blow the instalation away and start over. So we did, probably two or three times. On the third try, we managed to actually get the thing mostly up and running. By this point, we were very nearly on easy street. So I decided to do the exact same thing locally.
My install required a little bit more creativity, mostly because I was also using it as an excuse at guessing which VM settings would play a little bit nicer with our instalations. I got mine up and running on the fourth try, or thereabouts, and threw the modified settings at the first attempt at a Gentoo install. Now, with both machines up and running and not threatening to explode, we could play.
Shane’s heavily into the whole beta testing thing, so we went on a dependancy hunt to trick out his install with the requirements for at least one game he’s been testing. Then, we threw Gnome at it, and while that took its time installing, we threw a small party. The new and exciting part of all this was over by now–virtual Gentoo plays just as nicely as nonvirtual Gentoo, post-install. So now comes breakage.
I had no idea exactly how hard Gentoo, even in a VM, was to break. Or how easy it was to fix when it did. We’d try this or that nifty little trick, compile something, and watch it fall over. And in about 10 minutes at best, we had the why, the when, the how, and a fix was on its way down. The two things we didn’t intentionally break are apparently fairly common, or at least, simplistic issues–apparently, kernel 2.6.36 is still way, way too knew. As in things that depend on the kernel sources being installed–hello, NVidia drivers–fail quite fantastically at the compile stage. Same with the latest current stable version of Speakup, which escentially meant if we wanted the instalation to talk at us, we weren’t about to be using that kernel version. There’s apparently such thing as *too* bleeding edge. Who knew?
Another potentially kernel-related almost failure isn’t actually what I’d call breakage, but it is kind of annoying–and equally not either of our falt, lucky for us. This is the more common/known/widely experienced issue–when you run certain commands from the console or a remote session, it throws an “Unknown HZ Value!” error. It doesn’t actually break, and I’m assuming the results you get from that command are what you’d expect to get, but the error, or notice if you’d rather, regularly makes an appearance. We traced the problem to Procps, a utility package that contains several system monitoring programs among other things. I was about ready to report it, then saw it was already taken care of–hence the more widely experienced/common-ness of this annoyance. This is not something I’ll be fixing any time soon, but the activity so far as this bug report shows indicates people far more experienced than me with Gentoo, kernel tweeking and all the fun crap that goes with have it well in hand. Or at least are faking it very well. So now, we just sit back and see what else decides to implode.
The install actually went a little easier than I was hoping, if only because hey, I needed an excuse to break things on a more permanent basis. But, oh well. The OS works, on both machines, and any lingering loose ends we can safely reject any and all responsibility for. For my next trick, I’d like to see if I can install MacOS on the VM. I’d be interested in seeing how badly that breaks. In the meantime, time to go play fix the video card. Thank god for caffeine.