The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Author: Ed

  • Ubuntu 9.10 Partition Backup: ext4 vs partimage vs dd

    Ubuntu 9.10 uses ext4 filesystems by default and it’s usually a Good Thing to not mess with defaults early in the installation.

    That precept worked up to the point where I wanted to make a full-partition backup before doing something potentially catastrophic… at which point I discovered that the current version of System Rescue CD has a version of partimage that doesn’t know about ext4 filesystems. While FSArchiver looks promising, all I really wanted was a quick-and-simple backup and (possibly) restoration.

    So. Once again, dd to the rescue.

    This being a fresh installation, there’s not much other data to contend with. In fact, the installation uses under 3 GB, but it’s in a 32 GB partition. Wouldn’t It Would Be Nice If we could back up just the 10% of useful data and skip the rest?

    Reboot to System Rescue CD (hereinafter, SRC) and, while that’s happening, plug in a spare hard drive using a USB-to-SATA converter. That will be the “backup drive”.

    Mount the backup drive (which appeared as /dev/sdf1 and will be different for you) at /mnt/backup, which is conveniently provided by SRC:

    mount /dev/sdf1 /mnt/backup
    

    Mount the partition to be backed up (which is /dev/sda8 and will be different for you) at /mnt/custom, another existing mount point.

    mount /dev/sda8 /mnt/custom
    

    Zero out all the unused space by creating one honkin’ big file, then erase it leaving all those highly compressible zeros behind:

    dd bs=1M if=/dev/zero of=/mnt/custom/zero.bin
    sync
    rm /mnt/custom/zero.bin
    

    Unmount the partition, make the backup, and save the MBR while you’re at it:

    umount /mnt/custom
    dd bs=1M if=/dev/sda1 | gzip -c -3 > /mnt/backup/boxname-sda8-ext4-32GB.bin.gz
    dd bs=512 count=1 if=/dev/sda of=/mnt/backup/boxname-mbr.bin
    

    The bs=1M option sets a decent blocksize for the read operations, which gets dd trundling along at a pretty good clip by reducing the per-read overhead.

    The -c option tells gzip to pipe the output to stdout and not mess with the input file. The -3 says to not waste a lot of time trying to compress the data; much of the partition consists of raw binary executables, so there’s no point. The whole process will be limited by disk I/O speed, most likely.

    As it happened, the partition squeezed down into about 1.8 GB worth of gzipped backup file.

    Unmount the backup drive, reboot, and do risky things…

    As it turned out, I actually had to restore the partition.

    Once again, boot into SRC with the backup drive plugged in, mount the backup drive. Restoration is straightforward:

    gunzip -c /mnt/backup/boxname-sda8-ext4-32GB.bin.gz | dd bs=1M of=/dev/sda8
    

    Warning: if you bungle the target of that dd, you are so screwed.

    You’re both saving and restoring from a specific partition (/dev/sda8, in my case) within the drive, not the whole drive (which would be /dev/sda). Pay attention to what’s on the screen, check twice, and have a full-drive backup lurking in your fireproof safe…

  • Ubuntu Karmic 9.10 vs Separate X Sessions: Whack-a-mole!

    I’m in the process of figuring out which Ubuntu 9.10 desktop will work with my collection of hardware. That I got all this working successfully with Xubuntu 8.10 is most likely a testament to raw determination rather than good sense, but that’s water over the dam.

    The hardware:

    • Kensington Expert Mouse trackball (must use left-hand buttons)
    • Logitech Cordless Optical Trackman (must use right-hand buttons)
    • Wacom Graphire3 6×8 tablet (must swap side buttons)
    • Dell 2001FP 1600×1200 landscape display (left side)
    • Dell 2005FP 1680×1050 portrait display (right side)
    • nVidia GeForce 9400 GT dual-DVI card (using nVidia driver)
    • Dell Dimension 9150 deskside PC
    • Intel HDA Stac92 on-board sound (system sounds)
    • Ensoniq AudioPCI plug-in sound (unused right now)
    • Logitech USB audio headset (phone calls)

    General requirements:

    • Monitors must use separate X sessions, not Xinerama or TwinView
    • 2005FP must be rotated 1/4 turn CCW into portrait mode
    • *buntu preferred, due to large user base

    After some trial installations and moderate fiddling, some of which served as blog fodder:

    • Kubuntu doesn’t work, as KDE 4.x can’t handle separate X sessions
    • Xubuntu is OK, but tends to not have nearly the support of Ubuntu
    • Ubuntu comes heartbreakingly close to working

    Problems:

    • Rotating that monitor is a real problem
    • I don’t need RandR, but static rotation in xorg.conf causes other problems
    • The tablet wants to cover both screens, but that’s fixable
    • Trackball handedness requires careful FDI tweakage
    • Previous xorg.conf setup is not useful in the new world of FDI files
    • Most configuration documentation isn’t useful in that new world, either

    Installations on other household PCs  have gone reasonably well. Installation on my desktop box is in a spare partition, so I can return to What Worked without too much trouble.

    With all that in hand, here we go …

  • Monthly Aphorism: On Buying Test Equipment

    • When you’re buying test equipment, buy all the options.

    Mad Phil taught me, long ago, to buy everything available in one package, rather than try to figure out what you’ll eventually need and go through the justification process for each piece you forgot.

    That applied in a corporate setting, but it’s worth pondering even for your own gear: you’re likely to own it longer than the company producing it will offer parts.

    Or, these days, it’s more likely you’ll outlive the company…

  • WWVB Antenna: Oops!

    Ferrite inductor cores are notoriously fragile: they do not withstand much abuse at all. Given the amount of fiddling I’ve been doing with the Totally Featureless Clock, it was inevitable that I’d manage to drop the antenna…

    Broken ferrite bar antenna
    Broken ferrite bar antenna

    Gluing it back together with cyanoacrylate demonstrated that some things just never work the same. The antenna depends on a continuous flux path through the winding and even the minute gap introduced by the adhesive is enough to ruin the antenna.

    What they say about hearts and wheels is also true of ferrite bar antennas:

    “Once you bend it, you can’t mend it…”

  • More WWVB 3D Glitchiness

    The next day of WWVB Glitchiness, with the “!” limit characters changed to “|” to move them above the plot where they belong… which really doesn’t make that much difference.

    Gnuplot Glitchiness 2
    Gnuplot Glitchiness 2

    It’s worth mentioning that the WWVB transmitter is running in degraded mode during the day, down 3 dB, while they work on the antenna system. It probably doesn’t make much difference, given the noise around here, but you can see a definite jump as the frame marker pulses pop up off the floor.

    The clock synched with WWVB nine times during the Valley of the Shadow of Night. Each synch requires four consecutive glitch-free minutes, which obviously doesn’t happen during daylight hours.

    That’s with the antenna perched 3 cm over the top of the clock, aligned with the circuit board: the hardware seems quiet enough.

  • WWVB Glitchiness Histogram in 3D

    The character based Glitchiness histograms described there work pretty well for short time scales, but more than a screen full is too much. It turns out that Gnuplot can chew up the histograms and spit out a perfectly serviceable 3D map plot.

    The trick is to extract the histogram characters into a file, then persuade Gnuplot to regard the file as a binary array, with the ASCII character values giving the Z height of the dot for each XY cell.

    Click for bigger picture:

    Gnuplot Glitchiness
    Gnuplot Glitchiness

    The axes:

    • Front edge = 51 pulse durations, 0 – 1 second, 20 ms resolution
    • Right edge = 1363 histograms = 22.7 hours of WWVB reception
    • Z axis = histogram counts

    The flat plane has the vast majority of points having zero (or just a few) counts.

    The three front-to-back hillocks show the durations of the binary-zero, binary-one, and frame markers within each second; the resolution is 20 ms per sample perpendicular to those lines.

    The fuzzy mountain peaks along the left edge represent intense noise; you’re looking for the very few intervals of zero noise when the WWVB signal is readable. Those would be flat lines from the left to right edges, with just three bumps at the proper durations.

    The valley between the mountain peaks is the nighttime reception, when the noise drops to bearable intensity and RF propagation brings in enough WWVB signal to make a difference. The fact that you can see the proper pulse widths through much of the day suggests the signal is in there, but it’s so noisy you (well, I) can’t make make much use of it.

    How to get the graph…

    The clock produces three lines of output every minute that look like this:

    UTC: 10 013 16:36:00.0 Loc=11 Age=367   LY=0 LS=0 DST=0 Chg=0 UT1=1 Mon=1 DOM=13
    Glitchiness:  268 Histogram: W!ieTHG3A35412132.11...............................
    Light: 02CA Min=0005 Max=038B
    

    Extract just the lines with histograms:

    grep Histo 2010-01-12\ LR\ Window\ 80\ cm\ V\ on\ shelf\ -\ shield\ box.log > 1.txt
    

    Chop out the histogram data, which has a leading space:

    cut -d ':' -f 3 1.txt > 2.txt
    

    Discard the leading space and put the histogram text in the final file:

    cut -d ' ' -f 2 2.txt > histo.txt
    

    The last few lines of that file look like this:

    Q!njLDG896D6341...1................................
    BpgcSHD7B35531311.21..1..2....2....................
    L!jPQECA856231.221.....1.1................1........
    W!ieTHG3A35412132.11...............................
    

    You could do that all in one gargantuan Bash line, piping the results from one filter to the next, but that’s hard to explain.

    Now, fire up Gnuplot and have at it:

    gnuplot
    set xyplane at 0
    set zrange [0:128]
    splot 'histo.txt' binary format="%uint8" record=52x1363 using 1 with points lt 3 pt 0
    

    The doc suggests record=52xInf should work, but that draws a useless picture. If the record value is bigger than the number of actual records (found with wc -l histo.txt, the plot ends at the end of file; if it’s smaller, then you get only that many records. I suppose you could just use 99999; it’d work well enough.

    The 52 comes from the number of characters in the line: 51 histogram bytes per line, plus a newline character at the end. The newline produces the distinct line below everything else along the right edge of the plot. You could get rid of the newline characters and turn it into a binary file before plotting, but that’s sort of cheating, I think.

    You’ll recall the counting sequence in each histogram character:

    • “.” = 0
    • 1 through 9 = obvious
    • A through Z = 10 – 35
    • a through z = 36 – 61
    • ! = more than 61

    Unfortunately, the “!” has a lower ASCII value than the other characters, so those are the dots below the plane on the left side; they should be along the top surface. I’ll change that to “|” and make the answer come out right.

    From here on, it’s a matter of the usual Gnuplot futzing to get a decent-looking plot.

    Rotating the view may be useful. For example, set view 60,80 produces this:

    Gnuplot Glitchiness - rotated
    Gnuplot Glitchiness – rotated

    Now you’re looking more-or-less parallel to the samples for each minute. If you twiddled with the ranges, you could probably see the few valleys where it’d be possible to extract a valid time code.

    The alert reader will note that I used record=52×4344 to generate those plots. Homework: why?

  • Ubuntu Karmic 9.10: Wacom Graphire 2 HAL Configuration

    With yesterday’s background in hand, here’s the the fdi file for my Wacom Graphire 2 tablet that:

    1. Fixes the incomprehensible Wacom screwup in Ubuntu Karmic
    2. Swaps the two buttons on the side of the stylus

    This is based largely on the work found there, with the generalizations stripped out and the tablet identification changed just slightly.

    The file is stashed at:

    /usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi
    
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <deviceinfo version="0.2">
     <device>
     <match key="info.product" string="Wacom Graphire2 4x5">
     <merge key="input.x11_driver" type="string">wacom</merge>
     <merge key="input.x11_options.Type" type="string">stylus</merge>
     <merge key="input.x11_options.Button2" type="string">3</merge>
     <merge key="input.x11_options.Button3" type="string">2</merge>
     <append key="info.callouts.add" type="strlist">hal-setup-wacom</append>
     <append key="wacom.types" type="strlist">eraser</append>
     <append key="wacom.types" type="strlist">cursor</append>
     </match>
     </device>
     <!-- Wacom names "parser" -->
     <device>
     <match key="info.udi" contains_not="subdev_0">
     <match key="info.udi" contains_not="subdev_1">
     <match key="info.udi" contains_not="subdev_2">
     <match key="input.x11_options.Type" contains="stylus">
     <merge key="info.product" type="string">stylus</merge>
     </match>
     <match key="input.x11_options.Type" contains="eraser">
     <merge key="info.product" type="string">eraser</merge>
     </match>
     <match key="input.x11_options.Type" contains="cursor">
     <merge key="info.product" type="string">cursor</merge>
     </match>
     </match>
     </match>
     </match>
     </device>
    </deviceinfo>
    
    

    This button config works better for me:

    • front button = 3 — right mouse button
    • rear button = 2 — middle mouse button

    The tip switch remains the left button: if you try to configure the “mouse” to be left-handed, the tip switch functions as button 3, which is probably not what you really expected. The switch on the other end remains the eraser.

    Notice that the button configuration syntax is totally different from the evdev syntax that did basically the same thing yesterday: different drivers, different syntax.