Technology
Upgrade Fedora 15 to Fedora 16
by balleman on Dec.29, 2011, under Linux
The desktop upgrade from Fedora 15 to Fedora 16 was about on par with the upgrade from 14 to 15. Instead of the disaster that is Gnome 3, we’re instead greeted with GRUB 2 and new systemd quirks.
The main portion of the upgrade itself went smoothly. No unexpected surprises from anaconda until the notice that the bootloader didn’t install right.
GRUB 2
So apparently Fedora 16 incorporates GRUB 2. While its error messages seem far friendlier than GRUB classic, I really did not delve into all of its supposed benefits. One downside is that when built with RAID support (which I seem to need since my /boot partition is mirrored), the core.img file ends up >32KiB, and thus does not fit in the post-MBR gap present on my drives.
To address this, I used a gparted live CD and resized and moved the first partition of each drive (which happen to be NTFS drives for my Windows 7 install, one of which was the system volume). This provided a 2MiB gap between the MBR and first partition. Booting back into the Fedora 16 rescue mode and using grub2-install on both drives successfully installed GRUB2 and, following a reboot, allowed Fedora 16 to load.
Unfortunately, these partition table and file system hijinks left Windows 7 with a bit of a problem, seeing as it would not boot. The recommended method of using the Windows 7 installer’s “Startup Repair” feature was unsuccessful. The “bootrec /fixboot” would not fix it, giving an “unsupported filesystem” error. Using diskpart to set the Windows partition to active appears to resolve this, and the fixboot succeeds. Naturally, I ran fixmbr at some point, which wiped out GRUB again, and thus it had to be reinstalled. Success with booting both Windows 7 and Fedora 16 was then achieved.
NFS mount
The machine has one NFS share mounted via /etc/fstab. After the upgrade, this would fail to mount during boot, but would have no difficulty being manually mounted after boot. After researching a variety of wrong paths with various systemctl changes, the one I found to resolve this was “systemctl enable NetworkManager-wait-online.service”.
Update 1/8:
The upgrade of my HTPC wasn’t too painful. Mucked with partitions to make room for GRUB2 ahead of time, had to change my lirc init script to not confuse systemd, disable screensaver in gnome 3 (yes, shouldn’t be using gnome to run mythtv – need to add that to the list), re-enabling services that weren’t automatically figured out from existing init scripts, switched mounts from /dev/md* to UUID-based to get the ordering right in the new boot sequence, mythtv ownership changes, etc, etc.
GraphViz
by balleman on Aug.12, 2010, under Technology
A while back I had to diagram interactions between components in a KRB5+LDAP+NFS4 system. Instead of laying this out by hand, I went with GraphViz. I think I had known of its existence, but when I forget what the name of it is, I tend to look up this diagram of Ender stories from Wikipedia. The diagram I made is below, if you happen to have a Celerra laying around. Recently, I’ve started playing with GraphViz again to do some stuff for my current job, but have found out that one thing it doesn’t really do are the directory-tree type layouts one expects to find in most file managers today. Maybe they’ll add that as a different layout engine at some point.
DNSSEC at home
by balleman on Jul.17, 2010, under Happenings, Networking
Since the root zone was signed this week, I spent a bit of time today setting up DNSSEC validation on my home recursive server. It was relatively painless (so far). I did opt to not enable DLV though – not fond of it receiving every host name I resolve.
Resources:
- RHEL RPMs from http://people.redhat.com/atkac/bind/5.6-test/ – if someone finds a better source for BIND 9.7+ RHEL RPMs, I’d like to know. I had no luck building from the Fedora SRPMs.
- http://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers – instructions for setting up BIND to use the root key.
- http://fanf.livejournal.com/107310.html – A more thorough walk-through of setup.
One resource I would have liked to find and could not was a deliberately unvalidatable non-root zone/record that could be used to see a validation failure. If anyone knows of or finds such a thing, please pass it along. Now we get to wait for .com, .net, etc, to catch up to .bg and .uk in the publishing of DS glue for deeper validation.
UPDATE 7/22/10: Just found the following site which makes available bad records for testing purposes: http://dnssec-tools.org/testzone/index.html
Device Convergence: GPS
by balleman on Jun.01, 2010, under Technology
Are cell phones yet to the point where they can replace a hand-held hiking GPS? Up until recently, I’ve been quick to dismiss this notion. The announcement of Garmin’s latest hand-helds that appear to be moving closer to their cell phone brethren has me wondering. Reports of the new touch-screen interface are about as bad as one would expect.
So, what are the issues? I tried my G1 running OruxMaps on a 3.5hr / 10 mile hike in the mountains on Monday to get a better perspective.
Battery Life. It barely survived. I would probably expect twice the battery life from my Garmin GPSMap 76S with a constantly running display. Can the battery life issues be solved with an external AA-based battery pack to keep the cell phone charged? I have no experience with these things. Reviews indicate that ones without regulators aren’t worth much. I might have to try one.
GPS Hardware. Cell phones may have GPS receivers, but it is not their primary function. Most Android phones I’ve looked at seem to use the Qualcomm gpsOne chipset instead of a dedicated chipset such as the oft-mentioned SiRFstar III. This is a cause for concern, since gpsOne currently seems to lack support for WAAS and likely is not as sensitive as the SiRFstar. The upside of gpsOne is that AGPS will provide a faster lock when within range of the cell network.
Usability. Another major hurdle is the availability of high quality GPS software for the phone. I’ve tried Maverick Lite, OruxMaps, and My Tracks and found them all to be lacking the necessary features of a hand-held GPS. My Tracks is the Google-sponsored outdoor activity tracking app that was very recently open-sourced. Maverick and Orux both provide offline map access (another must), but they seem to accomplish this with saved graphic tiles and not vector data as would be desired. Any new GPS solution I get should have high-resolution topo maps included.
Durability. Hand-held GPS receivers tend to be waterproof and a bit rugged. I’ve dropped my GPSmap 76s a number of times – and it once fell off my bike at 15+ mph. There’s no way any phone I’ve owned would be happy with that kind of treatment.
Bottom line? Not sure yet. I do think the concept of a hand-held GPS is already starting to fade. I’m not ready just yet to give mine up in favor of the cell phone. I hope the newly open-sourced My Tracks starts gaining some useful hand-held features.
Tales of X10
by balleman on May.28, 2010, under Happenings, Technology
A few years ago, I decided to improve the light switch situation in my garage. The garage had lights at either end controlled by pull strings. It was a frequent hassle to walk from one end to the other, often tripping over a variety of obstacles, to get both of them on or off. Having already deployed X10 to control a few things around the house, it seemed like a reasonable and economical idea to use X10 here as well. I used two LM15As for load switching, two SS13As for control near both doors in the garage, and an RR501 to tie everything together. Initially, the project seemed to be a great success.
Then it becomes apparent that the SS13As are not that great. The adhesive backing would refuse to stick to the garage wall for extended periods of time, necessitating the addition of some screws to provide a slight ledge for them to sit upon. They are also battery powered, and the stock batteries were nearly useless in cold weather. Naturally, the colder times of year require the use of lights in the garage more often, and it became incredibly annoying to have to warm the switch with your hand and make multiple attempts to turn on the light… when the pullstring that otherwise would work is in reach. My suggestion is to never use SS13As in anything but warm environments, and probably just avoid them altogether. The one I had used inside would “forget” its code assignments and the coldness of the window sill was enough to keep it from working well.
To fix these issues, I revisited the idea of wiring regular three-way switches in the garage. With the layout of the existing wiring, even the most creative ideas would require two new wires run the length of the garage, with one of them likely needing to be a 3-conductor that I don’t happen to have laying around. And copper isn’t really cheap right now. So, X10 was again looked at for a solution.
I decided to go with hard-wired X10 controllers, specifically the XPT4-W. I installed these near existing wire locations with a minimal of effort – maybe 3 hours total. So, now I have fully functional control of my garage lights (probably even in cold weather), and didn’t need to run crazy amounts of cable for three-way switches.
