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.

Category: PC Tweakage

Remembering which tweaks worked

  • Rsnapshot vs. GVFS: Exclusion

    The backup scripts running on Mary’s folks’ PC kvetched on each backup:

    WARNING: Some files and/or directories in /home/ only transferred partially during rsync operation
    WARNING: /usr/bin/rsnapshot daily: completed, but with some warnings

    Poking around showed that the problem came from the .gvfs “directory” tucked into each home directory, which produced this unenlightening ls -al result:

    d????????? ? ? ? ? ? .gvfs

    Come to find out that it’s an old problem with mysterious causes that should be fixed by now; evidently I triggered it by installing basic Ubuntu-with-Unity and then installing the Xbubuntu desktop. Or something like that.

    Anyhow, the solution workaround involves an rsnapshot configuration entry that bypasses that directory:

    exclude .gvfs

    And then it Just Works.

  • MHV LUG Lightning Talk: Intro to NSA Hardware Implants

    Meme - Nixon - I see what you did there - 5x38k
    Meme – Nixon – I see what you did there – 5x38k

    I did five minutes of standup comedy at yesterday’s MHV Lug meeting, pointing out some of the more interesting ways to compromise a PC when you have an infinite budget for development and consumables.

    You don’t get my patter with the PDF (unless you had access to the room’s bugging hardware), but the links may come in handy in the unlikely event you haven’t been following the story closely.

    If you have a security clearance or are in line for one, you probably shouldn’t click on the link, because it contains copies of pages from the leaked NSA catalog:

    I See What You Did There – NSA Hardware Guide

  • Sandisk 32 GB Flash Drive: Now With String!

    So I drill two holes in the dust caps of those teensy Sandisk drives and added a cheerful red string:

    Sandisk 32 GB Flash Drive - cap string
    Sandisk 32 GB Flash Drive – cap string

    That this should not be necessary goes without saying…

  • Verifying a 32 GB USB Flash Memory Drive

    This resembles the 32 GB Micro SD card checkout, with the exception that, for some unknown reason, the available space doesn’t match up with the actual space occupied by the file. It also turns out that rsync deletes the incomplete file, rather than leaving a stub, which makes perfect sense, but was still a bit disappointing after two hours.

    I had two identical Sandisk Cruzer Fit Flash Drives, one of which appears here:

    32 GB Sandisk USB Flash Drive
    32 GB Sandisk USB Flash Drive

    Those squares are an inch on a side, so it’s a bit larger than the Micro SD card. Adding a lanyard loop on the plastic cap or a string between cap and drive seems like a great idea, because that little thing is certain to get lost.

    The snippets here represent a compendium of Things Done that happened over the course of two days; I didn’t save all the logs. The process started with the same 32 GB file of entropy I used for the Micro SD card:

    df -B1 /mnt/part2
    Filesystem       1B-blocks      Used   Available Use% Mounted on
    /dev/sdc1      31512350720 180424704 31331926016   1% /mnt/part2
    -----------------------
    time rsync --progress /mnt/part/Testdata/Testdata.bin /mnt/part2
    Testdata.bin
     31298191360  99%   14.18kB/s    0:39:38
    rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
    rsync: write failed on "/mnt/part2/Testdata.bin": No space left on device (28)
    rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
    rsync: connection unexpectedly closed (28 bytes received so far) [sender]
    rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
    
    real	126m20.505s
    user	3m6.393s
    sys	2m17.492s
    -----------------------
    time dd bs=8K count=20000000 if=/mnt/part/Testdata/Testdata.bin of=/mnt/part2/Test1.bin
    dd: writing ‘/mnt/part2/Test1.bin’: No space left on device
    3820963+0 records in
    3820962+0 records out
    31301320704 bytes (31 GB) copied, 7455.97 s, 4.2 MB/s
    
    real	124m15.970s
    user	0m1.607s
    sys	1m17.546s
    -----------------------
    truncate -s 31301320704 /mnt/part/Testdata/Testdata.bin
    -----------------------
    ll /mnt/part/Testdata/Testdata.bin
    -rw-r--r-- 1 ed ed 31301320704 Dec 24 18:13 /mnt/part/Testdata/Testdata.bin
    -----------------------
    time diff /mnt/part/Testdata/Testdata.bin /mnt/part3/Test1.bin 
    
    real	26m37.081s
    user	0m4.400s
    sys	0m52.723s
    

    Notice that the write speed runs around 4 MB/s, which is a lot slower than you might expect from a USB 2.0 device; as with a hard drive, the interface doesn’t limit the throughput! The read speed, on the other paw, trots along at about 20 MB/s.

    One of these will go to Mary’s folks as an online daily backup device; their PC will soon run a version of the rsnapshot scripts that back up our basement file server. It’s not off-site backup and it’s not proof against catastrophic hardware failure, but it should be good enough.

  • Xubuntu: Unpacking winmail.dat Files

    Mary’s compadres sometimes send her pictures of garden vegetables and quilting projects. Those pictures usually pass through Microsoft Outlook (or its ilk) and emerge in winmail.dat files that aren’t particularly useful in a Linux context. That page gives a good overview of the problem and how to resolve it; I’m just documenting the process here, so I can find it again.

    Start by installing both tnef and convmv. I think the latter isn’t needed in our situation, because most folks use flat ASCII file names that come through just fine.

    Save the attachment in, say /tmp and unleash tnef on it:

    cd /tmp
    tnef --file=winmail.dat
    

    That unpacks all the attachments into /tmp, where one may have one’s way with them.

    It’s not worth my effort to bolt that into the email programs and then maintain that mess across updates, so we’ll do it by hand as needed.

    Microsoft certainly had a good reason for inventing Yet Another Encapsulation Format, although I wonder why good old ZIP wouldn’t have worked nearly as well…

  • Optiplex 980 PCI Card Clamp Cover Repair

    The new-to-me Optiplex 980 has a tool-free clamp securing the PCI card brackets to the chassis, with a nice plastic dress cover that really finishes off that side of the case. Alas, it’s secured by five small heat-staked plastic pegs that I managed to shear off as part of a finger fumble that you’ll recognize when it happens to you and which I need not further discuss:

    Optiplex 980 PCI Clamp Cover - disassembled
    Optiplex 980 PCI Clamp Cover – disassembled

    So I drilled two slightly undersized holes for the tiniest screws in the Little Box o’ Tiny Screws:

    Optiplex 980 PCI Clamp Cover - drilling
    Optiplex 980 PCI Clamp Cover – drilling

    The two end plates sticking up are the only square parts of the cover, so that thing is actually clamped by the right-side plate and sheer will power. I ran the drill down 3 mm from the top of the post at the slowest manual jog speed from the Joggy Thing and I did not break through the top and did not hit that lathe bit under the cover.

    The screw threads and a dab of epoxy hold them in place:

    Optiplex 980 PCI Clamp Cover - tiny screws
    Optiplex 980 PCI Clamp Cover – tiny screws

    I’d like to say the finished repair looked like this:

    Optiplex 980 PCI Clamp Cover - in place
    Optiplex 980 PCI Clamp Cover – in place

    But, alas, the eagle-eyed reader will note that the screws are gone, replaced by two dabs of clear acrylic caulk; those faint threads and epoxy were no match for the snap of that latching lever and the slight distortion caused by the spring fingers applying force to the brackets.

    Ah, well, it’s close enough…

  • Upstart vs. NFS Mounts vs. Display Manager: Resolved!

    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:

    Xubuntu greeter - after NFS fix
    Xubuntu greeter – after NFS fix

    Until the next startup revision, anyway…