Sound Device Problem in VMware Workstation 7

I was running Windows XP as a guest in a virtual machine (VM) in VMware Workstation 7 on an Ubuntu 9.10 (Karmic Koala) host.  When I used Workstation's VM > Removable Devices > Sound Card > Connect option, I got this error message:

Failed to open sound device /dev/audio:  Device or resource busy
Failed to connect virtual device sound.

I had also gotten this message:

Failed to open sound device /dev/dsp: Device or resource busy
Sound will not be available

I had been having this problem ever since I started using VMware.  I had previously changed the sound device (using VM > Settings > Hardware tab > Sound Card > Use physical sound card) from /dev/dsp to /dev/audio, and had also changed the sound card so that it would not connect at power on.  These and other efforts (e.g., rebooting) had fixed things temporarily, but then stopped working.

Some time back, I had found that I got this problem when Second Life was running in Ubuntu (that is, not in the WinXP guest).  More recently, I had had the same problem when Firefox was running in Ubuntu.  What I worked out that time was as follows:

For the time being, the solution seems to be either (a) to watch videos and other webpages that use Flash, do it in a browser session that is running inside your VM, not in a browser running in Ubuntu, or (b) after watching a video or otherwise using Flash in Ubuntu, kill the program that used it (e.g., Firefox) and manually reconnect with your sound card inside the VM.

So now I powered down my VM (i.e., not just suspended) and went into Workstation's VM > Settings > Sound Card option.  There, I put my settings at "Connect at power on" and Use physical sound card:  Auto detect.  I saved that and killed all browsers in Ubuntu, including Firefox and also Google Chrome.  I then powered on the VM.  WinXP had a hard time booting itself -- it always seemed to reboot a couple of times before it finally got itself together -- so while I was waiting, I started another session of Workstation and, in that one, I set the sound card to "Use physical sound card:  ALSA: Default sound card," and powered up that VM as well.  That one booted.  The one set to Auto Detect seemed frozen, so I changed it to "Use physical sound card:  OSS:  /dev/dsp" and tried again.  It gave me a notice that VMware Tools was not installed (it had been installed previously), but it booted, and Tools did appear to be running OK.

At this point, sound was working OK in the one that used ALSA, but not in the one using OSS.  That is, when I tried the virtual machine that was using VM > Removable Devices > Sound Card > Connect in the OSS, I got an error message.  I changed it to ALSA, like the other one, and then the sound worked in both.  The solution reached previously, of killing competing programs in Ubuntu, seemed to be the answer again.

Later, though -- after rebooting, I think, and anyway after running Firefox in Ubuntu again -- I found the audio was stuttering.  It stuttered at different speeds if I used ALSA or OSS, but either way it stuttered.

I played a sound file in the VM, and while it was stuttering along, I went to Ubuntu's System > Preferences > Sound > Applications tab.  There, I saw "ALSA plug-in [vmware-vmx]" listed, and underneath it I saw "No application is currently playing or recording audio."  That message was flickering on and off with each stutter in the sound.  A search along these lines led to a thread in which someone suggested reinstalling the ALSA packages.  In System > Administration > Synaptic Package Manager I did a quick search for ALSA.  I saw that I had a number of ALSA-related programs installed.  I started to mark one of them, alsa-base, for removal, but when I did so, Synaptic indicated that it would also need to remove a package called ubuntu-desktop.  That sounded pretty major, so I bailed out of the reinstall-ALSA approach.

I did a different search and came up with a thread in which someone said that VMware Workstation 7 supports ALSA perfectly, and if you are getting stuttering it may be because of a setting in the WinXP guest, not in Ubuntu or Workstation.  Following the advice there, I went into XP's Control Panel > Sounds and Audio Devices > Volume tab > Speaker settings > Advanced > Performance tab.  There, as advised, I set both the Hardware Acceleration and the Sample Rate Conversion Quality sliders to the lowest possible settings.  I clicked Apply and OK and then rebooted the XP guest.  With ALSA as the chosen sound card setting, and with the sound card connected in VM > Removable Devices > Sound Card, I found on reboot that I had no sound at all.  I tried changing from ALSA to OSS and auto detect and back to ALSA.  Now I could connect the sound card, and now I had sound.  But I still had stuttering.  I tried typing “/dev/audio” into the box in place of ALSA, and (after reconnecting the sound card) that sped up the stuttering but did not eliminate it.

I wondered if the stuttering was due to a larger problem with the VM.  I wondered this because its performance was generally slow at this point, and had been slow before I started this latest round of tinkering.  (In other words, I hadn’t caused that slowness just by playing with the sound problem.)  I suspended the VM and shut down the system.  Next day, I started the machine and tried again.  There was still a bit of stuttering, but the situation was much better.  (See also this other writeup on audio problems in Ubuntu and VMware.)

Restoring GRUB on Dual-Boot Vista-Ubuntu (9.10) Machine

I had Ubuntu 9.10 (Karmic Koala) installed.  I reinstalled Microsoft Vista.  This knocked out the GRUB boot menu.  To restore the boot menu, I followed some Ubuntu community documentation.  The steps I used there, boiled down for my purposes, were simply to reboot from the Ubuntu CD, go into the Ubuntu partition via the Places menu, type "mount | tail -1" to make sure the Ubuntu partition was now mounted (in my case, it said something like "/dev/sda2 on /media/UBUNTU type 3" because I had named the partition using GParted), type "ls /media/UBUNTU/boot" to make sure I had the partition containing GRUB (along with memtest86+ and other files), and then run "sudo grub-install --root-directory=/media/UBUNTU /dev/sda."  That last command did not end in a number (e.g., sda2); it was simply the drive containing the boot partition.  In place of UBUNTU in my example, I would have typed the long UUID if that was what the mount command had given me.

That pretty much fixed it.  When I rebooted, I did have a GRUB menu.  But when I opted to go into Ubuntu, I got an error message:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:

SWAP: waiting for UUID=[UUID number]

Press ESC to enter a recovery shell.

I pressed ESC.  I went to Applications > Accessories > Terminal and typed "sudo gedit /etc/fstab."  This opened fstab.  The lines weren't wide enough to view clearly, so I expanded the box.  Fstab contained an entry for SWAP, which (above) was the partition that didn't boot in my case.  I started another Terminal session and typed "blkid" to see what the UUIDs were.  I saw that the UUIDs and the /dev entries for SWAP didn't match.  I changed the fstab line for SWAP to match what blkid had given me, for both the UUID and the /dev location.  (I had to use the right-click option to copy from the Terminal output for blkid.)  I saved fstab and rebooted.  That seemed to fix it; the boot proceeded normally.

Ubuntu 9.10: Mounting and Dismounting Blues

I was using a couple of external USB drives with Ubuntu 9.10 (Karmic Koala).  I found the easiest way to switch them between computers was to wait until they were inactive and then yank the USB cord from one machine and plug it into another.  This had worked pretty well, but then I got this error message:

Unable to unmount DAILY

umount:  /media/DAILY mount disagrees with the fstab

This seemed to have been related to some kind of bug.  I got this after a previous error message:

Could not display "/media/DAILY".

Error:  error stating file '/media/DAILY': Input/output error

Please select another viewer and try again

DAILY was a manually created folder in /media.  I couldn't figure out how to delete it either:  it wasn't visible in "sudo nautilus" and there wasn't an option to delete it in ordinary Nautilus.  Chris Jean fixed a similar problem with this kind of command:

sudo fuser -km /media/DAILY

This seemed like a reasonable command, given some basic information about the fuser command, so I closed down everything else and tried that.  I got this response:

Cannot stat /media/DAILY:  Input/output error

I looked that up.  It didn't seem to be a very common problem.  Several of the entries that came up in that search referred to GRUB, but I wasn't sure what to make of that.  Charles A said the input/output error usually means that a drive is going bad.  Going from something else he said, I did a search for how to mount an NTFS drive by using its UUID.  Ganesh suggested "sudo fdisk -l" to see if DAILY was connected.  It did not appear to be . . . because it wasn't.  I had just pulled out its USB cable a few minutes earlier and had neglected  to plug it back in.  I did that, but now I got this:

Unable to mount DAILY

Error mounting: mount exited with exit code 1: helper failed with:

mount: according to mtab, /dev/sdf5 is already mounted on /media/DAILY

mount failed

I typed "df" and saw that DAILY was mounted at /dev/sdf5.  I clicked on DAILY in Nautilus and got the "Could not display '/media/DAILY'" error shown above.  I got an indication that this was, again, a bug.  I decided to reboot.  That fixed everything for the time being.

Later, I took a different approach.  As advised in an Ubuntu community document, I installed pmount in Synaptic.  The recommended syntax was "pmount /dev/sdb5 DRIVE," where any available location could be used in lieu of sdb5 and where DRIVE is the name of the partition.  If just the drive name is used like this, it will be mounted by default at /media/DRIVE.  But, oops, I mounted it as root, when the whole purpose of pmount was to make it possible for a non-root user to mount a drive.  So I unmounted, typed "exit" to get out of the root prompt, and tried again:  "pmount /dev/sde5 WEEKLY."  Unfortunately, it hung.  I wondered if it was because I had already mounted and disconnected (without unmounting) a device at sde5.  Maybe I needed to use the largest previously unused letter.  I killed Terminal, unplugged and replugged the USB cable on the drive, and as a user in a new Terminal session I typed "df -h" to see what was available.  I already had something mounted as sdf5, so I tried "pmount /dev/sdg5 WEEKLY."  This gave me "device /dev/sdg5 does not exist."  It took me quite a while to discover that, actually, I had not plugged the drive back in after all.  Now it mounted as "WEEKLY_" with an underscore at the end; and when I tried "umount /media/WEEKLY," I got "/media/WEEKLY is not mounted (according to mtab)."  So, OK, I pulled the USB plug, typed "sudo nautilus," went into File System/media, right-clicked, and moved WEEKLY to trash.  I replugged the USB, killed sudo-Nautilus, and at a user prompt typed "df -h" and saw that WEEKLY had reclaimed its old post at /dev/sdd5.  Now it seemed to be working OK.  Later, when I tried using pmount another time, I got some errors, like this:

Error: directory /media/[directory name] is not empty

Error:  device /dev/sdf1 does not exist

I looked at a more detailed pmount documentation page and saw that /dev/sd?? had to be a "block device in /dev."  A forum post told me that I could identify my system's block devices by typing "sudo fdisk -l."  (That's an L, not a one.)  This sobered me up on the question of what my /dev options were.  I really had only one choice as to where to mount the drive, and when I tried pmount there, I got "Error: device /dev/sde5 is already mounted to /media/[partition name]."

(Having run out of time to fiddle with this, I left this post as a draft at that point.  I believe this problem ultimately got solved by a reinstallation.  No further comments on this issue here.)

VMware Workstation 7: Improving Performance in 32-bit Ubuntu 9.10 (Karmic Koala)

I was in the process of tweaking an installation of x32 Ubuntu 9.10, and ran into some VMware performance issues.  Specifically, in VMware Workstation 7, I found that one of my virtual machines (VMs) performed much more slowly under 32-bit Ubuntu than it had performed under 64-bit.

To improve performance, I tried a couple of things.  I shut down the VM I was using, closed Workstation, typed "sudo vmware," and went into Workstation's VM > Settings > Hardware tab > Processors.  I had set it at 2, because I was using a dual-core processor, but I vaguely recalled that that had seemed slower at one point in the past, so I changed it to 1 processor.  I also increased Memory from 1000MB to 2000MB.  Also, while I was running Workstation as root, I went to Edit > Preferences > Memory.  I left Reserved Memory at 2500MB and changed Additional Memory to "Allow some virtual machine memory to be swapped," which as I recalled was the original setting.  I also thought that I might have been able to speed up the VM somewhat if it was smaller:  this particular one was 35GB, having been converted from a larger WinXP partition.  With these changes in place, I closed out of Workstation as root, started Workstation normally, and tried the VM again.  It was still very slow -- if anything, worse than before.  Some of this slowness could have been due to other hard drive activity.  I had recently installed Google Desktop, and it was indexing my hard drive throughout the time when I was writing this post.  But at this same time, another VM, set to 1 processor and only 1000MB of RAM, worked acceptably.

To speed things up further, there were numerous tweaks that would supposedly improve Ubuntu performance.  One speedup option was to buy a solid state drive (SSD).  This, it was said, would yield "a remarkable change in system performance - boot time and program startup times are drastically reduced. I highly recommend the investment - I have never before seen a single hardware change that affected performance as much as an SSD."  SSDs that would be large enough (30GB+) were currently at $150 and more, so that was something to think about for the future, as prices came down.  Getting an SSD would apparently call for some additional adjustments.

I ran a search to see if I could use the rest of my system's memory as a RAM disk.  This didn't seem to be a very common procedure.  But one post said it was simple.  The dominant approach seemed to be to tell Ubuntu to load its /tmp temporary files folder into RAM at startup.  There were different types of Ubuntu RAM disks.  The one called tmpfs seemed optimal.  The general idea seemed to be that you would set up tmpfs at a special location known as /dev/shm.  According to Kevin VanZonneveld, "The standard /dev/shm grows automatically as more space is needed, but is by default limited to half of your physical RAM. If you have 2GB, it can grow to 1GB at most."  There seemed to be ways to change that; but since I figured I'd typically have total RAM of 6GB to 8GB in my system, 50% of RAM seemed fine.  For future reference, there were ways to speed up Firefox by using tmpfs, but I hadn't noticed as much of a need for that, especially outside of the VMs.  What seemed most immediately promising, for my purposes, was to use /dev/shm for VMware specifically.  After some hunting, I found a website for VMware Server, but I wasn't sure whether I should try using its suggestions in Workstation.  I learned that KVM is an open source competitor with VMware but is still rather complex.  Then I noticed that someone said that a Physical Address Extension (PAE) aware kernel would allow 32-bit Ubuntu to use more than the (theoretically 4GB, but practically) 3GB RAM limitation.  I checked that out and concluded that 32-bit PAE performance was not going to be much better per se than plain 32-bit (and both would remain far below 64-bit performance), but neither would it hurt (unless I turned out to be one of those users who had problems with e.g., the mouse or graphics).  There was supposedly some performance reduction if you installed it in the standard way; the alternative was to build a custom kernel, which was beyond my time and abilities at that point.  I had just made an Acronis TrueImage backup, so I decided to try the standard approach, in its latest version.  First, I went to Synaptic and installed linux-generic-pae and linux-headers-generic-pae.  This did its thing for five minutes or so, and then said it needed to restart.  When the machine rebooted and got to GRUB, it showed me a new item:  "Ubuntu, Linux 2.6.31-19-generic-pae."  I selected that.  The BIOS told me, at boot, that I had 6GB of RAM.  When Ubuntu loaded, my previously opened windows were still in place (due to settings described in the previous post), but not VMware.  Instead, I had a dialog that said this:

VMware Kernel Module Updater

Before you can run VMware, several modules must be compiled and loaded into the running kernel.

So I went with that.  Meanwhile, I typed "free -m" and it reported that I did indeed have a total of 6050 of memory.  I wondered whether this would make any difference in VMware.  When the modules were done loading, I started VMware as root and increased the VM's allocation from 1000MB to 1500MB.  I also changed Additional Memory back to"Fit all virtual machine memory into reserved host RAM" and increased Reserved Memory to 5000MB of the 5472MB available to VMs.  Also, I changed the individual VMs to use 1500MB each.

Then I powered on the VM that had been working adequately before.  There was no question that it was much snappier.  With that one running, I powered up the other one, the one that had started the investigation.  So the additional memory definitely was available:  I had two machines running, where before I could only run one.  Now that I had two VMs up, the first VM, the better performer, was running more slowly.  The other one was still slow, but definitely was running better than before.  As before, the new Ubuntu kernel's audio started as muted, so I had to unmute it and turn it up, but then audio in both VMs worked.  There was stuttering in the second, larger VM.  To get the best performance, I turned off one VM and left just one running.  The memory enhancement had still not put me back to where I had been with 64-bit Ubuntu and 64-bit Workstation at their best, but if I got greater reliability and acceptable performance, that would be OK for now.  I did not pursue this further, though, because at about this time I began the process of upgrading to Ubuntu 10.04.

No Sound on Ubuntu 9.10 and VMware Workstation 7 (again!)

I was running Windows XP Pro in virtual machines (VMs) within VMware Workstation 7 on a 64-bit Ubuntu 9.10 (Karmic Koala) host.  I had repeatedly had problems with no audio in earlier versions of Workstation (e.g., 6.5.2).  Various fixes, reboots, and other efforts had randomly gotten the audio working again within one or more VMs.

Now I had a new situation:  there was no audio in any VM and, when I checked, I found there was also no sound in Ubuntu itself.  Once again, I ran various searches and began trying various suggestions.  I came across an Ubuntu Community Documentation page on Sound, which led me to another Community page on Sound Troubleshooting Procedure.  Step 1 in that procedure led me to Stéphane Gaudreault's long, step-by-step procedure on upgrading the Advanced Linux Sound Architecture (ALSA) (1.0.22.1) on Karmic.  (On WinXP, using another computer, Stéphane's page loaded in Internet Explorer, but not in Firefox.  It loaded slowly in Firefox in Ubuntu.)  I closed Workstation, and then copied and pasted each line of that procedure into Terminal.  (It was possible to copy and paste multiple lines at once, including line ends; they would run one after another.)  One exception:  as far as I could tell, I did not get the "panelw library not found" error he described, so as he advised, I skipped the "symbolic links" part of his instructions.  Everything seemed to go smoothly until his very last command (sudo alsaconf), which opened the ALSA Configurator.  After clicking OK, the Configurator said, "Searching sound cards," and then gave me this error:

No supported PnP or PCI card found.

Would you like to probe legacy ISA sound cards/chips?

So it seemed that possibly I did not need to go through Stéphane's procedure, though I did appreciate how perfectly it went.  I might have just run "sudo alsaconf" in the first place, assuming I already had some version of ALSA loaded on my computer; doing so might have given me this same hardware-related error notice -- unless Stéphane's procedure was its cause.  That seemed possible; maybe my ALSA was now so new that Ubuntu had not yet caught up.  I tried listening to a WAV file, just in case, but no, sure enough, still no sound.  I ran a search for that error message.  This led to a VIA Technologies Release Note (oddly, not found on the VIA website) that said,

When installing driver, if the ALSA Configurator reminds that "No supported PnP or PCI card found", it means the kernel cannot find the pci audio device. Select "No" to exit the installation and uninstall the driver. Please read Notes b des-cription to resolve the problem.

Exiting the Configurator did not seem to uninstall anything, so I interpreted that part of the Release Note to mean that I was supposed to uninstall the driver myself, somehow.  Notes, point b, in that document said this:

Before installation, make sure your linux kernel can find the pci audio device first. If your kernel can not find any pci device with command 'lspci', you'd better add an option in /boot/grub/menu.1st file. At the end of line with "kernel /boot/vmlinuz-xxxx", xxxx is the kernel version, add the following:

pci=conf1

This information appeared to mean that I should have done this before going through Stéphane's procedure.  I didn't know how to undo that procedure, so I decided to poke around a bit more, in search of other possibilities.  I started back at the Sound Troubleshooting Procedures (STP) page.  It gave me several commands to copy and paste into Terminal.  This gave me a link to Stephen Olesen's Pastebin website, where all kinds of information about my system was automatically posted for other people to see and, presumably, help me with.  The last message produced by those commands I cut and pasted was, "Please inform the person helping you."  So apparently I could post a question in a forum somewhere, and include the Pastebin address instead of cluttering up the forum with all that information about my system.

Anyway, the STP page said that the Pastebin file should contain some indication of the "Driver version," the "Library version," and the "Utilities version."  I tried searching the Pastebin file for "Driver version" and, sure enough, there it was, not far from the top.  It said this:

ALSA Version
------------
Driver version: 1.0.22.1
Library version: 1.0.22
Utilities version: 1.0.22

That didn't look like an exact match.  I wasn't sure if 1.0.22.1 was close enough to the others.  The STP page said the numbers needed to be equal.  If they weren't, then (a) one of the ALSA components was not successfully upgraded (which I didn't think was the problem, as I had seen no error messages), or (b) I booted an older kernel version (which wasn't the case either).  Anyway, there seemed to be a mismatch between my ALSA version and my Ubuntu kernel.  So it still looked like I would need to reinstall ALSA.  But then it occurred to me that I hadn't run the lspci command, as suggested by the Release Note (above), to see if my kernel could find a PCI device.  It found a bunch of PCI devices, including "MCP61 High Definition Audio."  Hmm.  Puzzling!

OK, well, the STP page had one more, very long line to copy and paste into Terminal.  If my driver version numbers (above) were acceptably similar to one another, maybe this was all I needed to do.  So I tried that.  It ran, but I couldn't tell for sure if it was happy.  I tried "sudo alsaconf" again.  Still the same result.  Mark Rijckenberg suggested, to someone having a similar problem, that they either revert to an earlier version of ALSA (which hadn't been working for me) or else consider switching from x64 back to 32-bit Ubuntu.  Having had many problems with 64-bit Ubuntu -- orphan problems, especially, that almost nobody else seemed to be having -- and having wrestled with the sound problem repeatedly for the past year, I decided to try my luck with 32-bit Karmic.  I describe the downgrading process in a separate post.

Ubuntu 9.10: Downgrading from 64-bit to 32-bit Karmic Koala

As indicated by numerous posts in this blog over the past couple of years, I had a number of problems with 64-bit Ubuntu installations -- orphan problems, especially, that almost nobody else seemed to be having.  I finally decided to try replacing 64-bit with 32-bit Ubuntu 9.10.  This post describes the steps I took to install and configure the downgrade.

First, I made an Acronis TrueImage backup of my current installation, so that I could quickly restore the 64-bit installation if it turned out that downgrading to a 32-bit system wasn't paying off.  Next, I looked into the possibility of downgrading without doing a complete reinstallation, but the consensus
appeared to be that I would have to completely wipe the 64-bit installation and start from scratch, using 32-bit applications.

A tip from Benjamin Lowenstein led me to a quick method of listing and restoring my installed applications.  First, I typed "dpkg --get-selections > installed-software."  This created a file called "installed-software" in my Home folder.  The contents of that file looked like this:

acpi-support                         install
acpid                                    install
adduser                                install

In my case, there were hundreds of them.  Some that I had installed specially (i.e., outside of Synaptic Package Manager), such as VMware Workstation, were not on the list.  Otherwise, though, I would later be able to use this list to restore the large majority of my programs automatically.  Quite an improvement over Windows!

But first, I had some housekeeping to do.  For one thing, the dpkg command put that "installed-software" file into my Home directory; and since I was in the habit of installing all of my Ubuntu folders into a single partition, I assumed that my Home directory would be wiped out during the 32-bit installation.  So I moved the installed-software file to a different partition.  I already had my other data files, virtual machine folders, etc. on other partitions, with one exception:  my Thunderbird e-mail data was in /home/ray/.mozilla-thunderbird, so I had to copy that over to another drive as well.  My Firefox extensions and settings were backed up to that other partition by the FEBE add-on, so I expected the Firefox part of my reinstallation to go smoothly.

Meanwhile, I was downloading the current version of 32-bit Ubuntu 9.10.  When it finished, I burned it to a CD, inserted the CD in the target machine, and rebooted.  The basic installation did not go too smoothly, though.  For some reason, the newly burned CD booted only once in the target machine.  On later reboots, the machine did not boot from the CD, but instead went on to boot from the hard drive.  I tried booting from the CD with a different program, and in that case the machine booted from the CD as expected.  So I switched to an older Karmic 32-bit CD I found lying around.  That booted without a problem.  But then the system seemed to have gotten confused from the previous efforts, and that installation got hung up and took a long time to get past the partitioning step.  The hard drive was still going, according to the activity light; it was just not going anywhere in particular.

At about the same time, the Internet connection on my secondary computer began acting up.  Suddenly, without warning, I wasn't able to go online.  I decided to try installing 32-bit Ubuntu 9.10 there too, using the newly burned CD.  That installation went fine.  And then it was time to work through a 32-bit version of my typical installation steps, following the process described in my previous posts on installing 64-bit Ubuntu 9.04 and 9.10.

I started by running System > Administration > Update Manager to update the programs installed by the CD.  Then I went into Applications > Ubuntu Software Center > Get Free Software > search for "restricted extras" > Ubuntu restricted extras > Install.  Next, System > Administration > Hardware Drivers searched for available drivers and, for my machine, found NVIDIA accelerated graphics driver (version 185) (because I had an NVIDIA video card) > Activate.  This gave me an error:

SystemError:  Failed to lock /var/cache/apt/archives/lock

I wondered if this was because I had not yet rebooted the machine after downloading and installing the initial batch of updates. A reboot got me past that error, but now I had a new one:

SystemError: installArchives() failed.

I tried installing the older (version 173) driver instead.   That seemed to go OK.  It said, "You need to restart the computer to activate this driver," but meanwhile I had gotten started on the next step, so again I deferred rebooting.  That next step was System > Administration > Software Sources > Ubuntu Software tab > Download From > Other > Select Best Server > Choose Server (whichever one it highlights) > Close > Reload.  Then I went back into Software Sources > Other Software tab > select the two entries that are already there > Add.  To get the APT line it was requesting, I opened Firefox and went to the X-Updates website, clicked on "Technical details about this PPA," specified Karmic, and copied the two deb lines there, one at a time, into the APT line, clicking "Add Source" after each.  Next, on that same webpage, below the deb lines, I found the "Signing Key."  In this case, it was "1024R/AF1CDFA9."  I copied the portion after the slash (i.e., AF1CDFA9) and entered it into Terminal at the end of a one-line command, as follows:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AF1CDFA9

This gave me this output in Terminal:

gpg: key AF1CDFA9: "Launchpad PPA for Ubuntu-X" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

I suspected this meant that one or more of my steps had accomplished nothing.  Then I clicked Close > Reload.  (From a previous installation, I had a note to myself:  If you don't get a "Reload" option when you click Close, go back into Third-Party Software and unclick and then re-click some item and try again.  That step was not needed this time.)  Also, by typing "sudo gedit /etc/apt/sources.list," I was able to verify that there were no hash marks in front of the lines for the Universe and Multiverse repositories, which apparently meant they were already available.  The other repository I wanted was the Medibuntu, which I added by using these three commands:

sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update

sudo apt-get --yes install app-install-data-medibuntu apport-hooks-medibuntu

sudo apt-get install libdvdcss2

After installing the Medibuntu repository, I realized that possibly my only reason for having it had been an attempt to make some things work on my 64-bit installation.  But soon I was to discover that I could use it to install Google Earth too.

The next step was to try the other half of the tip mentioned above.  I copied the  "installed-software" file back to my Home folder and maneuvered the Terminal cursor to that location (cd /home/ray) and then entered the needed commands:

    sudo dpkg --set-selections < installed-software

    sudo apt-get install dselect

    sudo dselect

This started dselect.  There, I went into Access and selected APT Acquisition.  It asked whether I wanted to overwrite the sources list mentioned above.  I said no.  This put me back at the next item on the menu, Update; and when I went with that, it updated something and then put me to the next item, Select.  Here, I paged through thousands of packages, not sure of what I was looking for, not seeing anything marked with boldface or "Y" instead of "n."  I bailed out of that -- it wasn't easy, but I used some uncertain combination of Esc, Q, X, space, and Enter -- and that took me to the Install menu option.  This appeared to be what I was looking for.  When I chose this one, it said it was going to get 390MB of archives and use 924MB of additional disk space, which sounded like a lot of installing and updating.  The first couple of items that it seemed to be downloading did appear on the installed-software list, so it all looked good.  But then my network connection died, so I had to start dselect again.  This time, I went directly to the Install option.  It seemed to resume where it left off, and after a while it finished downloading and began adding and removing stuff.   Then it wanted to reboot, and that was fine with me.

Previously, when I had installed 64-bit Ubuntu 9.10, I had manually added a number of programs through System > Administration > Synaptic, including particularly these:  boinc; boinc-manager; dvgrab; fdutils; gparted; mplayer; ntfs-config; ntfsprogs; p7zip-full; sysinfo; and webhttrack.  Now I checked Synaptic to see which of those had been reinstalled through the dselect process. Well, it had worked.  Every one of them had been reinstalled.  I tried System > Administration > Update Manager > Check.  It confirmed it:  everything was up to date.  That dselect process was one smooth play.  What a remarkable improvement over the Windows reinstallation process!

While I was in Synaptic, I installed googleearth (already mentioned above).  I also kept Thunderbird on only one computer because, for the time being, I didn't want to worry about keeping Address Books and Inboxes synchronized across multiple computers.  Also, after I later installed AutoFsck from a .deb download, I discovered that it, too, was in Synaptic.

Next, I installed FEBE and used it to restore my previous Firefox setup.  Unlike my previous attempt, this time I did succeed in using a FEBE backup from Windows XP to restore my Firefox add-ons and settings in Ubuntu.  I installed Google Chrome, checked to verify that Opera was still not available through Synaptic, downloaded it from its website, and double-clicked on the .deb download to install it.

I had just sent an e-mail to VMware, asking if they would allow me to downgrade my recently purchased 64-bit Workstation 7 license into a 32-bit Workstation license.  Hoping to receive a favorable answer from them, whenever they would get back to me, I went ahead and installed the 32-bit version for at least their 30-day trial period. Workstation 7 came as a .bundle file, which required the same installation steps as .bin files.  In Terminal, I navigated to the folder where I had put the download, and then typed these two commands:

sudo chmod +x VMware-Workstation-Full-7.0.1-227600.i386.bundle 

sudo ./VMware-Workstation-Full-7.0.1-227600.i386.bundle

Next, to set up my partitions so that they would be mounted automatically, I used these commands:

sudo ntfs-config
sudo gedit /etc/fstab
sudo gparted [entered in a separate Terminal session]
sudo blkid [entered in a separate Terminal session]

The first one, "sudo ntfs-config," would open a dialog offering to let me include any partitions that were not presently mounted.  It also offered write support for both internal and external devices, which I accepted, and then it modified the fstab file to include lines for ntfs partitions.  The next command, "sudo gedit /etc/fstab," opened the fstab file for manual adjustment.  Then "sudo gparted" opened the GParted program so that I could see what partitions existed, in case I wanted to add any more partitions to fstab, and "sudo blkid" told me what their UUIDs were.  This information resulted in arrangements and additions to fstab so that my partitions were in an order I liked, with explanatory comments (preceded by #), using UUIDs rather than partition names where possible, so that the fstab commands would still work if I renamed the partitions.  Examples of the results looked like this:

# Entry for /dev/sdb2 [a Linux ext3 partition] :

UUID=9cec5b4d-7e72-42a9-86ee-b59c16e6410f /media/VMS ext3 defaults 0 0

# Entry for /dev/sdb3 [a Windows partition] :

UUID=5B56363D59D5E95C /media/CURRENT ntfs-3g defaults,locale=en_US.UTF-8 0 0

Next, I did some configuring.  I went into Nautilus > Edit > Preferences and made changes there.  To prevent icons for mounted drives from appearing on the desktop, I typed "gconf-editor" and went into apps/nautilus/desktop, unclicked volumes_visible, and closed Configuration Editor.

In System > Preferences > Startup Applications, I added Chrome, Firefox, and VMware Workstation.  To get the necessary information for that, I right-clicked on the top panel near "Applications" and chose Edit Menus, then selected the item in question and right-clicked for its Properties.  To configure boinc, I went to Applications > System Tools > BOINC Manager > Next and, in the Choose a Project window, I typed in the URL (in my case, http://www.worldcommunitygrid.org/).  (I had already gone to that site and set up an account.)  Then I logged in, and back in the BOINC Manager I adjusted my preferences.

I wanted Grub2 to boot up whatever operating system I had used last, instead of always defaulting to Ubuntu, so I typed "sudo gedit /etc/default/grub"; I changed one line to say GRUB_DEFAULT=saved instead of GRUB_DEFAULT=0; I saved and closed that file; and then I typed "sudo update-grub."

Reviewing my previous post on scheduling things, I wanted gedit to be my default crontab editor, so I typed "gedit /home/ray/.bashrc" and, at the end of that file, I added a new line that said "export EDITOR=gedit" and then saved and closed .bashrc.  I had developed scripts that I wanted to run on regular occasions, so I put those in a folder on a partition that would not be wiped out if I reinstalled Ubuntu.  Then I set up recurrent entries in Applications > System Tools > Scheduled Tasks.

Among the partitions listed in fstab, I wanted some to be available to ordinary mortals (namely, me) instead of having to become root (i.e., use sudo) to mount and access them.  To do this, I typed "sudo mount -a."  This gave me an error for one partition:  "mount point /media/[partition name] does not exist."  It was an ext3 partition so, in fstab, I changed its options to be like those shown for the VMS partition (above) and then typed the following three lines (using the CURRENT partition as an example):

sudo mkdir /media /CURRENT

sudo mount -t ext3 /dev/sda3 /media/CURRENT

sudo chmod 777 /media/CURRENT

To configure VMware Workstation, I typed "sudo vmware" and went into Edit > Preferences and set as many settings as possible. I verified that the 32-bit version of Workstation was able to open the VMs I had created in the 64-bit version.  I changed Settings for each VM as needed.  (I had to resume and then shut down those VMs that had been merely suspended.)  The 32-bit version of Workstation would allow a maximum of only about 3GB of RAM.  I had hoped that meant "per session," but, alas, that was not the case; the 32-bit operating system was able to recognize only about 3GB total, even though I had considerably more than that in the system.  Within Workstation's Edit > Preferences > Memory, the maximum available for VMs seemed to be 2966MB, and I had set Workstation to use 2500MB, so as to keep some RAM available for processes in Ubuntu.  I preferred to set my VMs not to swap, for speed -- that is, to keep everything in RAM.  So when I opened one VM with 1504MB allotted to it, and then started another session of Workstation and tried to open a VM that needed 1024MB, the second one told me that only 536MB was available.  This suggested that, of the 2500MB I had made available to Workstation, about 2040MB was available for VMs.  So there seemed to be an overhead of about 230MB per VM.  I set each VM to use 1000MB and was able to open two at once.

I then exited that root session of Workstation, restarted Workstation from Applications > System Tools > VMware Workstation, and verified that the VMs worked properly for the ordinary user.  One of the things I had to adjust, in the VMs, was that audio volume was low; I had to turn it up in Ubuntu first, and then adjust it in the Windows XP VM.  I was pleased to see that the stuttering problem I had had in 64-bit Workstation was gone, though there was some undesirable static.  Also, a renamed partition was no longer shared; I had to remove the old one from VM > Settings and add the one with the new name, and then reboot the VM.  I had to change the Network Connection from Bridged to NAT.  Inside the VM, I right-clicked on each partition name to change it from the long form (e.g., "Vms on 'vmware-host\Shared Folders'") to the short form (e.g., VMs).

It seemed likely that I would be continuing to tweak and refine the setup, but for now, this appeared to give me a good working situation.  It seemed that the 32-bit downgrade had been a good idea; I really hadn't encountered any of the strange things that had complicated life in the 64-bit world.

Plugins Needed in Ubuntu 9.10

I was trying to play a .wav file in 64-bit Ubuntu 9.10 (Karmic Koala).  (This was a compressed .wav in 4-bit 22 kHz IMA ADPCM format.)  I double-clicked on it in Nautilus.  Movie Player opened up and gave me this message:

Search for suitable plugin?

The required software to play this file is not installed.  You need to install suitable plugins to play media files.  Do you want to search for a plugin that supports the selected file?

The search will also include software which is not officially supported.

I went with that.  Unfortunately, the next message said this:

No packages with the requested plugins found.

The requested plugins are:

image/vnd.microsoft.icon decoder

I clicked OK.  That gave me another message:

An error occurred

The playback of this movie requires a image/vnd.microsoft.icon decoder plugin which is not installed.

A search for relevant terms led to a thread in which someone asked whether the user had "the w32codecs" installed.  I didn't see that package in Synaptic.  But then someone else in that thread said maybe I wouldn't need it for my 64-bit Ubuntu.  One person pointed toward an extended tutorial in setting up multimedia in Ubuntu.  There was some discussion on whether 32-bit codecs (e.g., w32codecs) were necessary in a 64-bit system; the consensus (supported, of course, by the actual error message on my system) was that they might well be.  The same opinion emerged in another discussion.  The way to get those 32-bit codecs seemed to be, first, to add the Medibuntu repository to my Ubuntu installation.  The simple way to do this was to cut and paste this command into Terminal:

sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update

all on one line.  For additional multimedia options and capabilities and such, it was also recommended that I enter these commands:

sudo apt-get --yes install app-install-data-medibuntu apport-hooks-medibuntu

sudo apt-get install libdvdcss2

sudo apt-get install w64codecs

So I did that.  This all went smoothly.  I was now able to play other .wav files, but I was not able to play that particular one.  I tried playing it in Windows, using IrfanView, and got these error messages:

[filename]:  Can't read file header !

Unknown file format or file not found !

IrfanView: i_view32.exe - Corrupt File

The file or directory [filename] is corrupt and unreadable.  Please run the Chkdsk utility.

So possibly that was why Ubuntu had been unable to play it.  I had checked its properties in Ubuntu, but had not seen any such message.

Configuring 64-Bit Ubuntu 9.10 (Karmic Koala)

In a previous post, I described the steps I followed in setting up x64 Ubuntu 9.04 (as refined in a later post).  This post does the same for Ubuntu 9.10.  I won't re-describe steps that are already spelled out in some detail in that previous post and in the other webpages to which it refers.  I'll still provide most of the details here, just not as much in-depth explanation.

Deciding on a Clean Install.  I was installing on a machine where I had previously been running 9.04.  I installed 9.04 on top of 8.10 on that machine, and this seemed to lead to some unusual problems -- you know, the kind of issue that brings up almost nothing in a Google search.  The better approach was apparently to do a clean install.  So now it was time to do that, replacing 9.04 with 9.10.

My first question was, what should I preserve from my previous setup, and how can I preserve it?  One suggestion was to try this:

tar cf /media/[backup drive]/[backup folder]/[backup filename].tar /etc /home

That didn't work for me, as my /home directory contained 32GB.  Another post in that same thread suggested installing your stuff to a separate /home partition, so that your settings wouldn't be wiped out by future clean installations.  I found a guide to moving the /home partition.  I started to use GParted to make a 50GB /home partition.  I chose ext3 because ext4 still seemed to have some issues.  I discovered that Ubuntu's manual installer has an option not to format the partition you're installing to, so as to preserve your old settings.  I decided against both of these approaches because I did want to wipe out my old /home partition, with its mistakes and assorted junk.  So I installed Ubuntu as described in the previous post, working from a CD.  I went into System > Administration > Update Manager > Check.  This gave me 184 updates and a reboot.

Software Sources.  Next, I went into Applications > Ubuntu Software Center > Get Free Software > search for "restricted extras" > select Ubuntu restricted extras > Install.  Next, System > Administration > Hardware Drivers > NVIDIA accelerated graphics driver (version 185) (because I had an NVIDIA video card) > Activate > Close.  Next, System > Administration > Software Sources > Ubuntu Software tab > Download From > Other > Select Best Server > Choose Server (whichever one it highlights) > Close.  Also, in Software Sources, go to the Other Software tab, select the two entries that are already there, and click Add to add more.  The additional lines come from the X-Updates website.  There, click on "Technical details about this PPA," specify Karmic, and copy the two deb lines there, one at a time, into the APT line, clicking "Add Source" after each.  Next, on that same webpage, follow the Signing Key instructions, just below the deb lines.  Click Close.  This will bring up "The information about available software is out-of-date."  Click Reload.  If you don't get a "Reload" option when you click Close, go back into Third-Party Software and unclick and then re-click some item and try again.

Synaptic.  I had read an upgrade tip that said I could automatically reinstall my installed Synaptic applications by using System > Administration Synaptic Package Manager > File > Save Markings As > Save full state and then, after the upgrade, use Synaptic > File > Read Markings.  I had saved as advised; now I tried the read (restore) step.  It did not work well for me.  After this and a few more misadventures, I wound up reinstalling Ubuntu from scratch.  For posterity, the next few paragraphs describe the failed approach.  After that, I describe the alternate approach, the one that I had used in previous installations. 


To try the Read Markings approach, I started by going to Places > Computer and double-clicking on the drive where I had saved the backup.  Then Apply.  But that gave me an error:  "Could not apply changes!  Fix broken packages first."  So I went into Synaptic > Edit > Fix broken packages.  That, in turn, generated this message:  "An error occurred.  The following details are provided:  E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages."  Adapting some older advice, I closed Synaptic and then typed this:

sudo -i
apt-get clean
apt-get autoclean
apt-get update
apt-get upgrade
apt-get dist-upgrade

Now I tried Synaptic again.  The steps just taken did not seem to change anything; but after tinkering with the same options, Edit > Fix broken packages seemed to work, and Apply proceeded to download 259 files.  Since the more automated Markings approach seemed to work, the advice for the next installation would be to uninstall any unwanted packages before running the Save Markings step.

Instead of all that, on the second installation I selected and installed these packages from within Synaptic:  boinc; boinc-manager; fdutils (if you expect to be using a floppy drive); gparted; ntfs-config; ntfsprogs; p7zip-full; sysinfo; and webhttrack. (If numerous items come up in response to your search, click on the Package heading to sort them alphabetically. Also install other related packages, if given the option.) (If some of my later descriptions don't work for you, it may be because you didn't install one of these.)  For my e-mail, I preferred thunderbird, so I added that, and uninstalled evolution.  Some of these may ask if you want to "Mark additional required changes?" Click "Mark" and go on to the next one. Then click Apply. Some of these programs may already be shown as being installed on your system. If so, no problem.

Other Programs.  To install Google Earth, I didn't use a previous download (see above). Instead, I typed these two lines:  First, "wget http://dl.google.com/earth/client/current/GoogleEarthLinux.bin," and then "sh GoogleEarthLinux.bin" (as always, without quotation marks).

I didn't have to install Firefox -- it came installed with Karmic -- but, as in the past, I hoped to speed up my customization by using the FEBE add-in.  I had made a FEBE backup before this reinstallation.  Now, to restore my previous settings, I installed FEBE.  Unfortunately, Firefox did not seem to be functioning properly. I address this set of problems in a separate post.  (I think the problem may have been that I tried to use a FEBE backup of a Windows XP Firefox installation.  Firefox on Ubuntu does not use the same add-ons.)  To have a browser, I downloaded 64-bit Opera.  (At this point, 64-bit Google Chrome was apparently unstable.)  Opera came as a .deb file, so I just double-clicked to install it.  On the reinstall, I didn't even bother with FEBE at this point; for the time being, I just used Opera in its basic form.

VMware Workstation 7 came as a .bundle file, which required the same installation steps as .bin files.  First, I typed "chmod +x" [filename] and then "./"[filename]. I designated "/home/[username]" as the installation directory.  (In all cases, fill in the bracketed names with your actual names.)

I didn't have any .tar files to install at this point.  If I had, my notes said I should have used tar -vxf filename.tar.gz (or possibly tar xvfz instead), tar xvf filename.tar, and tar yxf filename.tar.bz2.

Drive Automount.  I wanted some partitions to be mounted automatically at startup.  In the past, I had manually edited /etc/fstab to do this.  This time, I decided to try PySDM, which was apparently short for Python Storage Device Manager (System > Administration > Storage Device Manager).  Unfortunately, my efforts suggested there were serious bugs in PySDM, so I uninstalled it and edited fstab manually.  I began by typing "sudo ntfs-config" and then "sudo gedit /etc/fstab."  I also ran System > Administration > GParted for a GUI reference, to help me see what I was supposed to be doing.  I plugged in all of my USB drives, typed "sudo blkid" to get the universal identifier (UUID) for each partition, and copied and pasted that into fstab.  I refreshed GParted (Ctrl-R) and created a comment line for each partition shown in GParted.  This was about the point when things seemed so grotesquely screwed up (because of PySDM, it seemed) as to warrant a complete reinstallation.  When I rebooted, it looked like everything was getting automatically booted without a problem.  I saved a copy of my resulting fstab in case I had to reinstall again.  I noticed that the booted partitions were all represented by icons on the desktop.  I wanted to remove those, so I typed "gconf-editor" and went into apps/nautilus/desktop, unnclicked volumes_visible, and closed the Configuration Editor, and the icons were gone.



Miscellany.  Ubuntu 9.10 used Grub2, which no longer used menu.lst.  I heard it was no longer possible to edit the Grub menu to remove entries for older kernels; instead, you had to remove the whole kernel, and then the menu entry would go away too.  ||  In System > Preferences > Startup Applications, I added Thunderbird, Firefox, and VMware Workstation.

The next steps are going to be to restore my Thunderbird profile backup and finish the automation of the rsync scripts I have been playing with for some months now.  But those steps will have to come later.

Firefox and FEBE Problems in Ubuntu 9.10 (Karmic)

As noted in a previous post, I was having problems with using FEBE to restore a profile with all of my settings and add-ons preset.  This post describes the steps I took in a failed effort to fix that problem.

I completely uninstalled Firefox, first, by searching for it in Synaptic and marking it (3.5.7) for complete removal and clicking Apply, and then by navigating to Home in Nautilus and deleting the .mozilla/firefox folder.  It was a hidden folder, so in Nautilus I had to set View > Show Hidden Files to see it.  Then I reinstalled Firefox 3.5.7 in Synaptic and reinstalled FEBE.  To run FEBE in Firefox, I selected Tools > FEBE > Restore Profile (kill the pop-up reminders) > Create new profile (I called mine Working).  This gave me a box that offered to let me name a new profile, but that was not taking any text input.

With the aid of the tutorial, I discovered that closing Firefox would actually not close the Restore Profile window.  Now I was able to create my new profile and then Start Profile Restore.  Again, it did what it did before:  "Profile restore in progress ... Please wait" continued for much longer than the "minute or two" recommended by the tutorial, and the hard drive light was not running. I killed FEBE and restarted Firefox.  It did not show FEBE as being installed.  It did show other extensions (Tools > Add-ons) that it had not shown previously.

I installed FEBE again, this time from within the Add-ons window instead of from the Mozilla webpage, and again restarted Firefox.  Now Firefox showed only the two add-ons (FEBE 6.3.2 and Ubuntu Firefox Modifications 0.8) that it had shown at the start.  I went through the profile restore steps again.  To get the "Start profile restore" button to light up, I had to switch back and forth between the default and Working profiles.  Then I started the restore again.  Again, no action.  After a minute or two, I killed it and tried restoring a different profile.  Still nothing.

Another flaky thing that Firefox was doing:  it was opening a tiny window sometimes.  This little window could be expanded, but there was nothing in it.  In Synaptic, I did a Quick Search for Firefox and uninstalled all versions that were installed.  I then reinstalled 3.5.7 and tried again in FEBE.  Still no profile restore.  At this point, I gave up and reinstalled.

Ubuntu: Schedule Items with Cron

I wanted to schedule regular backups in Ubuntu 9.10.  I had already worked out the rsync commands I wanted to use; now it was a matter of running them automatically at certain times or on certain days.  I began by seeing what was already scheduled in my crontab (i.e., my chronological table).  Actually, I had two of them:  one for me, and one for the root (i.e., administrator).  I checked them with "crontab -l" (that's a small L) and "sudo crontab -l" and both say "no crontab."  This supposedly meant that there were no crontab files in /var/spool/cron/crontabs.  I verified that via "sudo nautilus."  It seemed like that would apply to the root's cron, but I wasn't able to find any different location where the user's cron should be, so I just moved on to the next step.

The next step was to edit the crontab by using "crontab -e."  This seemed to be creating a crontab for me, as distinct from root:  it said "no crontab for ray - using an empty one."  To confirm that, I tried in a separate Terminal session with "sudo crontab -e."  It seemed to flash the same choice as had appeared for me, showing a choice of editors; but then it went directly into nano, which the other Terminal session was describing as the "easiest" of the three available editors.  So, OK, since I ordinarily ran my rsync backups as me, user, not as root, I figured I would want to set up my own crontab, not a root crontab.  (Later, I found some statements that it was a bad idea to edit root's crontab.)  So I killed that nano session and went back to the first Terminal session.  There, I chose no. 3, nano, as my editor.

The top of the nano screen was showing me "# m h  dom mon dow   command."  This was my cue for the things that I needed to enter on a line, in order to schedule a cron job:  minute, hour, day of month, month, day of week, and command.  (The leading # was to indicate that this sample line was just a comment and should not be executed.)

According to About.com, up through the week level, permissible values began at zero:  that is, minutes of the hour ran from 0 to 59, hours of the day ran from 0 to 23, and days of the week ran from 0 to 7 (where Sunday was both 0 and 7, as you prefer).  Beyond that, days of the month ran from 1 to 31, and months of the year ran from 1 to 12.  If they had names, you could use their first three letters (e.g., "Mon" and "Jul" but not "minute 23"). Cron uses the union (not the intersection) of the two day commands.  That is, if you specify a day of the week (e.g., Fri) and also a day of the month (e.g., 15), the command will run on both days (e.g., every Friday, and also the 15th of every month).  You could use an asterisk to indicate "every"; for example, * * * * * would indicate that you want to run the command every minute of every hour of every day of every month.

There were additional options for numbers below the date level; that is, these wouldn't work on days of the week or of the month.  One of these options was to use fractions:  for instance, */4 would mean "every fourth" minute or hour or whatever.  You could also use a range:  40-45 would mean it should run every minute of the hour from 40 to 45 minutes (i.e., 12:40 AM, 12:41 AM, 12:42 AM . . . 12:45 AM, 1:40 AM . . . 11:45 PM).  You could use lists, separating items with commas, so that 40,41 would mean that it should run only on the 40th and 41st minutes of the hour. So designating the hour as 0-11/2 would mean that it should run every other hour, in the morning only.  You could use a list of ranges; for example, an hour designation of 0-1,10-11 would indicate that the command should run in the first two and also in the last two hours of the morning.  Range and list commands start on the first number; for instance, 2-6/2 runs at 2 AM, 4 AM, and 6 AM (at whatever minute you specify).

There was one other category of entry:  special words.  These words would replace all five numbers.  In other words, if you wanted the precise control offered by the numbers for minute, hour, etc., use the numbers; but if you want the convenience of just entering one word without having to think much about what it means, use the word.  These special words were @reboot (run at reboot), @yearly or @annually (once a year), @monthly, @weekly, @daily or @midnight (run once a day), and @hourly.  These all run as soon as the time period starts (e.g., January 1, 12:00 midnight).  There was more to know about these commands, in the official documentation.

I decided the first thing to schedule was a backup of my CURRENT partition to a backup internal hard drive.  I wanted this backup to run several times a day.  I hadn't set it up as a RAID array because I didn't want it to happen immediately; I wanted to allow some time in case I accidentally deleted something, or made some other stupid mistake.  The more frequently it ran, the more likely it would contain the most recent version of the relevant folder - which could mean it would be more likely to have the version that existed *after* my stupid mistake.  My compromise was to set it up to run every two hours.  The cron line I used, then, was this:

0   */2   *   *   *   [rsync command]

In crontab, I put several spaces between the numbers for readability.  Here, in this blog posting, I had to use nonbreaking spaces for the display shown above, because plain old spaces tend to get ignored in HTML.  I haven't reproduced, here, the long command that I want executed, because I want to focus on the cron parts of the line.  (The rsync command of choice is shown in the previous post.)

Then it occurred to me that, instead of putting that long command in cron, where I would have to do some minor translation every time I wondered what it meant, I could probably write a basic Ubuntu shell script that would do the same thing and would allow me to add explanatory notes and other commands.  So I took a brief detour into the land of scripts.  By the time I returned and finished my look at rsync, I had two scripts.  One was called backup-hour.sh, to be run every few hours.  The other was called backup-day.sh.  I put them into /home/ray/bin and wrote the following cron lines for them:

0   */2   *   *   *   ./home/ray/bin/backup-hour.sh

0   2   *   *   *   ./home/ray/bin/backup-day.sh

The first one would hopefully run backup-hour.sh every two hours, all day and all night.  The second one was intended to run backup-day.sh every day at 2 AM.

To put these lines into crontab, I typed crontab -e.  It all looked good.  But nothing was happening.  A couple of days went by, and cron didn't run.  The problem, I suspected, was with those periods I had put at the start of my path names.  I had thought that was part of a command, but nobody else was using them in their cron files.  So I deleted those and waited until the next even-numbered hour, to see if backup-hour.sh would run.

Then I wondered whether I was saving crontab in the right place.  I noticed that nano, my default crontab editor, was saving it to /tmp/crontab.zfItNF/crontab.  Somehow, that didn't look right.  I did a quick search and found a variety of theories on where crontab should be, and none of them involved the /tmp folder.  Someone suggested typing "which crontab" at the prompt.  That came back with /usr/bin/crontab, which wasn't one of the options those other people had suggested.  I tried to save this crontab to /usr/bin/crontab and got a message that the file already existed.  I tried "gedit /usr/bin/crontab," but even with sudo I got a message that the file could not be opened.  I decided to pass on that one for the time being and, selecting a seemingly knowledgeable opinion, I thought about saving it in /var/spool/cron.  It turned out that there was a subdirectory there, and more specifically we had a file called /var/spool/cron/crontabs/ray.  When I looked in that, I saw a copy of my crontab file, the one that nano had been trying to save in a /tmp folder, except that it began with the line, "DO NOT EDIT THIS FILE - edit the master and reinstall."  So it seemed that maybe nano knew what it was doing after all.  So I let nano save crontab in that /tmp folder after all.  Then, following some advice, I decided to output the error messages, if any, to a crontab.log file.  So the first complete line in my crontab looked like this:

0 */2 * * * /home/ray/bin/backup-hour.sh 2>> /Folder1/crontab-errors.log

Unfortunately, at 4:00 PM, nothing happened.  I decided to follow the suggestion that it is much easier to use the gnome-schedule package (though there were problems for those who upgraded from Ubuntu 9.04 to 9.10 rather than doing a fresh install), so I installed that in Synaptic.  This gave me a new option at Applications > System Tools > Scheduled Tasks.  (Scheduled Tasks was apparently a simple front end for cron.)  But before Scheduled Tasks would work, I had to make sure that crontab and a program called At were installed.  Both were marked as installed in Synaptic.  Cron was for recurrent tasks, and At was for one-time jobs (e.g., run this "At" startup).

The basic idea, it developed, was that crontab -e would add scheduling files to the /var/spool/cron/crontabs folder, but it was apparently advisable to just let crontab -e do that, and not try to find and edit those files directly.  I tried typing "sudo /etc/init.d/cron restart," but that gave me a suggestion:  "Rather than invoking init scripts through /etc/init.d, use the service(8) utility, e.g. service cron restart."  So, OK, I tried that.  This gave me a long message that started with "restart: Rejected send message."  That didn't sound good, so I tried "ps -eaf | grep cron" and that gave me these three lines:

ray       8381  8343  0 19:46 pts/0    00:00:00 man 5 crontab
root      8409     1  0 19:50 ?        00:00:00 cron
ray       8416  8343  0 19:52 pts/0    00:00:00 grep --color=auto cron

When I had tried running that command previously, I had gotten only the second and third lines, not the first.  So perhaps the problem had been that my cron had not been running when I had tried to run it previously, and now it was running.  On that assumption, I could have just gone back to the command-line approach at this point, but I liked the added option of using At to schedule one-time events. But as I checked further, "crontab -l" said "no crontab for ray," so apparently crontab was *still* not running.  But no, one source said, "The output: no crontab for [username] means crontab is installed."

I found a long thread that told me I could use gedit instead of nano, to edit crontab, by typing this:

export EDITOR=gedit && crontab -e

(The "&&" part combined separate commands; apparently I could have achieved the same thing by typing these two on separate lines.)  Someone said I could make this permanent by putting the command in my .bashrc file, which they said I would find in /home/ray, which was true.  But if .bashrc hadn't been there, apparently I could have used gedit to create it, with something like this:

# .bashrc - bash config file #
# export variables
export EDITOR=gedit

Since .bashrc was already there, I just added those last two lines to the end of it.  But anyway, back at the cron issue, someone in that long thread said I could change my cron line to look like this:

* * * * * export DISPLAY:=0 && xterm [command]

if I wanted to see something on the screen when the command was executing.  But this got me back to the realization that, for all of the flexibility I was seeing as I worked my way through page 9 of that very long thread, I would probably prefer, right now, to just get something working.  So I guessed that Scheduled Tasks would work just fine if plain old crontab was working.  So, as others had done, I wrote up a simple command to test crontab.  The entry looked like this:

* * * * * export DISPLAY:=0 && xterm dir

Sadly, this did nothing.  I opened Scheduled Tasks, thinking I would try something similar there, and instead I saw that my crontab line was already there, albeit in ugly form: 

Recurrent    At every minute     export DISPLAY:=0 &amp&amp dir

Anyway, that didn't seem to be running, so I deleted it, in Scheduled Tasks, and tried doing similar as a one-time task.  Here's what I ran:

dir > /home/ray/DIRDIRDIR

and it worked!  I got a text file named DIRDIRDIR that contained a directory listing.  So it seemed the one-time part of Scheduled Tasks was working properly.  So I returned to the question of recurrent tasks.  I remembered that, in Ubuntu, we use "ls" rather than "dir."  So in Scheduled Tasks, I used more or less the same command to append updated directory listings each minute, showing the time when DIRDIRDIR had been last updated:

ls -l >> /home/ray/DIRDIRDIR

and that worked too.  So now I felt I should try again with the lines I had attempted earlier, as revised.  This time, I entered them into Scheduled Tasks rather than into crontab, so I didn't need the * * * * * parts of the entries.  So here are the commands I entered in Scheduled Tasks:

/home/ray/bin/backup-hour.sh 2>> /Folder1/crontab-errors.log
/home/ray/bin/backup-day.sh 2>> /Folder1/crontab-errors.log

I didn't actually enter them both right away; I started with the first one, and made it run just once, at nine minutes past the hour (which was about two minutes ahead of when I was working on it).  When the time came, it ran, or it seemed to:  there was now a file named "crontab-errors.log" with 0 bytes in Folder1.  That was good enough for now.  I tried another line, this time telling Scheduled Tasks to make it an "X application" rather than "Default behavior."  That didn't seem to do anything, but whatever.  It looked I had what I needed, and I could add more knowledge later.