Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Although automobile batteries have “standard” sizes designated by BCI Group numbers, this Group 34R Sears Diehard battery was about an inch shorter than the previous one:
Toyota Sienna – short Group 34 battery
It arrived with a plastic grid embossed with the helpful notation “Use this height adapter under battery if necessary”, but I figured lower was better. A little bending, two snippets of mouse pad (remember mouse pads?), and a section of white plastic rod faced off / drilled on the lathe anchored it flat on the platform with no wiggle room at all.
With any luck, that’s the last battery the van will ever need…
That window is far enough away that birds get up to full speed and low enough that they can see through the windows on the far side of the bedroom to the bushes and trees north of the house.
One of the battery packs powering the GPS+audio interface on our bikes has completely failed, with zero volts at the output and no charge indication. The other five chug along as well as can be expected:
Initial-brand DVD External Packs – 2013-11
The push-to-test button on Pack 4 has become increasingly erratic over the last few months, rendering the charge status LEDs mostly useless, so it has two curves: the lower capacity came directly from the bike, the higher hot off the charger.
For reference, here’s what they looked like in May 2012:
External Li-Ion packs – 2012-05
And right after they arrived:
Initial External Li-Ion packs
Given their nearly constant use and charge cycling, I’m impressed.
Quick summary: the current Linux startup machinery Runs All The Things! in parallel, leaving you to figure out all the interdependencies and update all the script files to match your requirements. Mostly, the distro maintainers figure all that, but if you have essential files mounted as NFS shares, then you can will reach a login screen before the mount process completes.
Having wrestled with this problem for a while, I think I’ve doped out the right way to coerce the Upstart Pachinko Machine to converge on a workable login.
The solution is to fire off a unique signal after the NFS mount command, then force the display manager to wait until it receives that signal, rather than depend on happenstance as I did before. The mounts occur in /etc/init/local.conf, which now looks like this:
description "Stuff that should be in /etc/rc.local"
author "Ed Nisley - KE4ZNU"
start on (local-filesystems and net-device-up IFACE=em1)
stop on shutdown
emits nfs-mounted
script
logger Starting local init...
logger Mounting NFS filesystems
mount /mnt/bulkdata
mount /mnt/userfiles
mount /mnt/diskimages
mount /mnt/music
initctl emit nfs-mounted
logger Ending local init
end script
The start condition ensures that this code won’t run until the wired LAN is up; note that what was once eth0 is now em1. Then, after the mounts happen, initctl fires the nfs-mounted signal.
The modification to /etc/init/lightdm.conf script consists of one additional line to wait for that signal:
start on ((filesystem
and runlevel [!06]
and started dbus
and plymouth-ready
and nfs-mounted)
or runlevel PREVLEVEL=S)
stop on runlevel [016]
emits login-session-start
emits desktop-session-start
emits desktop-shutdown
I’m not convinced lightdm.conf is the right spot to jam a stick in the gears, but it seems to be the least-awful alternative. The login-session-start signal doesn’t appear in any file in that subdirectory and I have no idea where else to look.
Anyhow, the greeter screen now shows a desktop background from the NFS mount, which I regard as A Good Sign:
Part of the routine cleaning around here involves running the vacuum cleaner nozzle over the keyboard to suck up random debris, but that doesn’t extract crud from under the keycaps. Almost exactly three years after the previous cleaning, I finally decided the keys had lost enough of their normal feel to justify the hassle of taking the thing apart.
Bolstered by that experience, however, I just yanked the keycaps off with a removal tool from my old bag of tricks, revealing the horror that lies beneath the surface:
The keycaps took a swim in a dishpan full of hot soapy water, endured some scrubbing, and emerged looking like new. Thwacking them on a towel ejected the remaining water from the posts.
With the electronics still in place, I vacuumed the larger chunks out of the tray, scrubbed the aforementioned hot soapy water around the bushings with an acid brush, then cleaned up the residue with cotton swabs. There’s a paper towel under the drain gutters to catch the runoff, which worked surprisingly well.
The keycap legends have been eroding, as they’re basically a decal stuck on the surface. Eventually I’ll have a crappy non-clicky Das Keyboard Model S Ultimate.
[Update: a spammer’s script has been attempting to create hundreds of junk comments per day, so I’ve temporarily disabled comments for this post. Drop me a direct note using the About / Copyright / Contact link on the right if it’s critical. I expect this to pass in a few days, but I may be underestimating the stupidity out there. ]
A note from regular commenter Frans:
Don’t get a Das Keyboard if you want a keyboard without a keypad. Look into e.g. a Leopold Tenkeyless Otaku. The one to which I include a link comes with the same Cherry MX Brown switches as the Das Keyboard Silent.
Picked up a Sandisk 32 GB Micro SD Card from a reputable supplier for $0.62/GB, in the hope that Santa will deliver a helmet camera:
Sandisk 32 GB microSD card
Until that happy event, I verified that it can store and return 32 GB of white noise with absolute fidelity.
It came formatted with an empty FAT32 filesystem that allows single files up to 4 GB. Reformatting with exFAT supports vastly larger capacities and, in this case, allows single files up to 32 GB. Whether it’s actually legal to use exFAT on a Linux box remains up for grabs, but installing exfat-utils, which drags in exfat-fuse, does the trick.
Verifying the SD Card capacity went swimmingly, much along the lines of the original recipe. The data file size came from the card’s FAT-32 formatting and is a smidge less than the capacity after reformatting the card with exFAT. Close enough for this purpose.
dd bs=1K count=31154656 if=/dev/urandom of=/mnt/part2/Testdata/Testdata.bin
(This took the better part of an hour; I didn't record it.)
sudo mkexfatfs -i babeface -n SanDisk32GB /dev/sdb1
mkexfatfs 1.0.1
Creating... done.
Flushing... done.
File system created successfully.
sudo dumpexfat /dev/sdb1
dumpexfat 1.0.1
Volume label SanDisk32GB
Volume serial number 0xbabeface
FS version 1.0
Sector size 512
Cluster size 32768
Sectors count 62325760
Free sectors 62317504
Clusters count 973719
Free clusters 973711
First sector 0
FAT first sector 128
FAT sectors count 7616
First cluster sector 7744
Root directory cluster 7
Volume state 0x0000
FATs count 1
Drive number 0x80
Allocated space 0%
time rsync --progress /mnt/part2/Testdata/Testdata.bin /mnt/part/Test.bin
Testdata.bin
31902367744 100% 9.15MB/s 0:55:24 (xfer#1, to-check=0/1)
sent 31906262150 bytes received 31 bytes 9594425.55 bytes/sec
total size is 31902367744 speedup is 1.00
real 55m25.791s
user 3m16.088s
sys 2m7.808s
df -h /mnt/part
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 30G 30G 4.0M 100% /mnt/part
time diff /mnt/part2/Testdata/Testdata.bin /mnt/part/Test.bin
real 28m43.878s
user 0m4.044s
sys 0m42.902s
ll /mnt/part/Test.bin
-rwxr-xr-x 1 ed root 31902367744 Dec 2 18:32 /mnt/part/Test.bin*
rm /mnt/part/Test.bin
df -h /mnt/part
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 30G 4.1M 30G 1% /mnt/part
I’m probably easily impressed, but wow that’s a lot of data in a little chip of plastic… for $20 delivered.
Although the Optiplex 780 continues to chug along, some additional bringup notes for the new-to-me Optiplex 980 may be of future use. In no particular order, because that’s how it goes:
The OS is Xubuntu 13.10 in the 64-bit flavor, mostly for UI & infrastructure consistency with my other boxes. The Ubuntu project continues to diverge from consensus reality and the process of fighting down the Special Ubuntu Sauce seems increasingly difficult and less rewarding. This may be the last box I set up with Xubuntu, although I’m not sure what else to use; Arch requires more fiddly sysadmin-fu than I’m willing to allocate and Ubuntu-based distros like Mint seem to have all the disadvantage of Ubuntu plus the difficulties of splinter distros.
With two cores and HyperThreading turned on, it has enough moxie to run one instance of the GIMPS prime factoring code without crippling the UI. The estimated completion date for the current work is 9 July 2014, which should creep closer as the CPU sees more uptime. The previous crontab startup continues to work. It adds about 25 W to the baseline 50 W consumption.
Adobe has abandoned Adobe Reader for Linux and attempting to install the most recent version of 9.whatever produces a blizzard of warnings. I’ll try Okular and Evince, although both have problems with some PDFs that Reader handles with aplomb. Eliminating the security exposures in Reader should be a net win.
Okular gets its own devilspie2 rule that look a lot like the previous one for Adobe Reader:
if (string.find(get_window_name(),"Okular")) then
unmaximize();
set_window_geometry(0,0,1000,100);
set_window_geometry(2561,0,1000,100)
maximize();
end
This Optiplex 980 has two built-in video connectors (DisplayPort and VGA) that work with the Free Software drivers. After some fumbling around, the XFCE Display configuration utility positioned and rotated the landscape and portrait monitors as I wanted them. Running the 1680×1050 display with analog VGA signals produces a noticeably less crisp result, but it’s on the OK side of Good Enough.
The startup display / greeter doesn’t handle that configuration very well at all:
Xubuntu greeter – dual displays
The .xprofile file doesn’t need the xrandr hacks and includes the display names corresponding to the new video outputs:
setxkbmap -option terminate:ctrl_alt_bksp
#xrandr --output HDMI-0 --rotate left
#xrandr --dpi 100x100
xsetwacom --verbose set "Wacom Graphire3 6x8 stylus" MapToOutput "DP1"
xsetwacom --verbose set "Wacom Graphire3 6x8 eraser" MapToOutput "DP1"
Although I’m sure there’s a Better Way that’s now The Standard Method, just creating a simple /etc/X11/xorg.conf file (with nothing else!) swapped the Kensington Expert Mouse buttons:
Perhaps that should be in a file tucked in /usr/share/X11/, along with 50-wacom.conf, which I modified to swap the stylus buttons, which worked the last time:
The default audio stream goes through DisplayPort and comes out of the monitor’s audio jack, which took an embarassingly long time to discover. As nearly as I can tell, there is no way to enable the internal audio in addition to the DisplayPort channel; putzing with pavucontrol and alsamixer was unproductive.
The “indicator applet” sound control seems to be irrecoverably broken, for reasons having to do with the change from GTK2 to GTK3 (or something like that); the suggested workaround do not work for this system. Unfortunately, XFCE allows exactly one mixer applet in the panel, which will pose a problem with the USB headset I use for phone calls.
I think having the local.conf routine emit a unique signal after mounting the NFS shares, then having the lightdm.conf routine wait for that signal, might just do the trick. More research is needed.
Of course, a release or two ago the tried-and-true network interface names changed, for well and good reason, but … OK, I can use em1 instead of eth0, although I sure hope that’s not a random outcome.
En passant, I discovered why the keyboard didn’t respond during boot: a crappy powered USB2 hub wasn’t working quite right. Swapping in an ancient Belkin powered USB hub solved that problem:
Belkin USB Hub – under desk
The hub concentrates the desktop peripherals (keyboard, two trackballs, and the tablet), so it doesn’t need high-speed throughput or responsiveness.