Resolution Changer

We’ve probably all come across annoying programs that insist in taking over your monitor to run in ‘full screen’ mode, but are designed only for a particular monitor resolution, leaving nice big black borders when running a higher resolution.

I’ve been using just such a program a lot lately that is designed to only run at 800×600 resolution. Even on my laptop this ends up with huge amounts of wasted space, plus all the text and images are a bit too small to see comfortably. I’ve been manually switching my display to 800×600, but that gets old fast. I figured there must be a better way to do this.

It turns out that there is, and it’s a tiny program called Resolution Changer. This little gem weighs in at only 84k (when’s the last time you installed anything smaller than a megabyte?) and can switch to arbitrary resolutions, run a program, and then when the program finishes switch back to the original resolution.

I downloaded this program, and copied it into “C:\Program Files\reschange\”. Then I went to the shortcut which starts the annoying program and edited the properties so that this:

“C:\Program Files\reschange\reschange.exe” -width=800 -height=600

was added to the start of the “Target:” in front of the program executable that was previously there.

Voila! Now when I click to start that program, my display changes to 800×600. When I exit the program it switches right back to the original resolution.

Sometimes it’s best NOT to follow directions…

Had a problem with my main Solaris server in Taipei today which runs Solaris 10 6/06. It hung and when I rebooted it came up with this error:

WARNING – The following files in / differ from the boot archive:
cannot find: /etc/devices/mdi_ib_cache: No such file or directory
/kernel/drv/md.conf
The recommended action is to reboot and select “Solaris failsafe”
option from the boot menu. Then follow prompts to update the
boot archive.

I rebooted into failsafe mode and blindly followed the directions given:

/dev/dsk/c0d0s0 is under md control, skipping.
To manually recover the boot archive on a root mirror,mount the first
side (the one that the system boots from) and run:

bootadm update-archive -R <mount_point>

In summary, I did the following:

# mount /dev/dsk/c0d0s0 /mnt
# bootadm update-archive -R /mnt
Creating ram disk on /mnt
updating /mnt/platform/i86pc/boot_archive…this may take a minute
# reboot

WRONG! WRONG! WRONG!

This ended up updating the boot archive on only one side of the mirror. The other side of the mirror was not modified. Hence, the mirrors became out of sync. However, the configuration is still set to boot from a mirrored device. This quickly gets you to this point on reboot:

NOTICE: /: unexpected free inode 9864, run fsck(1M)
The / file system (/dev/md/rdsk/d1) is being checked.

WARNING – Unable to repair the / filesystem. Run fsck
manually (fsck -F ufs /dev/md/rdsk/d1).

Yes, you really only need to update the boot archive on the first device in the mirror as that’s the one the system boots from. However, once it’s bootstrapped the kernel, it’s going to mount the full mirror, and the full mirror now has different contents on each side. Depending on what’s read from which side of the mirror, you’re likely to end up with some inconsistency detected.

The correct way to do things would be:

# mount /dev/dsk/c0d0s0 /mnt
# vi /mnt/etc/vfstab
(Change root mount device to the unmirrored device /dev/dsk/c0d0s0.)
# bootadm update-archive -R /mnt
Creating ram disk on /mnt
updating /mnt/platform/i86pc/boot_archive…this may take a minute
# reboot

You would then need to rebuild the mirrored root after you get the system back up.

However, that is not the end of the story. It turns out that all this boot archive rebuilding won’t fix this particular problem. This error message is normally generated when the files in the bootstrap image don’t match those in the actual filesystem. This is your heads up that the state during bootstrap doesn’t match what’s on the actual root filesystem. Going through the exercise of rebuilding the boot archive is supposed to get things back to a point where the bootstrap image and the filesystem match.

However, in this case the file /etc/devices/mdi_ib_cache is missing on the actual root filesystem. So the error message is actually wrong. If you rebuild the boot archive it’ll fail to add the file, because it doesn’t exist. And the next time you boot it’ll give you the same error again. The error is that a file is missing on the actual root filesystem, not that the boot archive doesn’t match the root filesystem.

And it turns out this file is completely unimportant. If it’s screwed up or missing, the system will replace it automatically and merrily go on its way. In other words, it’s absolutely no big deal if it’s missing on reboot.

The original error message I saw also had this advice:

To continue booting at your own risk, clear the service:
# svcadm clear system/boot-archive

This ‘at your own risk’ option actually turns out in this case to be the correct remedy for this problem.

So to summarize:

  1. The original error message misstates the problem as files being different instead of one being missing
  2. The recommended fix does not solve the problem
  3. The instructions for the recommended fix gives specific advice for mirrored filesystems that will damage your filesystem and waste lots of time undoing the damage
  4. The missing file is actually completely unimportant
  5. The ‘at your own risk’ option is the correct way to solve the problem

It looks like everything but point 3 is covered by BugID 6256649, however the public description is not useful. I didn’t find a bug report covering the problem with the instructions for rebuilding the boot archive on mirrored filesystems being wrong.

I also don’t know why the thing hung in the first place. Nothing in /var/adm/messages.

First WordPress plugin

For some reason wordpress hasn’t fixed a bug in how non-ASCII emails are sent even two years after the bug was submitted. As a result, the subject lines of emails from blogs using non-ASCII characters are sent using unencoded Subject headers. This not only violates email standards, but also tends to cause such mails to be tagged as spam, not to mention that the resulting subject line is unreadable.

Since the wp_mail() routine is one that is plugin-replaceable, I whipped up a plugin based on kpumuk’s solution posted in the bug report. It was surprisingly simple to make the plugin and now the notification emails I get aren’t all scrambled.

Plugin: WP RFC2047

Upgrades

Finally got around to upgrading to WordPress 2.0.4 which has been out for a while. I was kinda reluctant to do it because I know from upgrading other PHP software once you’ve made lots of modifications it gets tricky to upgrade. Fortunately WordPress is a bit better designed in this area and I had managed to keep most of my mods limited to the Ocadia themes file. One place where I’d hacked the main files was in the get_archives function which I modded to show months in Chinese and English. Fortunately I had backed everything up and it was a simple matter to pull out those mods and stick them in the Ocadia theme directory instead.

I’ve also enabled the ‘Blogroll’ feature, so if you look over in the sidebar you can see some of the blogs I read.

What I’m listening to

I’ve been playing around with WordPress today, customizing the Ocadia theme I use a bit (mostly just small tweaks). The big change is I added a plugin to show the music I’m listening to.

My first attempt was to use my last.fm account to generate charts. Unfortunately after a lot of searching I couldn’t find a theme that I both liked and also would fit in my sidebar. The only one I was happy with didn’t use transparency, so it looked stupid on Ocadia’s sidebar background.

I then settled on using the WP iTunes plugin along with iTunesBlogger. WP-iTunes actually does a bit more than I wanted, so I hacked it up a bit to take out the Amazon features (which didn’t work too well with my diverse music library anyways) and changed the presentation routine.

It’s surprisingly easy to hack on WordPress. I’ve only done a little bit of PHP programming before but it’s like a cross between C and Perl, so it’s pretty easy to make it up as I go along.

What I’m having problems with now is the CSS features on how the song information is displayed. I know so little about CSS now that I was only able to make a fairly crudely formatted list. I kinda know what I want it to look like, I just don’t know enough CSS to do it.

I also need to look into adding a spell-check plugin.

I’m Gonna SCREAM+

(This post isn’t about the new Tommy Heavenly6 single, it’s about Migrating from LiveJournal to WordPress.)

I’ve decided to migrate my blog from being hosted on LiveJournal to hosting it on my own server using the open-source WordPress software. I primarily blame Suresh for asking me to set up a blog for APCAUCE, which lead me to decide to try it on for myself first. It probably would have been better to have set it up on the APCAUCE web site first, but anyways…

One of the things I liked about WordPress was that it had a feature to import blog entries from LiveJournal, which would make transitioning a fairly smooth process. It was only after I got into it that I realized how limited the import process was. Turns out that migration isn’t so easy, unless you have very low standards.

The first problem is with LiveJournal’s export tool. It has two major limitations: 1) You can only export one month at a time and 2) comments are not saved.

There are various LiveJournal clients out that that are not limited like that, and I eventually settled on using jbackup.pl, a tool maintained by LiveJournal. This is a nifty tool that will backup your LiveJournal complete with comments to a GDBM database on a Unix server.

But there’s problems with it as well. The first problem is that it doesn’t output in the same XML format as the WordPress import tool expects. For this you need to use a hacked version of jbackup.pl which I found at this wiki entry on migrating from LiveJournal to WordPress. This version has been modified to output XML in a format that the import program can understand.

That turns out not to be the end of the problems. The next problem is that the import program can’t handle comments, because the export tool it works with doesn’t support them. So back to that wiki entry for a modified livejournal import tool.

There’s a couple of plugins that the wiki also recommends, but I encountered some bugs with the threaded comments plugin they wanted. It turns out you can edit the modified import tool to turn off threading, so I did that. Basically follow their procedure except skip the install of the plugins and edit the import tool to turn off threaded comments.

The next problem I encountered is that a bunch of entries were scrambled because entity encoded characters weren’t copied over correctly. I had to use a filter to translate those back to straight ASCII:

sed -e "s/&lt;/</g" -e 's/&quot;/"/g' -e "s/&gt;/>/g" -e "s/&apos;/\'/g"

Then it turned out that lj-user tags weren’t getting translated, so I had to filter those:

sed -e 's/<lj user="*\([^">]*\)"*>*/<a href="http:\/\/www.livejournal.com\/users\/\1\/"><img width="17" height="17" alt="" src="http:\/\/www.livejournal.com\/stc\/fck\/editor\/plugins\/livejournal\/userinfo.gif" style="vertical-align: bottom;" \/>\1<\/a>/g'

Actually that only applies to the plain-text editor tags. If you use the rich text editor on LiveJournal, you’ll have to translate those separately. I only had one, so I did it by hand.

The final problem is with bare URLs. In LiveJournal if you type or paste a bare URL such as: http://jameslick.com/ it’ll automatically turn it into a link. However, the exporter leaves it just as a raw URL. I probably should have built a filter to convert these as well, but it was so close at this point that I just did these by hand as well.

So after a few hours of work, 361 LiveJournal entries imported into WordPress with comments and various other corrections.

Wish List:

WordPress import tool that can handle comments, can handle the default jbackup.pl format, can handle entity encoded characters, and bare URLs. It should have been MUCH easier than this.

USB Disks on Solaris 10 x86

USB support in Solaris is greatly improved these days. One thing I’ve had as a goal for a while now is to more fully migrate my server backups to using disk instead of tape. (Disk for backups? Isn’t that backwards? Actually, if you look at media prices, IDE disks are WAY cheaper than tape media, and that doesn’t even cover the exorbitant cost of tape drives. And rsync *rocks* for this type of application.) One thing that’s still keeping me on tape in addition to disk is that I don’t have any way to do easy offsite storage with disk. But USB drives provide a perfect opportunity to do this.

I’ve been playing a lot with Solaris 10 x86, so I decided to see how hard it is to get a USB disk installed. Unfortunately there’s not a whole lot of documentation out there, and what I could find was pretty vague, along the lines of ‘run rmformat’ which tells you approximately 5% of what you need to know. There’s a couple of pitfalls if you just poke around, so here’s the complete procedure I worked out.

Keep in mind that this is for Solaris 10 x86. The sparc version would be different, but would probably just skip the fdisk stuff and the s2 workarounds. This procedure also assumes you want to use ufs as the filesystem instead of something else like FAT (aka pcfs). Also remember that ufs drives cannot be shared between sparc and x86 servers because of the different methods for layout on the disk. This assumes that your USB chipset is supported and that your USB disk doesn’t require some proprietary driver. Most USB chipsets are supported in Solaris 10 x86, and most current USB disks on the market are generic. If the disk is plug-and-play on XP and Mac, it’ll probably work. The setup requires root access.

Disable Volume Management: /etc/init.d/volmgt stop

(If you don’t, vold will get in the way of what you are doing.)

Plug in your USB drive.

Look at end of file /var/adm/messages and run prtconf -v to verify it is recognized.

/var/adm/messages:

Apr 24 01:16:27 yemaozi.tcp.com usba: [ID 912658 kern.info] USB 2.0 device (usb4b4,6830) operating at hi speed (USB 2.x) on USB 2.0 root hub: storage@6, scsa2usb0 at bus address 2
Apr 24 01:16:27 yemaozi.tcp.com usba: [ID 349649 kern.info] Cypress Semiconductor USB2.0 Storage Device DEF1097DC60E

prtconf -v:

            storage, instance #0
...
                Hardware properties:
...
                    name='usb-product-name' type=string items=1
                        value='USB2.0 Storage Device'
                    name='usb-vendor-name' type=string items=1
                        value='Cypress Semiconductor'
                    name='usb-serialno' type=string items=1
                        value='DEF1097DC60E'
...

Run rmformat -l to list removable drives:

Looking for devices...
     1. Logical Node: /dev/rdsk/c1t1d0p0
        Physical Node: /pci@0,0/pci-ide@1f,1/ide@1/sd@1,0
        Connected Device: ASUS     CD-S520/A4       1.21
        Device Type: CD Reader
     2. Logical Node: /dev/rdsk/c2t0d0p0
        Physical Node: /pci@0,0/pci1297,fb62@1d,7/storage@6/disk@0,0
        Connected Device: SAMSUNG  SP1604N
        Device Type: Removable

The first device is the CD-ROM drive. The USB disk is device 2, which is at /dev/rdsk/c2t0d0p0

First create fdisk partitions: run fdisk -B /dev/rdsk/c2t0d0p0 which assigns the
whole disk to solaris. You may need to use fdisk interactively if the disk already had PC style partitioning on it to remove all other partitions before proceeding.

Add a label: rmformat -b usb-sam /dev/rdsk/c2t0d0p0

This label can be up to 8 characters. You don’t have to add one, but if you don’t add a label, it will show up as “unnamed_rmdisk” under volume management which looks icky. Here we used the label ‘usb-sam’.

Now here’s where it gets a little tricky. If you’re used to working with sparc stuff, you know that you can use partition s2 to make one big partition using the whole disk. On Solaris x86, there’s always a one cylinder boot partition (s8) at the beginning of the disk. This applies even if you’ll never boot off of that disk. So if you want to use the whole disk, you will have to start any data partitions at cylinder 1 instead of 0. Another catch is that Volume Management by default looks for s2 on removable disks, so if you use a different partition such as s0, it won’t automatically mount. But format won’t let you change the size of s2 if you keep the partition id as ‘backup’. So putting all of this together, the easiest way to resolve this is to change the partition id of s2 to ‘root’, set the permissions to ‘wm’ and then resize it to start at cylinder 1 and use the rest of the disk.

Partition disk: run format -e. Without the -e flag, Solaris won’t show
removable disks. Select your USB disk and then enter the following commands to do as described in the previous paragraph:

partition
2
root
wm
1
press enter for default
label
press enter for default
y
quit
quit

Run prtvtoc /dev/rdsk/c2t0d0p0 to verify partitioning, e.g.:

* /dev/rdsk/c2t0d0p0 (volume "usb-sam") partition map
*
* Dimensions:
*     512 bytes/sector
*      63 sectors/track
*     255 tracks/cylinder
*   16065 sectors/cylinder
*   19456 cylinders
*   19454 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       2      2    00      16065 312512445 312528509
       8      1    01          0     16065     16064

Verify that partition s2 does NOT start at sector 0.

Now create a filesystem: newfs /dev/rdsk/c2t0d0s2

Re-enable Volume Management: /etc/init.d/volmgt start

It should show up after a second or two:

df -k:

Filesystem           1K-blocks      Used Available Use% Mounted on
...
/vol/dev/dsk/c2t0d0/usb-sam/s2
                     153893759     65553 152289269   1% /rmdisk/usb-sam/s2

When you want to remove the disk, don’t just unplug it from the system. You need to use eject to have Volume Management unmount it first: eject usb-sam

Here we use the disk’s label to identify the device to eject. If you didn’t use a label you can do this instead, though it will be ambiguous if you have multiple removable disks in use: eject rmdisk

Then before you actually unplug the drive, you will need to stop Volume Management because it cannot deal with devices being unplugged. This has to be the stupidest thing ever. Here’s what the manual says:

     A disk storage device can not be removed or  inserted  while
     vold  is  active.  To  remove  or  insert  a removeable mass
     storage device such as a USB memory stick,  first  stop  the
     daemon by issuing the command /etc/init.d/volmgt stop. After
     the device has been removed or inserted, restart the  daemon
     by issuing the command /etc/init.d/volmgt start.

So much for Volume Management being automatic. Optionally you can either remove rmdisk support in vold.conf or disable vold completely and mount/unmount the drive manually. Would probably be easier.