Installing Arch Linux with an encrypted root

I’ve got a ThinkPad T410. I got it off craigslist in what was a somewhat shady transaction. Regardless, it came with a 300GB spinner. Not interested in finding out how much life was left on it I got a solid state replacement from NewEgg for “Cyber Monday”. A 240GB Intel one for $110, that’s less than 50 cents per GB!

The spinner has a single unencrypted partition with Arch Linux running on it. I wanted to run Arch on an encrypted partition. The main reason: If it’s ever stolen I don’t want to have to worry about any of the data on it. Bonus reason: Geek/spy points.

So, while there are excellent guides for installing Arch, and setting up encryption, and optimizing an SSD, there don’t seem to be any combining the three. In reality it’s not that much more difficult, and if you are motivated to setup encryption on Linux in the first place you probably know what you’re doing. Still, I was disheartened a bit at the lack of information so I decided to note how I went about it in general. Continue reading

Raspberry Pi – Cross-compiling

Now that you have the hardware built and tested (although that’s not necessary), you can either use the code I’ve written–which is specific to the hardware and environment I have, or compile your own version. If you want to compile your own there are two options:

  1. Compile on the Pi itself
  2. Compile on an ARM virtual machine
  3. Cross-compile on a faster machine

The trade off? Compiling on the Pi is slow (very slow). The virtual machine is a marked improvement for compiling speed, but is complicated to setup. Cross-compiling is about the same difficulty as setting up a virtual machine but a bit faster and less “bulky”. So it depends. The virtual machine is nice if you have a lot of libraries you want to use, since you’ll have to compile all of them to be available for linking. If any of them have poor autoconfig support, it might be a pain to fix if you weren’t already on the target machine. But, since I just needed one or two popular libraries, I decided to setup cross-compiling from my host (x86_64) machine.

The last time I setup cross-compiling it was on Gentoo, and it wasn’t pleasant. However, after a little bit of research it looks like the crosstool-ng project is pretty popular and useful. I only had to patch one tiny thing.

Here’s the overall process:

  1. Install crosstool-ng
  2. Configure a cross toolchain with it
  3. Try and build the toolchain
  4. Use the toolchain to build your Pi code

Continue reading

Interesting Spam

Akismet is really good at preventing spam, but I’ve noticed that spammers don’t even seem to be trying sometimes. This is what’s in my spam queue:

{I have|I’ve} been {surfing|browsing} online
more than {three|3|2|4} hours today, yet I never found any interesting article like yours.
{It’s|It is} pretty worth enough for me. {In my opinion|Personally|In my view}, if all {webmasters|site owners|website owners|web owners}
and bloggers made good content as you did, the {internet|net|web} will be {much more|a lot more} useful than ever
before.|
I {couldn’t|could not} {resist|refrain from} commenting.

Granted, it’s probably a bot doing this that has some Mad Libs license key problem, but still… at least try.

Carduino 2.0 – Intel Galileo Setup

Out of the box the Galileo is setup to run sketches uploaded from volatile memory, which is really lame. I didn’t spend much time with it using the stock SPI kernel. So, an SD card is pretty much required to do any serious development with this board. This is not a bad thing (although you aren’t running in real-time anymore), since having a full OS to use has lots of advantages. Plus, this way I can automate the build process in a way I’m more familiar with. Continue reading

Carduino 2.0

Over a year ago I got an Arduino Uno and a CAN-BUS Shield to try and make some kind of datalogger for my car. I was also interested in using the OpenXC library with it (which might need a port if there isn’t one already, since it uses the Digilent chipKIT Max32 development board). While OpenXC allows interfacing with Android stuff for phones, I’m more interested in a self-contained datalogging type deal. Connecting a phone to review/control things would be a plus, but not required. Mainly, it would record to an SD card for later manipulation on any platform.

The problem with the Uno was that it has limited flash storage space, 32KB total. Lots of strings (for LCD output) in my source combined with some poorly written C++ CAN-BUS/SD/GPS libraries that SK PANG provide with the CAN-BUS shield, and the compiled output is just too large. The libraries are a hodge-podge of various OSS projects. I intend to rewrite them in C. You can run the binaries off the SD Card, but that’s not what I wanted the SD Card for.

Carduino 2.0

So, I just got a Arduino Galileo, which is way overkill. It was either get a Arduino Mega, which has enough flash but is otherwise relatively the same (and likely going to be obsolete soon), or get the Galileo. Instead of Atmega powered, it has a real Intel x86 SoC and runs Linux! No more AVR cross-compiling. And since it is Arduino Uno “shield compatible”, I don’t have to worry about the shield not working (I think! I’m assuming the shield follows the Uno spec.).

8MB Flash, 400MHz clock speed and a whole other bunch of superior specs I don’t remember. Now, the embedded Linux kernel is on that 8MB, and takes most of it up. So at first it looked like I was in the same boat. However, it has a built-in SD card slot that you can load up another, larger, image onto. Now I have two SD Card slots, one on board and one on the CAN-BUS shield. One for the OS, one for logging data. Perfect.

First I have to get familiar with the Galileo and setup the environment. After that I can start developing. So this will be split up into at least two other parts.

First autocross with a VG33

Well, with less than a couple hundred miles on the rebuilt engine, it was time to really break-in the new VG33. I took it to an autocross. Things were going well until I shut it off after my second run. It didn’t want to restart after that. It appears that the culprit was low battery voltage, as the ECU was resetting and the fuel pump never even came on during cranking. Even with a jump cranking speed just wasn’t very fast.

I did get three runs in, albeit only one of was clean. The first one was red flagged due to someone else spinning out, and the last one I spun out. Here are videos of the clean run and the second run where I spin:

 

280Z LED Conversion Part 2

Continuing from part 1, this is the start of installation and results of the LED conversion. I ordered a small bunch of LEDs to get a feel for what brightness I’m looking at since the website I ordered from has somewhat confusing ‘relative intensity’, ‘brightness’, and ‘lumens’ listed for each bulb. Not to mention the prices seemed to fluctuate independently of any of those values so it wasn’t as simple as ‘find the most expensive ones’.

For the first part of the conversion I ordered just 6 bulbs. The Type 97 and Type 89 replacements for the front and rear side markers and the two license plate lamps, respectively. They all use a BA15S base (1156), but the bulb is much smaller. I went with 15 LED license plate bulbs since the bulbs don’t face outward. In retrospect the 15 LED bulbs would have been nice for the side markers as well, but the 9 LED ones I got are at least as bright as the incandescents, probably a tad brighter.

9 LED vs stock Type 97:

 

Incandescent (left) and 15 LED bulb (right)

 

Before:

After:

If I had to do it over again I’d get the 15 LED bulbs for all the clearance lights instead of the 9 LED as they are a bit brighter and have better coverage. But they are still brighter, in my unscientific opinion, than the stock filaments.

Satisfied, I ordered some more bulbs:

The contents being:

  • 2 67-R15 Red (rear tail lights)
  • 2 1157-A45-T 1157 Amber (front combination lamps)
  • 2 1157-R45-T 1157 Red (rear combination brake/tail lights)
  • 2 1156-R45-T 1156 Red (rear turn signals)
  • 2 CF13JL-02 (3 Pin Zero-Load “Japanese” Flasher)

The brake and tail lights are slightly brighter, but come on much faster. The 67-R15s could be replaced with something even more bright but it’s not a big deal. I took a few photos before and after but it’s really hard to tell. However, here is one side-by-side comparison shot:

The left side is the stock tail light bulbs and the right is the new LEDs (67 and 1157).

Once you replace the turn signals the stock flashers will give up due to lack of current. This is fixed by replacing the stock flashers with these “zero-load” flashers. The stock ones depend on enough current to heat up an element and warp it, at which point it triggers by bending and hitting the contacts. This is why if bulbs are out the flash rate is different, or it stops flashing all together. Anyway, these “digital” flashers just happen to fit perfectly with the stock harness. All that’s needed is an extra ground.

The stock turn signal flasher is attached to the steering column, near the pedal mounts:

The hazard flashers is above the ECU and ignition relay:

Wiring both of them up is easy as the B and L terminals match up fine with the stock female plugs.

The wires (on a 1977 CA 280Z) match up as follows:

  • Turn signal flasher
    • W -> ‘L’ (Load, not blue like in the FSM)
    • G/Y -> ‘B’
    • E is the new earth/ground you’ll have to run.
  • Hazard flasher
    • G -> ‘L’
    • R/W -> ‘B’
    • E is the new earth/ground you’ll have to run.

Unfortunately there weren’t mounting tabs on them, but a couple zip ties and it’s good.

And that’s it. I measured the actual amperage before and after (just for the parking and tails), and it went from 1.5 A to 0.5A (33%), with 0.5 A of the dropped attributed to the tail lights alone. Not as a big as I thought but anything to reduce the load on the stock combination switch is good. That’s 20W down to about 7W. My initial calculations relied on the listed wattage for the bulbs, which I’m guessing is based on the maximum current draw which would be when the bulbs are first turned on. That’s down over 90%, which translates into my alternator not pulling down the idle when I first switch the lights on.

280Z LED Conversion Part 1

My 280Z isn’t what you could call “modern” in the electrical department. Originally, it came with an externally regulated alternator, fusible links, incandescent bulbs, and very few relays. The design inhereted a few things from Lucas eletronics, which is not a good thing. Regardless, it was fairly normal for the time. I’m glad there are no vacuum operated things, like some makes. The most electrically obtuse part of the design is the lack of relays. So, all the current for the headlights, parking lights, turn signals, and brakes goes through the individual switches for each. So, not only is there a significant voltage drop by the time the bulbs actually see any current, the switches are very prone to corrosion and failure. Sourcing a replacement column switch is getting harder and harder.

Solutions to this problem? Add in new relays for the lights to significantly reduce the load on the switches, and/or add LED lights to reduce the current draw of the lighting system altogether.

I’m opting to do the latter for now. The power savings are calculated as:

1977 280Z

  • 2 50W/40W headlights
  • 4 Type 97 (1156) 8W bulb side markers (2 amber, 2 red)
  • 2 Type 89 7.5W license plate bulbs
  • 2 Type 1157 23W/8W Stop/Tail lights
  • 2 Type 1157 23W/8W Front Park/Turn signal lights
  • 2 Type 67 8W Rear tail lights
  • 2 Type 1156 23W Rear turn signal lights
  • 2 Type 1156 23W Reverse lights

Incandescent bulbs:

  • 1156 – 23W * 4 = 92W
  • 1157 – 31W * 4 = 124W
  • 67 – 8W * 2 = 16W
  • 89 – 7.5W * 2 = 15W
  • 97 – 8W * 4 = 32W

279W total (not including headlamps). Granted, that’s with the brake lights depressed, in reverse, with the lights and hazards on. A more typical wattage would be 95W.

LED Bulbs

Sidemarkers:

  • 97 (9 LED 67-x9 Amber) – 0.5W * 2 = 1W
  • 97 (9 LED 67-x9 Red) – 0.5W * 2 = 1W
  • 89 (15 LED 67-x15 Red) – 0.5W * 2 = 1W
  • 1156 (45 LED 1156-x45-T Red) 0.14W * 4 = 0.56W
  • 1156 (45 LED 1156-x45-T Amber) 0.16W * 2 = 0.32W
  • 1156 (45 LED 1156-x45-T White) 0.16W * 2 = 0.32W
  • 1157 (45 LED 1157-x45-T Red) 0.165W * 2 = 0.33W
  • 1157 (45 LED 1157-x45-T Amber) 0.195W * 2 = 0.39W

4.92 Watts, and that’s at full load. That’s two orders of magnitude less. Again, that’s with everything on at once. A realistic value is 4.16W. Not a big difference than all of them on, mostly due to the clearance and license plate LEDs taking most of the power in the first place. So, all the parking and operating lamps on the car illuminated for about half the power of a single incandescent clearance lamp. That’s a huge improvement:

4.92 W / 279W = 1.76% of the power with everything on, 4% with just the parking lights.

The catch? LEDs are expensive. Most of the cost is with the 1156 and 1157 replacements, at $20-30 per bulb. Also, digital flasher units are required rather than the heated element type in use (this also has a significant power drop, not calculated here). The total comes out to around $250. Ouch. Cheaper LEDs can be had, but they will not be as bright, and won’t last as long as quality units.

Continued here.

Updating WordPress on nearlyfreespeech.net hosts

Update Dec. 13, 2014:

These scripts are out of date. NFS has the WP-CLI installed allowing for much, much easier upgrades, backups, etc. See the repository for information.

Originally posted on Sept. 10th, 2014:

If you use NearlyFreeSpeech.net as your web host, you may have found it difficult to automate WordPress updates. I’ve made a script that does this for you. It also calls my backup and permissions fixing scripts, which I include here as well.

Beware of some notes and assumptions though:

  • Assumes WordPress is installed in /home/public/ (not a subdir of it)
  • Scripts are assumed to be in /home/private/
  • Does not check or recover from errors

Continue reading