Category: Gentoo

I’ve begun to think that my truck hates me. Last weekend, I had it at the shop because the heater has been working intermittently this winter. It turns out that the heater core was clogged, which meant that very little hot coolant was flowing into it to actually make it work. On top of that, I needed new back tires. Those two things ended up costing me just shy of $400. A few months ago, I had all 4 shock absorbers and the front tires replaced as well as a frontend alignment and something else I’m forgetting. All of that cost $800 or so.

Tonight, when I started my truck to leave work, the Service Engine Soon light came on. I was not happy. I stopped by AutoZone on the way home to have them pull the diagnostic code. The guy hooked up the reader and the first thing he said was “Ooh, this is a fun one”. I cringed. The code was “random cylinder misfire”. I cringed again. He said that there a few things that would cause this problem. The first was a fuel pressure problem, which makes sense since my truck tends to idle a bit rough and have some problems starting (when the engine is cold (regardless of outside temperature), I have to turn the key for 10-15 seconds or even a second time). The second possibility is the crank and/or cam sensor. I’m sure either of these possibilities will cost me lots more money. Hopefully, this will be covered under the 3-year/36,000-mile coverage plan I got with my truck when I bought it in September 2005. I guess I’ll call the dealer tomorrow.

After months of people asking me what Quickstart is, and me having to take the time to explain it, I’ve finally gotten up off my lazy butt (and then sat down again) and put together a project page for it.

For a while now, codeman and I have been working on a major overhaul of GLI (Gentoo Linux Installer or “the installer”). After I wrote Quickstart, it became apparently that the entire reason for GLI’s current design was no longer valid, since Quickstart was already more functional as an automated installer than GLI ever would be. We decided to drop the “configure first, then install” structure that the installer was originally designed with.

The results have so far been more than we could have hoped for. The entire install is now done in real-time (like virtually every other installer out there). For example, adding/deleting a partition takes effect immediately, clicking the Next button on the stage selection screen downloads and unpacks the stage before you move on, etc. Just the partitioning change has eliminated one of the largest complaints about the installer of old (it tended to eat partition tables if there was anything “weird” about the existing layout, such as partitions out of order, primaries after an extended, overlapping partitions, etc. due to the fact that it had to track all the changes in memory, serialize it to XML, read it back from XML, compare to the existing disk layout, and then make the existing match what was in the XML).

This allows us to do many things that we couldn’t do before, such as allowing the user to go back and change a setting if an install step fails, opening up an xterm/gnome-terminal window for ‘make menuconfig’ so the user can configure their own kernel, etc. Of course, you now have to babysit the installer, but you have to do that with a manual install, too.

Recently, when testing the installer, we noticed a weird issue. When ’emerge sync’ is run, rsync would complete the sync but not exit, which caused the install to hang. It took 2 days and a lot of frustration to finally track this one down. We owe the answer to d_m (on freenode).

The installer runs with 2 separate threads. The frontend is the main thread and the backend starts up a second thread to run the commands that perform the install. It turns out that when python creates a new thread, it blocks all signals for that thread. I’m not quite sure why. This has the side effect of blocking all signals for any processes that are fork()ed and/or exec()ed from that child thread.

Rsync fork()s when it’s doing it’s thing. One process waits for a USR2 signal from the other before they mutually exit. Since python had blocked all signals, the signal wasn’t getting from one process to another so they could exit. d_m’s solution was to write a small C program that resets the signal mask when running external programs. While this works, it is a huge hack. Although, this bug should be fixed in python 2.4 :-/

I just finished putting together a FAQ (URL changed) for the Installer project. We’ve been getting asked these questions over and over again, and it was starting to get a little bit annoying. Questions, comments, additions, etc. are welcome.

After all my frustration with the original C3600, I found a barebones (no video, memory, or disks) C3600 on eBay for $100 (~$150 after shipping). I’ve frankensteined (I love that term) them together and now once again have a working C3600. Hurray!

The other day, I obtained a cute little 333MHz iMac via eBay to use for installer work. After getting it, I find out that it uses SO-DIMM instead of SDRAM, so I can’t pull memory from my other boxes to upgrade it from the 64MB it has now. I’ve got a laptop, but it only has 28+128 currently, so I don’t want to pull any from that. Back to eBay, I guess. Isn’t it cute?

 

After the announcement today on /. about Genux doing a 2 week trial period of free support, I decided to see how far they had come. I downloaded their installer CD and wrote a little review which can be found here. Seriously, are they really going to release this thing in this condition?

In the interest of fairness, I’ve done a review of the Gentoo Linux Installer to complement the “review” I did of the Genux installer the other day. I tried to point out as many flaws and weaknesses as I could, since I gave the Genux installer the same “courtesy”.

I am ashamed of myself…