Brother DS-620 on Linux
UPDATE: The drivers were temporarily unavailable; they seem to be up again, at least on the Brother US site: http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=ds620_all&os=128
I recently bought a Brother DS-620 document scanner that supposedly had support for Linux. It turns out it did, but only after a few quirks. I installed the official Linux drivers, and tried to scan a document using a GUI scanning application. Things were hanging and generally very unresponsive. I checked with the SANE command line tools, e.g. “sane-find-scanner”. It turns out things were indeed working, albeit very slowly. In dmesg I found a lot of messages like:
Jan 29 22:52:13 mchro-laptop kernel: [39172.165644] usb 2-1.3: reset high-speed USB device number 32 using ehci-pci
Jan 29 22:52:13 mchro-laptop kernel: [39172.333832] usb 2-1.3: reset high-speed USB device number 32 using ehci-pci
Jan 29 22:52:13 mchro-laptop kernel: [39172.501677] usb 2-1.3: reset high-speed USB device number 32 using ehci-pci
Jan 29 22:52:13 mchro-laptop kernel: [39172.669712] usb 2-1.3: reset high-speed USB device number 32 using ehci-pci
Jan 29 22:52:13 mchro-laptop kernel: [39172.837679] usb 2-1.3: reset high-speed USB device number 32 using ehci-pci
repeating several times every seconds. At this stage I was thinking that the Linux support was very crappy. After quite a lot of mucking around playing with capturing USB packets using Wireshark, it seemed the device itself was requesting a reset, and the Linux kernel was resetting it approximately 200ms later. Reading some Linux source code, and playing with USB quirks in Linux solved nothing.
Finally, I gave up and booted into Windows to check if the hardware had a defect. In Windows it worked without issues. I upgraded the firmware using the Windows utility to do so. After doing this the scanner worked without issue also in Linux.
So, all in all: There is official Linux support for this scanner, but it seems to require a firmware upgrade. This could definitely be better handled by the Brother documentation.
Stupid sys-admin’ing, and hooray for LVM and unnecessary partitions
The scenario is: almost finished migrating from an old server to a new server. Only a few steps remain, namely
- change DNS to point to new server
- wipe disks on old server
Done in this order, one might be unlucky that ssh’ing in to wipe the disks lands you on the new server. If you don’t discover this and run the command
dd if=/dev/zero of=/dev/md2
to wipe the disks you might run it on the new server instead. BAM: you just wiped the data of your new server. Fortunately, I realised my mistake after a few seconds, and was able to recover from this with only unimportant data loss, and a little panic.
/dev/md2 is actually a LVM physical partition, of which the first part now only contains zeroes; hereunder all the meta-data. LVM reported no volumes of any kind:
root@server# pvs -v
Scanning for physical volume names
root@server# lvs -v
Finding all logical volumes
No volume groups found
root@server # vgs -v
Finding all volume groups
No volume groups found
After a bit of Google’ing while panicking I found out LVM keeps a backup of all its metadata in /etc/lvm/backup, and that it could be rewritten to the physical volume using:
pvcreate -ff -u XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX --restorefile /etc/lvm/backup/vg0 /dev/md2
where XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX is the physical UUID from the backup file:
...
physical_volumes {
pv0 {
id = "XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX"
device = "/dev/md2" # Hint only ...
Unfortunately, I got an error:
root@server# pvcreate -ff -u XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX --restorefile /etc/lvm/backup/vg0 /dev/md2
Couldn't find device with uuid XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX.
Can't open /dev/md2 exclusively. Mounted filesystem?
lsof showed nothing accessing md2, but I guess something still had references to the logical volumes. I was unable to get it to work, so I decided to reboot (while making sure the system would come up, and nothing would try to mount the (non-existent) LVM volumes). After a reboot the command worked, but still no logical volumes:
root@server # pvcreate -ff -u XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX --restorefile /etc/lvm/backup/vg0 /dev/md2
Couldn't find device with uuid XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX.
Physical volume "/dev/md2" successfully created
root@server # sudo pvs
PV VG Fmt Attr PSize PFree
/dev/md2 lvm2 a- 648.51g 648.51g
root@server # sudo lvs
No volume groups found
Now I had a physical volume, and could use the vgcfgrestore command:
root@server # vgcfgrestore -f /etc/lvm/backup/vg0 /dev/vg0
Restored volume group vg0
root@server # sudo lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
...
home vg0 -wi-a- 20.00g
I now had my logical volumes back! Now to assess the data loss… The backup file /etc/lvm/backup/vg0 lists which order the logical volumes are stored. The first volume in my case was the “home” volume. Sure enough, it would no longer mount:
root@server # mount /dev/vg0/home /home
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg0-home,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
I actually had no important information on that file system, so I re-created it. Luckily the next volume was intact, and I could bring up the rest of the system without problems.
So to sum up: LVM keeps a backup of all it’s metadata that can be restored (after a reboot), but if your keyboard is faster than your brain it can be a good idea to keep an unused volume as the first logical volume 🙂
Making objdump -S find your source code
We all know the situation: We want to disassemble the most awesome pre-compiled object file, with accompanying sources, using objdump and we would like to view the assembly and C-code interleaved, so we use -S. Unfortunately, objdump fails to find the sources, and we are sad 🙁
How does objdump look for the sources? Normally the paths are hardcoded in the object file in the DWARF information. To inspect the DWARF debug info:
$ objdump --dwarf myobject.o | less
and look for DW_TAG_compile_unit sections, where the paths should exist like:
<25> DW_AT_name : C:/ARM/myfile.c
Of course, this might not be the path you have on your machine, and thus objdump gives up.
However, we can use an undocumented option to objdump: the -I or –include:
$ objdump -I ../mysources -S myobject.o | less
and voila, objdump finds the sources, inlines the C-code, and everything is awesome!
WordPress – mildly impressed
So, I just installed WordPress, because I was starting to have a too long mental list of things that I considered “blog-able”. My current estimate of what I will be blogging about is: Sysadmin’ing on a tight budget, Ubuntu Linux, MultiADM, various happenings in the Open Source world, and probably a bit about my everyday life as a student of Computer Science at Aalborg University, Denmark.
But back to the title of this post. For various reasons I have previously preferred other blogging software (primarily blogging software integrated with Typo3), but I finally gave in and installed WordPress. I deemed that I was simply missing out on too much: trackbacks, tags, anti-spam measures for comments. All this warranted a separate blogging system, and WordPress is pretty much the no. 1 blogging system in use.
My experience with it so far: Installation was okay, but it could have told me that the reason I didn’t get the fancy install-wizard was because I had forgot to give permissions for WordPress to modify its files. Minor nitpick: I decided to move my installation from /wordpress to just /. This resulted in all links still pointing at /wordpress. After a little detective work, and phpMyAdmin to the rescue to alter a couple of rows, and everything was working again.
But overall it seems WordPress is a pretty capable and extendable, and has a nice Web 2.0-like user interface. I’m pretty sure I will grow accustomed to it over time.