/etc/cron.daily/60sa-update:
[: 9: 1: unexpected operator
[: 14: 1: unexpected operator
run-parts: /etc/cron.daily/60sa-update exited with return code 1

The solution:

Open /etc/cron.daily/60sa-update in your favorite text editor and change the top line from “#!/bin/sh” to “#!/bin/bash“.

Credit for this fix goes to this post at Mammuts FAQ (Spanish).

Yet another Ubuntu upgrade bug not solved in time for release.  The details are in the bug report here.  I don’t understand how this bug has been known since February and not fixed in time for release.

The workaround: Download and install the Ubuntu 12.04 versions of libtinfo5, libncurses5, and libncursesw5 (in that order).  You will have unresolved dependencies until you install all three, but you should be able to do them one by one with dpkg -i.  (Do not just double-click and use the graphical Ubuntu software manager; use dpkg -i from the terminal.) After they are installed, run the distribution upgrade like normal.

As far as I know, you need the Linux 3.0 kernel or later to boot via UEFI, which means you’ll need to be using at least Ubuntu 11.10. All of the current 64-bit Ubuntu (11.10) ISO images seem to boot fine via UEFI, so I booted the desktop disc as a “live CD” for many of these operations.

If you have a standard Ubuntu installation, your disk has just two partitions: one for the file system and one for swap space. In my case, these were /dev/sda1 (ext4) and /dev/sda5 (swap). The disk itself is partitioned using the MBR method.

To switch to UEFI, you’ll have to convert the disk’s partition table from MBR to GPT. This can be done non-destructively using gdisk. You can install it from the “Universe” repository in Ubuntu (here’s the package page), if you’ve booted from the Ubuntu Lice CD, you’ll have to enable this repository. Once you launch gdisk from the terminal, you tell it which disk you’re interested in (/dev/sda in my case) and it will proceed with the conversion from MBR to GPT automatically — you’ll just need to tell it to write changes and quit. GPT actually stores two copies of the partition table on the disk, and gdisk will want to put one at the front and one at the end. For me, it complained that there was no room after the last partition on my disk to store the second partition table, so I had to open GParted and shrink my swap partition a little.

After the conversion to GPT, you’ll notice that there are some small gaps between your partitions. The reason for this is explained in more detail here, but, you can use GParted to move and resize the partitions to your liking after the conversion is done.

Now, UEFI systems need a special boot partition to hold the UEFI boot loader for your OS, called the EFI system partition, or ESP. (It can actually hold several different boot loaders, making multi-booting considerably more simple than before.) Create a 20 MB FAT16 partition at the start of the disk, and use the GParted flag management to enable the “boot” flag. I don’t think that this new partition necessarily has to be the first one on the disk, but I’m just copying the partition structure that you get from installing Ubuntu on a UEFI system from scratch. Make sure you use the “MiB” alignment option when messing with the partitions to keep them aligned properly if you have an SSD, “advanced format” 4K-sector drive, or RAID setup.

After the conversion to GPT, I had two partitions on the disk: /dev/sda1 (ext4) and /dev/sda2 (swap). When I added the FAT16 partition at the front, it was labeled /dev/sda3 even though it was the first partition on the disk.

Now, the conversion to GPT is done and the ESP has been set up. All that’s left is to reinstall grub so that it can boot your machine. First, install the grub-efi package. This will remove the grub-pc package, and allow us to install grub without having it freak out because your disk is not partitioned with MBR.

The following commands did it for me… you may have to adjust them if your partitions are labeled the same as mine.

sudo mount /dev/sda1 /mnt # Mount the root filesystem in /mnt
sudo mkdir /mnt/boot/efi # Create a directory to mount the ESP in
sudo mount /dev/sda3 /mnt/boot/efi # Mount the ESP
sudo grub-install --root-directory=/mnt /dev/sda # Run the grub install

When you’re done, you should be able to check the ESP (in /mnt/boot/efi) to see that the boot loader has been placed there — EFI/ubuntu/grubx64.efi.

Then, reboot and it boots! Depending on your motherboard’s UEFI implementation, you may have to point it to the Ubuntu boot loader the first time (EFI/ubuntu/grubx64.efi). Also, the first time I booted after the conversion, some errors popped up on the screen but the system still came up properly. Subsequent boots did not have any errors, so I’m not quite sure what that was about.

Be sure to install the grub-efi package on your main system too, so that if an update comes along that requires updating grub, it works properly.  Also, I actually ended up deleting and re-creating the swap partition during this process, so its UUID changed.  You may want to check your /etc/fstab file and make sure the UUIDs still match up with your partitions.

Resources:

• http://www.rodsbooks.com/gdisk/ — the gdisk page has a lot of useful information about GPT/UEFI
• http://www.thinkwiki.org/wiki/UEFI_Firmware — a wiki page that describes the process of installing grub for booting via UEFI
• https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI — a page which discusses a similar migration for a Windows system, which has some additional useful information

My reading seems to indicate that this happens if you upgrade from Ubuntu 10.10 which itself had been upgraded from Ubuntu 10.04, and grub was never reinstalled.

I think it is completely ridiculous that this bug made it all the way to the Ubuntu 11.04 final release — leaving the system unbootable after an upgrade is a disaster.

The easiest way to fix it is to boot from the Ubuntu 11.04 alternate install CD.  Choose the option to “Repair a broken system.”  Go through the prompts and choose which disk has your root file system.

After this, you may have the option to just reinstall grub — if so, do it, and reboot, and your system should be fine.

If that’s not an option, choose to start a recovery shell using your root filesystem and then run the commands

grub-install /dev/sda
update-grub

(possibly adjusting for where your root disk is).  Then reboot and the machine should boot.

If it still doesn’t, go back to the recovery shell and see if your /boot directory is empty (aside from the “grub” directory).  This happened to me on a machine that was set up with LVM.  The /boot folder is actually stored on a different partition and you have to mount it before grub can set itself up right.  Here’s the commands…

rm -Rf /boot/*
mount /dev/sda1 /boot
grub-install /dev/sda
update-grub

Of course, these may need to be adjusted depending on which disk needs grub and which partition contains /boot.  You can use the GUI partition editor on the Live CD to check.

Now, hopefully your machine can boot up.  What a mess.  :-\

Update: May 12, 2011

dzsi posts another way to recover from this situation in the comments below.  This method does not require booting from a CD.

Note that in the commands that follow, “X”, “Y”, and “Z” should be replaced with numbers/letters that represent your boot disk.

At the grub prompt, issue these commands:

set root=(hdX,Y)
linux /vmlinuz root=/dev/sdZ ro
initrd /initrd.img
boot

Your machine should boot up.  Start a terminal and issue these commands:

sudo grub-install /dev/sdZ
sudo update-grub

This should fix grub so that you do not have any boot trouble anymore

The solution is to add an environment variable, OPENSSL_CONF, and set it to the complete path to an OpenSSL config file.  (In this case, again, it is located in Apache’s conf directory.)  Then, restart your command prompt instance and all should be good.

The easy solution to this problem is to open up the virtual network editor and click on the “Restore Defaults” button.  This reinstalls the VMware network components and sets everything back up like it would be if your install was brand new.  However, it’s annoying to have to do this every time I power up the machine.

continuum over at the VMware Communities message boards pointed me towards the solution — restarting the hidden “vmnetbridge” service also does the trick.  However, again, it’s annoying to have to do this every time the machine is powered on.

I tried writing a batch file to restart the service and scheduling that to execute at power on but I couldn’t find an appropriate trigger to have the Windows task scheduler execute it.

So, I wrote a system service in C# that hangs out in the background and restarts the vmnetbridge service whenever the machine wakes up from hibernate or sleep.  This handles the problem brilliantly — no effort required after the service is installed, but the VMware “Bridge” interface keeps working as expected.  You can download it from its new project page, here.

I like to use the monthly Mozilla Foxkeh desktop wallpaper.  Right now, I have the January 2011 wallpaper — this nice, large, lossless PNG.  (By the way, the word that he is in the progress of writing is “火狐”, which literally means “fire fox.”  How cool!)

Anyway, I noticed that there is crappy compression on the image shown on my desktop, particularly around the numbers that make of the calendar.  This has been occurring in the wallpapers for past months as well.  If I open up the PNG (that I told Windows to use!!) and zoom way in, the image is crystal clear.  But on the desktop, it is junk.  Take a look, I zoomed in on the “2011″ at the top-left of the calendar.  On the left is the data from the PNG as viewed in any decent graphics application, and on the right is what appears on my desktop.

Yuck!

Now, with perhaps more typical wallpapers like photographs, maybe this wouldn’t be so noticeable.  But this is still dumb.  If I provide a lossless image, why can’t Windows use it directly, or at least convert it for use in a lossless manner?

I happen to know that in the registry, the path to your current wallpaper is located at HKCU\Control Panel\Desktop\Wallpaper.  Taking a look at the value stored there…

That’s right, it is pointing at TranscodedWallpaper.jpg, located in the depths of my user profile.  So, Windows took my PNG and converted it to JPEG to be used as my wallpaper.  Ugh.  Ugh ugh ugh.

Anyway, there’s a couple of ways around the problem.  First, you can open the PNG image in Internet Explorer or Firefox or Windows Live Photo Gallery (or perhaps any number of other applications), right-click on it, and select the option to use it as your desktop background.  It will be properly set, without the crappy compression occurring.  (I normally set it through the control panel you get by right-clicking your desktop and clicking “Personalize.”  I confirmed that going back there to set it restores the crappy JPEG compression.)

The other option would be to convert the image to BMP and set the path to it manually in the registry, at the value shown above.  Then, log out and log back in to have Windows notice that the wallpaper has changed.

Hopefully this will be addressed in the next major Windows release!  (Not addressed in the forthcoming Windows 7 Service Pack 1, sorry.)

The DHCP server has a pool of addresses that it is allowed to hand out to clients, and it will often hand out these addresses sequentially. In some cases, the address chosen for a particular client may be based on some sort of hash function on the client’s MAC address (so that the client will always be assigned the same address, unless there is a hash collision).

Of course, sometimes it’s nice to assign a particular device on your network a specific IP address (a “static” or “fixed” IP address). This way, you will always know without any doubt what the IP address or your printer or file server or whatever is. Of course, you can just set the address manually on the device, taking care to place it outside of the DHCP pool.

Another way to go about it is to reserve a specific IP address for your device on your DHCP server using the device’s physical (or “MAC”) address. This is handy if you have many devices that you would like to assign fixed addresses to – if, for whatever reason, you ever want to change the IP address of something on your network, you just make the change on the DHCP server and you do not have to bother touching the device itself. The change will take place the next time the device renews its DHCP lease.

Using the DHCP server included with Ubuntu Server, if you would like to assign a fixed address to a particular device, just add some lines like this to /etc/dhcp3/dhcpd.conf:

host aaron-vmware {
    hardware ethernet 00:0c:29:f8:47:3e;
    fixed-address 192.168.100.81;
}

Restart the DHCP server configuration using sudo service dhcp3-server restart and you’re all set.

Cannot open file “C:\ProgramData\VMware\dndlogs\dndlog.conf”: The system cannot find the path specified.

The network bridge on device VMnet0 is temporarily down because the bridged Ethernet interface is down.  The virtual machine may not be able to communicate with the host or with other machines on your network.

Not too big a deal, usually using the NAT interface works just fine, but it does prevent other machines on the network from talking to the VM which is sometimes a handy feature to have.

The fix turned out to be simple.  Power down your VMs and open the “Virtual Network Editor” from the “Edit” menu and click the button to restore default settings.  Wait for a while for the network components to be reinstalled, and then start a VM with the bridged interface again.  Hopefully, it’s all fixed.

Update: December 30, 2010

I had this problem happen again after I closed VMware and opened it again the next day.  The “Restore Default” button fixed it again, however, why did it come back in the first place?  Further reading indicates that disabling the Visual Studio debugging support should take care of the problem.  (Not sure why it is enabled by default if I did not even choose to install it when installing VMware.)  You can do this in the options for each individual VM, under “Replay.”

Another solution is to simply create an empty “dndlog.conf” file in the appropriate location.

Lightbox is a nifty little JavaScript/CSS package you can download that allows you to make nifty slideshows on a web page with little effort.  Pretty much, your page has thumbnail images that link to the larger images, with a specific rel attribute on the a tags that make the links, and Lightbox takes over to display the large image in a nifty Flash-free box when you click on a thumbnail.  If you have several images, it’ll make a nifty slide show for you.  You can read more and see it in action if you click the link at the start of this paragraph.

Well, the box with the image in it has a close button at the bottom.  What if I want to put it on the top instead?

Googling around, this is the best I could come up with.  This page describes how to make changes to Lightbox 2.03 to move the close button to the top.  However, the current version of Lightbox is 2.04, and if you try to follow the same steps on the page, you’ll find that the line it says to change in the JavaScript file is nowhere to be found.  Yeah, you could just find a copy of Lightbox 2.03 to use, but there actually really are bugs in 2.03 that are fixed in 2.04 (for instance, 2.03 sometimes uses the wrong box/image size in Google Chrome and doesn’t notice when new images with links are added to the page via JavaScript, albeit on that second one there is actually a function you can call to get it to re-scan).

Anyway, yeah, we want to use 2.04.  Here’s how to do it.

First off, lightbox.css.  I added this line at the end of the file.

#outerImageContainer #bottomNav{ position: absolute; top: 0px; right: 0px; z-index: 200; padding:8px; background-color:#FFFFFF; font-size: 35px; }

That’s pretty much the same as the one mentioned in the page above, except for the font-size, which I added to keep the close button from moving slightly up and down when the size of the lightbox changes while switching between images.  Anyway, this pretty much just puts the close button at the top of the lightbox and puts it on top of everything else.

Now for lightbox.js, which is way different.  Find the code that actually builds the lightbox, which starts at line 134.  Replace it with this.

        objBody.appendChild(Builder.node('div',{id:'lightbox'}, [
            Builder.node('div',{id:'outerImageContainer'}, [
                Builder.node('div',{id:'imageContainer'}, [
                    Builder.node('img',{id:'lightboxImage'}), 
                    Builder.node('div',{id:'hoverNav'}, [
                        Builder.node('a',{id:'prevLink', href: '#' }),
                        Builder.node('a',{id:'nextLink', href: '#' })
                    ]),
                    Builder.node('div',{id:'loading'}, 
                        Builder.node('a',{id:'loadingLink', href: '#' }, 
                            Builder.node('img', {src: LightboxOptions.fileLoadingImage})
                        )
                    )
                ]),
                Builder.node('div',{id:'bottomNav'},
                    Builder.node('a',{id:'bottomNavClose', href: '#' },
                        Builder.node('img', { src: LightboxOptions.fileBottomNavCloseImage })
                    )
                )
            ]),
            Builder.node('div', {id:'imageDataContainer'},
                Builder.node('div',{id:'imageData'},
                    Builder.node('div',{id:'imageDetails'}, [
                        Builder.node('span',{id:'caption'}),
                        Builder.node('span',{id:'numberDisplay'})
                    ])
                )
            )
        ]));

This is pretty much the same as the code that was already there, except I moved the bottomNav node from the imageDataContainer up to the outerImageContainer.  This, plus the style change above, moves the close box from the bottom-right to the top-right of the lightbox container.  See for yourself:

Anyway, that’s it, you’re done.  Now, I’m going to propose one more fix, if you’re interested in captions to go along with your slide show.  If you have an image with a caption followed by an image without a caption, Lightbox will not remove the caption when you advance from one image to the next, because it only updates the caption if it is not blank.  See the if statement at line 330 in lightbox.js:

        if (this.imageArray[this.activeImage][1] != ""){
            this.caption.update(this.imageArray[this.activeImage][1]).show();
        }

Add this code right after it to make sure the caption goes away when it should:

        else {
            this.caption.update("").show();
        }

And that’s all.  If you’d like, I’ve uploaded here a copy of Lightbox 2.04 with the modifications mentioned in this post.