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

  • Ubuntu 8.10 Server Setup: Tweaks & Glitches

    Having just bumped the basement file server from Kubuntu 7.10 to Xubuntu 8.10, a few notes are in order…

    The general idea was to saw an existing 20 GB partition in half, maintain the existing 7.10 installation, and install 8.10 in the liberated part. The overview:

    • partimage — back up the 7.10 installation in sda6 and the data in sda7
    • resize2fs -p /dev/sda6 5G — squish the filesystem down
    • partimage — save the squished filesystem
    • cfdisk — delete sda6 and create a pair of 10 GB partitions sda6 and sda7
    • partimage — restore the squished filesystem to sda6
    • e2fsck -fv /dev/sda6 — prep it for resizing
    • resize2fs -p /dev/sda6 — expand to fill entire partition
    • tweak /etc/fstab to reflect the fact that sda7 has become sda8
    • reboot and shazam 7.10 started up just fine

    Then install 8.10 in sda7 and configure from there, using the 7.10 installation as a reference to help remember what’s needed.

    The only complication was that the Ubuntu 8.10 mini-ISO install enumerated the USB backup drive as sda, so things got a bit weird; evidently, the USB drive now has the grub MBR. Unplugging that drive, then deploying a bit of grub fu from SystemRescueCD fixed that up:

    • find /boot/grub/stage1 — appears in (hd0,5) and (hd0,6), thus sda6 & sda7
    • root (hd0,6)
    • setup (hd0)

    Then apply the relevant installation info from the series starting there, omitting all the user apps and foo-foos that won’t be needed on the basement box.

    Add useful server programs:

    • nfs-kernel-server
    • xinetd
    • swat

    There’s an authorization bug that may kill local login and sudo, as documented there, triggered when you configure CUPS printers (among other causes). The quick-and-dirty solution seems to be:

    • boot in recovery mode
    • remove samba*
    • install samba
    • install xubuntu-desktop

    It’s worth noting that I’d just finished configuring ssh for public-key logins, so I could get into the box from my Comfy Chair upstairs, but I couldn’t reconfigure anything because sudo segfaulted.

    Create mountpoints, then set up /etc/fstab to automount the various partitions:

    /dev/sda8 /mnt/music		ext3	defaults,noatime,auto,rw,nodev,noexec,nosuid 0 0
/dev/sdb1 /mnt/bulkdata		ext3	defaults,noatime,auto,rw,nodev,noexec,nosuid 0 0
/dev/sdb2 /mnt/diskimages	ext3	defaults,noatime,auto,rw,nodev,noexec,nosuid 0 0
/dev/sdb3 /mnt/userfiles	ext3	defaults,noatime,auto,rw,nodev,noexec,nosuid 0 0
UUID=069e50dc-1994-47d2-9c7e-0b5179a89041 /mnt/backup ext2 defaults,noatime,noauto,nodev,noexec,nosuid 0 0

    It would be more sensible to use UUIDs for those partitions, but that stuff hasn’t broken yet. If the USB backup drive enumerates as sda again, then I’ll be forced to tweak it.

    Add stanzas like this to /etc/exports:

    /mnt/bulkdata *(rw,async,subtree_check,root_squash,no_all_squash)

    That gets the files served to the other boxes.

    Install Turboprint and tweak the printer drivers accordingly.

  • XFCE Keyboard Mapping: Random Jots

    The multimedia keyboard on this box doesn’t work, which likely has something to do with the fact that I’m running separate X sessions on two monitors. I described what does work on my laptop there.

    Here are some random & incomplete notes, with no good outcome…

    Key and keyboard definitions are in /usr/share/X11/xkb/keycodes with:

    • xfree86 mapping the symbolic name (as in <I1E>) to key number 158
    • inet mapping from XF86AudioRaiseVolume to symbolic name

    The Microsoft Comfort Curve Keyboard 2000 V1.0 (don’t you love how they name things?) seems to be a subset of the microsoftprousb keyboard definition.

    Manually assigning a key works like this:

    xfconf-query -c xfce4-keyboard-shortcuts \
  -p /commands/custom/XF85AudioRaiseVolume \
  -t string
  -n
  --set="amixer -c 0 sset Master 10%+"

    Use xev to find key numbers, which turn out to be more or less common values (contrary to what I initially thought)…

    • Back = 234 I6A
    • Forward = 233 I69
    • Vol down = 174 I2E
    • Mute = 160 I20
    • Vol up = 176 I30
    • Play/Pause = 162 I22
    • Home = 178 I32 XFree86HomePage
    • Search = 299 I65 XFree86Search
    • Email = 236 I6C XFree86Mail
    • Calculator = 161 I21 XFree86Calculator

    The first two keys are defined in nav_common and the rest are in media_common, with the combination in, of course, media_nav_common.

    But none of this actually works.

  • Recovering JPG Images From Damaged Flash Memory

    My DSC-F717 just crashed as I took a picture in the Basement Laboratory; it stalled while writing a picture to the memory stick. This camera is known to have problems with its ribbon cables and I’ve fixed it a few times before, but right now I have other things to do. Who knows? Maybe it’s a different problem altogether.

    Thus, the pertinent question is how to grab the image files from the Memory Stick, even with a damaged filesystem. This trick will work with any memory device, so it’s not just a Memory Stick thing.

    The camera crashed with the Memory Stick activity LED stuck on. Turning the camera off didn’t work: it jammed in the power-down sequence. So I poked the Reset button, which snapped the camera back to 1 January 2002, just after midnight. Alas, it now couldn’t read the Memory Stick, which meant either the filesystem is pooched or the camera’s card socket has gone bad again.

    Mmm, do you know where your camera’s Reset button is? It might not even have one, in which case you just yank the battery. If you can yank the battery, that is.

    Anyhow…

    With the camera turned off: extract the memory card, poke it into a suitable USB card reader, and poke that into your PC (running Linux, of course).

    If the filesystem isn’t too badly damaged, you’ll probably get a popup asking what to do with the new drive (the memory card). Dismiss that, as you don’t want anything writing to the memory without your explicit permission, which you won’t give.

    Figure out which device corresponds to the card and which partition to use:

    dmesg | tail
[29846.600524] sd 5:0:0:2: [sdd] 1947648 512-byte hardware sectors (997 MB)
[29846.606022] sd 5:0:0:2: [sdd] Write Protect is off
[29846.606030] sd 5:0:0:2: [sdd] Mode Sense: 23 00 00 00
[29846.606033] sd 5:0:0:2: [sdd] Assuming drive cache: write through
[29846.608748]  sdd: sdd1

    In this case, the Memory Stick was intact enough to have a valid partition table, so it could be successfully mounted. However, you don’t want any attempt to write the data, just to keep a bad situation from getting worse. You do that by mounting the device read-only:

    sudo mount -o ro /dev/sdd1 /mnt/part

    You’ll need a suitable mount point; I created /mnt/part early on to hold manually mounted disk partitions.

    The FAT filesystem seemed to point to valid files, but attempting to display them didn’t work. So unmount the device before proceding:

    sudo umount /dev/sdd1

    Switch to /tmp or anywhere you have enough elbow room for a few files the size of the memory card.

    Run dd to make a bit-for-bit copy of the entire drive:

    sudo dd if=/dev/sdd of=memstick.bin bs=1M

    The bs=1M should dramatically speed up the transfer; the default is, IIRC, 512 bytes.

    After this, everything you do uses memstick.bin, not the memory card itself. If you’re paranoid like me, you’ll make a copy of the file before you do anything hazardous. You could even make two copies directly from the memory card and compare them, which might be instructive.

    To find your precious JPG images among the rubble, look for their magic Exif headers:

    strings -t x memstick.bin | grep Exif
  68006 Exif
 258006 Exif
 680006 Exif
 848006 Exif
 a18006 Exif
 bf0006 Exif
 e00006 Exif
 fe8006 Exif
11e8006 Exif
1420006 Exif
... snippage ...

    Because the strings search ignores the (presumably broken) FAT directory structure, you’ll find all the image files on the drive, whether or not they’ve been deleted, partially overwritten, or whatever. This is great for forensics and terrible if you’ve got something to hide. You have been warned.

    The -t x parameter returns the string’s starting offset in hex, which you need to find the actual starting offset of the file: it’s 6 bytes lower! Your mileage may vary, so be prepared to fiddle around a bit.

    You could write a bunch of code to parse the JPG header and extract exactly the number of bytes required, but this is no time for subtle gestures. I just yank out whatever the largest possible image file could be, because image-processing programs only process the valid stuff anyway. So, knowing that this camera produces images in the 2.4 MB range, this extracts the first image:

    dd if=memstick.bin of=image.jpg bs=$((16#1000)) count=1K skip=$((16#68))

    The $(( … )) notation evaluates the numeric expression within and the 16#… notation expresses a hexadecimal value.

    Soooo, bs=$((16#1000)) says that the blocksize is 4096 bytes, which you can deduce from the fact that all the Exif headers start 6 bytes from a multiple of 0x1000. Again, your camera may do things differently, but the general notion should get you started.

    If you’re fussy, you’ll note that the headers are actually on multiples of 0x8000 bytes, but using 0x1000 means you can read the high-order digits right off the strings dump. Why make things more complicated than necessary?

    Given a 4K blocksize, count=1K extracts a 4MB chunk: 1024 blocks of 4096 bytes each. That’s larger than the largest possible image file from this camera; adjust it to suit whatever you expect to find. Don’t be stingy, OK?

    The skip=$((16#68)) says to begin extracting data 0x68 blocks into memstick.bin. You read that value directly from the strings output, which is easy enough.

    You could write a tidy Bash script to eat the strings values and spit out the corresponding file chunks. I had few enough images this time to just do it manually, which beats having to debug some code…

    Good luck!

  • Devil’s Pie for Xubuntu

    I have six workspaces set up on my left monitor (and, perforce, six on the right, where I need only two) with more-or-less ritualized contents: email, browser, terminals, simulation, graphics, and whatever else comes to mind.

    While I’m not attached to the notion of a particular program being on a specific workspace, I really don’t want to arrange all the programs every time this thing lights up. Alas, Xubuntu’s XFCE desktop doesn’t offer much control over where windows appear, particularly for KDE programs that don’t seem to play nicely with the rest of the desktop.

    Devil’s Pie (installable with package devilspie) solves some of that problem. It doesn’t handle dual monitors with separate X sessions, is utterly undocumented, requires more than a little patience to get working, and produces baffling error messages. But it does essentially everything I need doing.

    So…

    Install devilspie, which is at 0.22 -1 in the Xubuntu 8.10 universe repository.

    Create ~/.devilspie to hold configuration files and create the following files therein:

    firefox.ds

    ; Force Firefox to workspace 2
(if
(is (application_name) "Firefox")
(set_workspace 2)
)

    gimp.ds

    ; Force Gimp windows to workspace 6
(begin
(if
  (matches (application_name) "GNU Image Manipulation Program" )
  (begin
    (set_workspace 6)
  )
)
)

    kmail.ds

    ; Force Kmail windows to workspace 1
(begin
(if
  (matches (application_name) "^KMail$" )
  (begin
    (set_workspace 1)
    (geometry "960x1200+0+0")
  )
)
)

    The syntax is fairly obvious, the semantics rather less so. The man page is basically useless and has been that way forever, but a true heroine has already dug through the source code and documented what you need to know. Go there and read.

    If you’re doing system-wide configs for all users, you can allegedly put those files in /etc/devilspie, but I haven’t tried it out yet.

    The (matches string regex) conditional allows you to do regular expression matching, which is more flexible than string equality (is string string) or substring (contains string substring) matching. What you see above represents cruft from figuring out what works.

    Use the (begin …) syntax to wrap multiple statements in a single file; the parser seems to choke on anything more than one.

    Put (debug) in whatever new config file you create, (re-)start devilspie from a terminal, then start the program you’re trying to control. You’ll get a torrent of information about all the various & sundry windows; pluck readable bits from them and hammer out some regex matches. Tuck one of these into a (begin …) stanza along with stuff you’re trying to make work.

    Attempting starting devilspie before X comes up causes great discomfort, so you can’t start it from /etc/rc.local.

    Instead, add it to XFCE’s Autostarted Applications list: System Settings -> Session and Startup -> Application Autostart, then click the Add button to put /usr/bin/devilspie in the list.

    Memo to Self: this will be ideal for Mom’s PC beyond 8.04, assuming KDE continues to favor foo-foos over basic functionality.

  • Xubuntu Multimedia Keyboard Keys

    I still haven’t figured out why the audio volume & mute keys on my desktop box’s keyboard don’t work, but this process sets ’em up on my Dell Inspiron E1405 laptop… which I just reloaded with Xubuntu / XFCE 4.6 using more-or-less the procedure described starting there, including saving, blowing away, repartitioning, and restoring the Windows partition.

    If the audio mixer icon doesn’t show up on the top XFCE panel, other-click the panel -> Add New Items -> Mixer to get it there.

    Then do System Settings -> Keyboard -> Layout. Verify that you’re using the default system keyboard layout, as that’s what I’m doing on the laptop and it works. The desktop, now, that’s another matter; I think having two X sessions confuses it mightily.

    Then click the Application Shortcuts tab, click Add, and type in each of these…

    • amixer sset Master 10%+
    • amixer sset Master 10%-
    • amixer sset Master toggle

    For each command, click OK after typing. You’ll get another pop-up, at which point you press the corresponding volume / mute key.

    Note that the Master keyword is case-sensitive and may be something entirely different on your box. Use amixer to find out what you should be typing, thusly:

    amixer
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 27 [87%] [-6.00dB] [on]
  Front Right: Playback 27 [87%] [-6.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 245 [96%] [-2.00dB]
  Front Right: Playback 245 [96%] [-2.00dB]
... snippage ...

    Shazam: audio control should then Just Work…

    The irony of having to futz around that much before having something Just Work is not lost on me. Really.

  • Changing the Xubuntu 8.10 GDM Login Splash Screen

    OK, this is frippery and I admit it, but I vastly prefer my login background to theirs…

    My GDM background
    My GDM background

    The right way to change the background is to create a whole new gdm theme and then fiddle gdm to use it. Easier than that: tweak an existing theme’s XML file to point to your image.

    The default Xubuntu theme for gdm is in /usr/share/gdm/themes/xubuntu, so cd there. This is a command-line thing …

    The background is stored in, oddly enough, background.png, a 1680×1500 image that doesn’t mind being stretched or cropped or smushed to fit your screen.

    Copy your favorite background image to that folder, perhaps renaming it on the fly:

    sudo cp /path/to/my-new-background.png danger.png

    I don’t know if JPG images will work, as I just saved that screen capture as a honkin’ big PNG; knock yourself out trying other formats.

    Adjust the first stanza in Xubuntu.xml to point at the new background file:

    <!-- background -->
−
<item type="pixmap">
<normal file="danger.png"/>
<pos y="0" x="0" width="100%" height="100%"/>
</item>

    Squash the Xubuntu logo (in logo.png) so it’s not so obtrusive and move it out of the way of the background text. Modify the stanza that displays the logo file:

    <!-- ubuntu logo -->
−
<item type="pixmap">
<normal file="<strong>logo.png</strong>" alpha="1.0"/>
<pos x="<strong>50</strong>%" y="<strong>70</strong>%" width="scale" height="<strong>10%</strong>" anchor="n"/>
</item>

    Log out. Enjoy…

    FWIW, replacing the background is far easier in KDE (3.x, at least), which has an actual GUI interface (System Settings -> Advanced -> Login Manager). But, of course, KDE 4.x is on the outs with this dual-screen box.

    And don’t you love those Beware Static Damage warning stickers on the Nostromo’s scuttling control panel?

    Default Xubuntu GDM background
    Default Xubuntu GDM background

  • UUIDs for External USB Drives

    I use an external USB drive to hold daily file-server backups. My backup scripts mount & unmount the drive around the rsnapshot backup, which allows the drive to spin down for most of the day, plus protecting it from random finger fumbles and possible system breakage. Whether that affects the drive’s long-term reliability or not, I cannot say, but it’s been chugging along for a year so far.

    In any event, hotplugging precludes the usual /dev/sd?? notation notation for disk mounting, because the drive tends to have a different device name depending on what’s plugged in. It turns out one of my printers has a USB port for memory gadgets (from whence it can print directly, not that I ever want to) which looks like an unmounted drive which may come up either before or after the USB backup drive.

    Sooo, I must use the drive’s UUID (Univerally Unique ID). Or, more accurately, the filesystem’s UUID, which has some implications.

    Figure out which drive it is by looking in dmesg

    [   18.436000] scsi 4:0:0:0: Direct-Access     Maxtor   OneTouch         0122 PQ: 0 ANSI: 4
... snippage ...
[   18.444000] sd 4:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
[   18.444000] sd 4:0:0:0: [sdd] Write Protect is off
[   18.444000] sd 4:0:0:0: [sdd] Mode Sense: 2d 08 00 00
[   18.444000] sd 4:0:0:0: [sdd] Assuming drive cache: write through
[   18.448000] sd 4:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
[   18.448000] sd 4:0:0:0: [sdd] Write Protect is off
[   18.448000] sd 4:0:0:0: [sdd] Mode Sense: 2d 08 00 00
[   18.448000] sd 4:0:0:0: [sdd] Assuming drive cache: write through
[   18.448000]  sdd: sdd1 sdd4
[   18.456000] sd 4:0:0:0: [sdd] Attached SCSI disk
[   18.456000] sd 4:0:0:0: Attached scsi generic sg4 type 0

    The sdd1 partition occupies nearly the entire drive and holds the backup files. The sdd4 partition is a tiny FAT thing for the Maxtor utilities that set the spin-down time and suchlike. Every now and then you do need a Windows box, alas.

    Find the UUID by looking in /dev/disk/by-uuid/

    lrwxrwxrwx 1 root root 10 2009-03-21 08:08 069e50dc-1994-47d2-9c7e-0b5179a89041 -> ../../sdd1
... snippage ...

    Plunk that in /etc/fstab

    UUID=069e50dc-1994-47d2-9c7e-0b5179a89041 /mnt/backup ext2 defaults,noatime,noauto,nodev,noexec,nosuid 0 0

    Then I (and, more importantly, my scripts) can mount the drive with a simple sudo mount /mnt/backup regardless of what drive name it sports today.

    The UUID comes from the filesystem written in the partition, so rebuilding the filesystem with mke2fs gives the partition a new UUID; the old entry in /etc/fstab stops working. You can use tune2fs to copy the old UUID to the new filesystem or do as I do: just plunk the new UUID in /etc/fstab.

    The system reads the partition’s UUID when it boots, so regenerate the /dev/disk/by-uuid entry using sudo udevtrigger or replugging the drive (which is awkward because it’s in the basement and I’m upstairs). That also re-jiggers all the hotpluggable devices, which shouldn’t matter, right?

    The reason I use mke2fs rather than sudo rm -rf /mnt/backup is that it takes basically forever to delete a whole drive full of files.