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.)

VMware Workstation 7 Installation: Permission Denied

I had been using VMware Workstation on Ubuntu for several years.  VMware put out a new release of Workstation 7, so I downloaded it.  I tried using the familiar steps I had used to upgrade VMware.  It had been just a matter of entering these two commands:

sudo chmod +x VMware-Workstation-Full-7.1.0-261024.i386.bundle 

sudo ./VMware-Workstation-Full-7.1.0-261024.i386.bundle

This time, though, it didn't work.  The first one went OK; but after the second one, I got this:

bash: ./VMware-Workstation-Full-7.1.0-261024.i386.bundle: Permission denied

Malcolm Lewis explained that I could use ./ to execute the file after running chmod, but I could skip the chmod command and just use one command:  sh [filename].  So I tried that.  And, you know, that worked.  Or at least it went further than before.  So apparently my chmod +x command was not sufficient to make the thing executable.  Possibly I needed to use chmod 777 or something.

I say it went further because I didn't type "sudo sh"; I just typed "sh" followed by the downloaded VMware bundle file.  So after it said, "Extracting VMware Installer...done," it stopped with an error:  "root access is required for the operations you have chosen."  I did it again with sudo, and this time it ran.  End of problem!

Scanning Functionality for a Brother MFC-7340 Multifunction Device in Ubuntu 10.04

I had installed the printing functionality for a Brother MFC-7340 multifunction device in Ubuntu 10.04 (Lucid Lynx), including a Windows XP virtual machine running in VMware Workstation 7 on that Ubuntu installation.  Now I wanted to set up scanning functionality as well.  This post describes that effort.

I first verified that the scanning functionality was not installed automatically as part of the printer driver.  I went into Ubuntu’s Applications > Graphics > XSane Image Scanner.  (I was not sure whether XSane came with Ubuntu or whether I installed it separately through Synaptic Package Manager.)  XSane said it was “scanning for devices” and then reported that there were “no devices available.”  It occurred to me that this could be because I had connected the printer to the virtual machine, which probably would have made it unavailable for Ubuntu itself.  I went into the virtual machine and selected VM > Removable Devices > Brother Printer > Disconnect.  Then I went back out to Ubuntu and tried again in XSane.  I got the same result.  So it did seem that I would need to install scanner drivers separately.

The Brother Drivers for Linux webpage did have drivers and instructions for scanners.  I went to the driver download page, where I found that the MFC-7340 was categorized as a “brscan3” model.  I selected the Debian driver for the 32-bit brscan3.  There was also an option to download and install a scan-key-tool.  I wasn’t sure what that was, or if I would need it, so I held off.  The 32-bit brscan3 download gave me a file called brscan3-0.2.9-1.i386.deb.  There were different installation instructions for USB and ethernet connections.  There was also a separate webpage for Scanner Settings for Normal Users.  They had an Ubuntu 10.04 option there.  The steps I had to take there were, first, to type “sudo gedit /lib/udev/rules.d/40-libsane.rules” and then add two lines at the end of the, right before the line that began with “# The following rule will disable USB autosuspend for the device.”  The two lines I had to add were:

# Brother scanners
ATTRS{idVendor}=="04f9", ENV{libsane_matched}="yes"

Then I had to save that file and reboot the system.  When that was done, as with the printer configuration, I went through the Pre-required Procedures that seemed to apply to all versions of Ubuntu generally or to this version (32-bit 10.04) particularly.  Those steps seemed to be as follows:

sudo -i
mkdir /var/spool/lpd
apt-get install sane-utils
apt-get install psutils

I got an error for the mkdir command, as this was a step I had already done – I think when I installed the printer driver.  I already had sane-utils too, and got a message telling me to run “apt-get autoremove” to get rid of some packages that were no longer required, which I did.  I already had psutils as well.  With the Pre-Required Procedures out of the way, I was ready to follow the USB installation instructions for the scanner driver.  Having already downloaded the driver and connected the MFC-7340’s USB cable, I navigated to the folder where I had put the download and then typed this:

dpkg -i --force-all brscan3-0.2.9-1.i386.deb
dpkg -l | grep Brother

This all seemed good.  I started XSane, adjusted its settings, and scanned.  It worked with the automatic sheet feeder.  It saved in multiple formats, including JPG and PDF.  I tried scanning while standing at the scanner and punching the buttons on the MFC-7340.  That didn’t work.  That, then, was what the scan-key-tool driver was for.  From the download page, I got the 32-bit Debian brscan3 scan-key-tool driver (brscan-skey-0.2.1-3.i386.deb) and looked at the installation instructions.  They said I needed GIMP, which I already had installed (I think it came with Ubuntu), and that I also needed to have installed the scanner driver already, which I had done.  That took care of the Pre-Required Procedures.  Now, as above, I navigated to the folder where I had put the download and entered more or less the same commands as with the scanner driver, plus a couple of additional steps:

dpkg -i --force-all brscan-skey-0.2.1-3.i386.deb
dpkg -l | grep Brother
brscan-skey
brscan-skey -l

Following their additional instructions, I set the scan-key-tool to run automatically when I started the computer, by going into System > Preferences > Startup Applications > Add (suggested name = Brother Scan Key, command = brscan-skey, comment = Scan from the MFC-7340 console).  I scanned from the console.  The resulting file was saved in /root/brscan, probably because I had run all of these commands as root (i.e., sudo).  I ran brscan-skey again from my normal user (i.e., not root) prompt.  This time, I saved to Image rather than to File.  This provoked GIMP to start up and display the scan.  I saw that, again, it was saving the scans to /root/brscan (though I could only see them when I went there as root).  I changed the file name and location to a PDF in my preferred folder for scans, but GIMP was not prepared to do PDFs, so that was apparently an advantage of saving as File rather than as Image.  I tried again with GIMP, this time as a JPG to my preferred folder.  That worked, but the scankey was still saving copies of them to /root/brscan too.  The instructions said I could type “brscan-skey -u” to change the target user, so I did that as root, and then typed brscan-skey as myself.  Unfortunately, that didn’t do it; it was still saving in /root.  I tried “sudo brscan-skey -t” to stop it altogether.  That worked.  Now it wouldn’t scan from the console.  I started it as myself again.  Now it was saving to /home/ray/brscan.

The next step I wanted to take, following their additional instructions, was to modify the default script for scan-to-image so that it would save in my preferred folder as a JPG, and scan-to-file so that it would save there as a PDF.  Brother suggested changing this line in the default scantoimage script:

scanimage --device-name "$device" --resolution $resolution > $output_file

to this:

scanimage --device-name "$device" --resolution $resolution | pnmtops | gs -q -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=- - > $output_file.pdf

To edit the default script for the scanner's Image option, I typed this:

cd /usr/local/Brother/sane/script
ls
sudo gedit scantoimage-0.2.1-3.sh

Once I was in the scantoimage script, I decided to change several things, including increasing the resolution to 300.  Now, unfortunately, the script didn’t work.  After I punched the Start button on the scanner, it just sat there for a moment, and then gave a long beep and a “sane_read: Error during device I/O,” and a tiny brscan.XXXXX file would appear in /home/ray; and when I opened that file, it was all black; or if I restored the line about echoing the output to gimp, it said this:

GIMP message
Opening ‘/home/ray/brscan/brscan.3bq3GA failed: PNM Image plug-in could not open image

and then gave up.  Weird thing is, I couldn’t get it to function normally, even when I restored scantoimage-0.2.1-3.sh to what I thought was its original condition.  I stopped and restarted brscan-skey (i.e., stop with brscan-skey -t); still the same thing.  I restarted the computer and, at the same time, shut down and then restarted the printer.  Having set brscan-skey to start automatically with Ubuntu, I went right to the console and tried again.  Now it scanned.  Maybe I had needed to completely kill brscan-skey after a bad edit.  I edited scantoimage-0.2.1-3.sh again, this time making just one change and then testing it.  Everything was fine until I got to the part where I made the recommended change to the actual scanimage line in the script.  Then, once again, the scanner just started the scan and then froze.  Eventually it reset itself.  I tried again, but now it was just waiting for a few seconds and then giving me that long beep and not even trying to scan.  I commented out their recommended change and restored the way it was originally, saved, and tried again.  Still just the long beep.  So I typed this

kill -9 `pidof brscan-skey-0.2.1-3`
brscan-skey

(note:  those are backticks, not single quotation marks) and then tried scanning again, but still the long beep and the error.  Turning the printer off for 30 seconds and then back on after killing brscan-skey did the trick.  I played some more and got the long beep and error again.  This time, I didn’t turn the printer off; I just killed brscan-skey and waited for the printer to reset itself.  That worked too.  After more searching, I found what looked like it might be an answer in Stutz’s Debian Linux Cookbook (pp. 286-287), which said this:

scanimage outputs images in the PNM (“portable anymap”) formats, so make sure that you have the `netpbm’ package (installed on most Linux systems by default); it’s a useful collection of tools for converting and manipulating these formats.

Well, Synaptic told me that I did not have netpbm installed.  I installed it, using Synaptic.  I observed that a list of devices (produced by “echo 'devicenames == ' | gs -q | tr " " "\n" | sort”) contained pnm but not the pnmtops device used in Brother’s command.  Pnmtops did appear to be in Ubuntu 10.04; it just didn’t appear to be on my system.  So I changed that too.  About this time, I discovered that Ubuntu had probably been giving me error messages in Terminal after each try, but Terminal tended to be buried under other windows.  So now I got this error:

scanimage: sane_read: Error during device I/O
scanimage: received signal 13
scanimage: trying to stop scannerSegmentation fault

So I changed it back to pnmtops.  This time, I got an additional error, after the “scanimage: sane_read: Error during device I/O” message:

pnmtops: warning, image too large for page, rescaling to 0.691703
pnmtops: writing color PostScript...
pnmtops: EOF/error reading 1 byte sample to file.

It looked like almost nobody had gotten that EOF/error message.  Not a good sign!  The rescaling part did not seem to be a problem.

Around this point, I realized that I had been trying to set the scanner’s Image option to produce PDFs, when I had originally wanted to do that via the File option.  I didn’t know whether I would have any better luck editing scantofile-0.2.1-3.sh than I had had with scantoimage-0.2.1-3.sh, but I decided to try.  I was puzzled that the Ubuntu Manual said, “Never use mktemp().”  I tried their recommended alternative of mkstemp, but bash did not seem to recognize it.  After some additional playing around, I came up with this working script:

#! /bin/sh

# $1 = scanner device
# $2 = friendly name
#
# Resolutions: 100,200,300,400,600

resolution=300
device=$1
sleep 0.01
output_file="/media/DATA/Current/Scan_`date +%Y%m%d-%H%M%S`.pdf"

scanimage --device-name "$device" --resolution $resolution | pnmtops | gs -q -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=- - > $output_file

chmod 644 $output_file

This script would name each PDF by its date and time, so that they would sort in the correct order in Nautilus or in Windows Explorer.  I think netpbm had to be installed (above) for this to work.  This script changed a number of things in the Brother script, including notably the filename and location.

I took these changes to the scantoimage script as well.  That script would normally output a PPM file, so I added a pnmtojpeg conversion line to produce an output file in the better-known JPG format, for maximum compatibility with various browsers and other programs.  I set quality to 95 because, in a brief test, the resulting JPG was half the size of one set to 100.  I included a slight bit of smoothing to make the file slightly smaller and better-looking, without blurring sharp lines.  I put this JPG file into a Lossy folder, to distinguish it from a parallel process in which I used the scanner’s PPM output to create a lossless PNG version, in case I needed maximum quality.  After the scanning session, I could then easily get rid of all unnecessary copies by deleting either the Lossy or the Lossless folder (or by mixing their contents as needed).  The resulting, working scantoimage script was as follows:

#! /bin/sh
#
# $1 = scanner device
# $2 = friendly name
#
# Resolution options: 100,200,300,400,600

resolution=300
device=$1
sleep 0.01
dir_name="/media/DATA/Current/"
file_name="Scan_`date +%Y%m%d-%H%M%S`"

ppm_file=$dir_name$file_name".ppm"
scanimage --device-name "$device" --resolution $resolution > $ppm_file

mkdir $dir_name"Lossy"
jpg_file=$dir_name"Lossy/"$file_name".jpg"
pnmtojpeg --quality=95 --smooth=10 $ppm_file > $jpg_file

mkdir $dir_name"Lossless"
png_file=$dir_name"Lossless/"$file_name".png"
pnmtopng $ppm_file > $png_file

# Change, comment, or delete the next line, depending on which
# file (if any) you want to open in GIMP
rm $ppm_file

# Uncomment the next line if you want the file to open in GIMP
# echo gimp $output_file \;rm -f $output_file | sh &

As with the printer setup, the final question was whether I could use the MFC-7340 from within a Windows XP virtual machine on VMware Workstation 7.  I went into a virtual machine, opened Adobe Acrobat, and entered the commands to scan.  It did not see any scanning devices.  I cancelled out of that and went to VM > Removable Devices > Brother Printer.  I saw that there was no “Brother Scanner” option, so this did not look good.  I clicked on Connect anyway, to connect the printer, and went back to Acrobat.  But that made the difference:  now it saw both TW-Brother MFC-7340 and WIA-Brother MFC-7340.  I usually used the latter, so I went with that.  I went through all the other normal steps to make a scan.  Unfortunately, Acrobat crashed.  It had been doing that anyway in that virtual machine, so I couldn’t infer anything for sure from that.  I tried again.  This time, Acrobat sat there for several minutes with the “Transferring data...” dialog open and then finally said, “Scanning canceled.”  I tried again, this time using the Twain (TW-Brother MFC-7340) option.  It said, “Reading from the device.”  It got as far as 0% Completed, and it hung there.  After maybe 10-15 minutes, I canceled it.  Apparently scanning would not be happening from within the virtual machine.  Otherwise, though, it appeared the project was complete.

Installing a Brother MFC-7340 Printer in Ubuntu 10.04

I was installing Ubuntu 10.04 (Lucid Lynx) on a desktop computer.  I wanted to get my Brother MFC-7340 printer working from within Ubuntu.  I had not been able to make it work with Ubuntu 9.10, but now I had found a post where mdgrech described how it could be done.  The steps I took were as follows:

sudo -i

aa-complain cupsd

mkdir /usr/share/cups/model

mkdir /var/spool/lpd

apt-get install sane-utils

apt-get install psutils

It puzzled me that mdgrech’s link led to the LPR driver for the MFC-7420.  I suspected he knew exactly what he was doing; but just in case that was a mistaken link, I went to the Brother Linux driver download page and downloaded the Debian LPR driver for the MFC-7340 instead.  This gave me a file called brmfc7340lpr-2.0.2-1.i386.deb.  To install the LPR driver, Brother advised using CUPS if it was working on my system.  I wasn’t sure if it was.  I was advised to try this:  “sudo /etc./init.d/cups status.”  That said “cupsd is running.”  Now what?  I followed the links to the Cupswrapper Driver Install page.  There, I had to follow certain “pre-required procedures.”  These appeared to be more or less the steps that mdgrech had already had me take (above).  So apparently he had used the CUPS approach too.  Encouraged, I continued along this CUPS route.  There was some disagreement on the next step.  Brother said that I should turn on the printer and connect it to the computer now; mdgrech seemed to say I should install the driver first.  I wound up not connecting the printer until later.  Meanwhile, it seemed that I would need to be installing the cupswrapper driver as well as the LPR driver, so I went back to the download page and did that.  This gave me a download called cupswrapperMFC7340-2.0.2-1.i386.deb.  The next steps were to navigate to the folder where I had downloaded brmfc7340lpr-2.0.2-1.i386.deb and then type these commands:

dpkg -i --force-all brmfc7340lpr-2.0.2-1.i386.deb

dpkg -i --force-all cupswrapperMFC7340-2.0.2-1.i386.deb

dpkg -l | grep Brother

The next step was to go to http://localhost:631/printers.  It showed the printer.  So now I did turn on the printer and plug in the USB cable.  (Note that there are slightly different instructions if your connection is ethernet.)  Ubuntu saw the printer, but gave me a “Missing printer driver” note in the upper right corner of the screen, and then said “Searching for available drivers.”  Eventually it gave me a New Printer dialog.  

Note:  mdgrech had advised, instead, to go to http://localhost:631/admin, select Add printer, choose Brother MFC-7340, choose “Another Make/Manufacturer,” select the MFC-7340, and click Add Printer.  Since I had gone to http://localhost:631/printers as Brother advised, I was now at the New Printer dialog, so I proceeded from there.  I selected “Select printer from database” (with Brother highlighted) > Forward > MFC7340 for CUPS > Brother MFC7340 for CUPS [en] (recommended) > Forward.  I went with the defaults in the “Describe Printer” dialog > Apply.  I printed a test page.  It worked!

There was one other thing I needed to check.  On this Ubuntu machine, I was running Windows XP in a virtual machine in VMware, and had previously tried to install the MFC-7340 from there.  I still had it listed as a printer.  So I went into VMware at this point and tried printing from there.  The print job queued up, but it didn’t print.  I ran Brother’s Installation Diagnostics software, there in Windows XP, and it reported failure:  “Cannot communicate with the machine.”  I went into Start > Settings > Printers and Faxes (right-click) > right-click on the Brother MFC-7340 Printer > Properties > Ports tab.  I checked the box next to the USB003 port, which was the only port that specifically referred to the Brother MFC-7340.  I clicked OK and tried printing again.  Once again, it queued but did not print.  Then it occurred to me that, of course, I would have to go into VMware’s VM > Removable Devices.  There, sure enough, I saw “Brother Printer.”  I clicked Connect.  The queue dialog said, “Printing,” and then it did print.

The other thing I really wanted to be able to do with the Brother MFC-7340 was to scan.  This appeared to be an entirely different process, so I started another post for that.  Otherwise, with this step finished, I returned to the project of tweaking Ubuntu 10.04, as described in a separate post.

Tweaking Ubuntu 10.04

I had upgraded from Ubuntu 9.10 to Ubuntu 10.04 (Lucid Lynx).  Now I wanted to make some adjustments.  For this purpose, I would be drawing upon the first and second lists of adjustments I had made when I had installed 9.10.

The first of those other things was to install a PAE-enabled 10.04 kernel, so that I would have access to all of my system's RAM.  I also found that VMware Workstation 7.0 was requiring me to enter my serial number.  I had not entered it after installing it on 9.10; I had just been using the trial serial number.  Now, unfortunately, Workstation was not cooperating:  it was saying "Unknown error entering serial number."  The solution to this problem was to run Workstation as root (i.e., type "sudo vmware" at the Terminal prompt) and enter the serial number there.

Since I was doing an upgrade of a previous installation, I did not have to reinstall packages, but I did have a problem with Software Sources.  I have described that one in a separate post.  (Even if I had needed to reinstall packages, the "installed-software" trick described in the lists of adjustments (above) would have made short work of it.)  On my laptop, I was doing the same upgrade, and there I made some problems for myself when I had to interrupt the upgrade.  Here on the desktop, the next task was (as described in separate posts) to try to get the printing and scanning features of my Brother MFC-7340 printer working from within Ubuntu.  After doing that, I tackled a problem that I had wanted to solve for years:  how to import the list of AutoCorrect entries that I had created in Microsoft Word into OpenOffice.org Writer, running on Ubuntu.  That took some time, but then I was able to get back to the project of working through those notes from previous installations.

The upgrade from Ubuntu 9.10 to 10.04 had preserved much of the configuration I had already set up.  So as I worked through the Ubuntu tweaking steps described in one of my previous posts, I had to deal with only a fraction of the issues addressed there.  One was to prevent icons for mounted drives from appearing on the desktop.  That called for Terminal:  “gconf-editor” > /apps/nautilus/desktop > unclick volumes_visible.  But it was already unclicked, and yet I did have icons for mounted drives visible on the desktop.  I went into Applications > System Tools > Ubuntu Tweak > Desktop Icon Settings and clicked Show desktop icons and left everything else unchecked, but this made no difference.  I tried again, this time using “sudo gconf-editor.”  Ah, yes.  The volumes_visible box was checked for root.  Unchecking it removed the icons from the desktop.

I had not noticed, but somewhere along the line, I had evidently installed nautilus-open-terminal via Synaptic, or possibly it came installed by default.  As its name suggested, this tool added a right-click (context menu) option in Nautilus, "Open in Terminal."  Unlike Windows Explorer, this option was only available for folders in the file listing in Nautilus -- in the right pane, that is, not in the left pane that would typically show the folder tree.  In that left pane, this and other options were absent.

Had another little problem.  During the upgrade to 10.04, the Firefox icon changed, on the left-side (formerly top) panel, to a red do-not-enter or not-allowed kind of icon; and in Applications > Internet, it changed to a grey question-mark box.  I fixed this by going to the panel, right-clicking on Applications > Edit Menus > Internet > Firefox > Properties, clicking on the icon, and selecting /usr/share/pixmaps/firefox.png.  Speaking of Firefox, I wanted Ubuntu to open Firefox and Google Chrome on startup.  I wanted to add these to a script that would run at startup, since I suspected that I would be coming up with other things that I wanted to have happen at startup too.  It seemed pretty technical – beyond my current ability, anyway – but it looked like I might be able to just write a script and put it into /etc./init.d.  I typed “sudo gedit” and then created a file called /etc./init.d/a_startup_script.sh.  I put, into it, the line that I got from e.g., right-clicking on Applications and choosing Edit Menus > Applications > Internet > Firefox > Properties:  “firefox %u.”  I saved it and typed “chmod +x /etc./init.d/a_startup_script.sh.”  Then I rebooted.  This achieved nothing.  So creating a general-purpose startup script remained a goal for the future.

I also went down Gizmo’s Freeware list of tweaks.  I had already done most of the ones I wanted, but there were a few others.  One was to install Windows TrueType fonts in Ubuntu.  I decided to extend their advice somewhat.  I took a look at System > Preferences > Appearance > Fonts.  I could see that a lot of Windows fonts were not present on the list there.  So in Windows XP, I went to C:\Windows\Fonts.  I selected and copied everything to another, temporary folder called UbuFonts.  In UbuFonts, I sorted by file type and deleted the ones that were not TTF files.  Back in Ubuntu, I typed “sudo nautilus” and went to /usr/share/fonts/truetype.  It already had a folder called msttcorefonts, but with only a fraction of the fonts that I had just copied from C:\Windows\Fonts to UbuFonts, and the font files there seemed older and smaller.  I made a backup copy of the msttcorefonts folder and then copied everything from UbuFonts into /usr/share/fonts/truetype/msttcorefonts.  Now System > Preferences > Appearance > Fonts had a much wider selection.  I changed the fonts to Tahoma 10 and the monospace to Courier 10.  Tahoma allowed me to see more information on each line onscreen.

Another tweak from Gizmo called for some playing around with Compiz.  This was a bad idea, as described in a separate post.  Another tweak of interest was to clean up the GRUB boot menu.  I typed “uname -r” and saw that I was using the 2.6.32-22-generic-pae kernel.  In Synaptic, I searched for linux-image, clicked at the top of the left-hand column to sort by those that were installed, and marked for removal all numbered items other than that kernel.  In this case, that included just two items:  linux-image-2.6.31-21-generic-pae and linux-image-2.6.32-22.generic (i.e., not pae).  I did another search for linux-headers and marked all non-2.6.32-22-generic-pae items there too.  In this case, trying to remove linux-headers-2.6.32-22 threatened to remove linux-headers-2.6.32-22-generic-pae as well; but I wanted to keep that, so I didn’t remove linux-headers-2.6.32-22.  On restart, I saw that GRUB now listed just the 2.6.32-22-generic-pae kernel and its recovery mode, along with memtest and Windows XP (it was a dual-boot machine).  I went back into Ubuntu without a problem.  I did later have a VMware problem that might have been related to this, though.

Gizmo also pointed me toward a number of recommended freeware apps.  These were for the KDE (not GNOME) desktop.  I thought it might be time to try KDE, if only to check out these programs.  One was the Wally wallpaper changer, which I installed through Synaptic.  Getting Wally (and the whole KDE desktop) involved a total of 91 files.  Other interesting pieces of Gizmo-recommended software I got through Synaptic:  gtk-recordMyDesktop and Dolphin file manager.  Downloaded directly from creators’ websites, I got Wink, FreeFile Sync, and Parted Magic.  I did consider using Dropbox as well, because of its good reviews (by e.g., PC Magazine, Online Backup Tools, Laptop, and alternativeTo; but I decided that Windows Live Sync had important advantages even though I would have to run it in a virtual machine when I was booted into Ubuntu.

(Note:  a few days later -- possibly the first time I tried it after installing KDE -- Google Desktop search was no longer responding to its default Ctrl-Ctrl hotkey.  That is, its Quick Search Box was not coming up.  Something I saw on some webpage, as I was trying to fix that problem, made me wonder whether the KDE installation was to blame.  A tip that fixed it was to open the Google Desktop Search preferences and change the hotkey to Ctrl-F1.)

The last thing to do, in this round of tweaking, was to clean out unnecessary stuff from the drive on which I had installed Ubuntu, so that I could make a backup image in case I needed to reinstall – so that I could just restore the image, that is, instead of having to go back through all these steps.  This, I thought, called for something like the TreeSize utility that I had used in Windows to see where I might have files or folders taking up huge amounts of space.  Among what seemed to be several possibilities, I found an actual Linux version of TreeSize, so I downloaded that – but I also discovered Ubuntu’s Applications > Accessories > Disk Usage Analyzer, whose Treemap Chart was especially interesting.  These revealed that my Ubuntu installation was not presently very large, so I didn’t have to worry too much about shrinking it for this particular image.  It also revealed that by far the largest space hog, within that installation, was the Google Desktop index of stuff on my hard drive, at 5.2GB.  I did see that the Google Chrome cache was also taking 400MB.  I went into Chrome’s Settings (the wrench icon at the upper-right corner) > Options but didn’t see any way to control that, other than to just clear the cache.  I decided to leave it for now, and changed some other settings while I was there.  And that was it.  Ubuntu 10.04 was tweaked, at least for now.

File Is Not Accessible. Access Is Denied.

I was using Windows XP in a VMware Workstation 7 virtual machine (VM), running on Ubuntu 9.10 (Karmic Koala).  In WinXP, I had moved some files to a new folder on a compressed external USB hard drive, and now I wanted to fiddle with the contents of that folder.  Unfortunately, I got this message:

[Filename] is not accessible.   

Access is denied.

I found a post that suggested that this might have something to do with folder sharing.  I went into VMware's VM > Settings > Options > Shared Folders.  There, I saw that the external drive was not included in the folders that were being shared.  I clicked Add, typed the name of the external drive, and went browsing for its host path.  But I couldn't add it; the dialog box was not seeing it.  It also wasn't visible in Ubuntu's Nautilus (i.e., File Browser), presumably because I had already connected to it in the VM, via VMware's VM > Removable Devices menu pick.  So now I disconnected it there, went back to Ubuntu, and waited for it to show up in Nautilus.  It didn't show up.  I went back to the VM to see what was going on, but it was definitely disconnected and was no longer visible in Windows Explorer.

Meanwhile, though, the external hard drive's light was on.  It was doing something, even though it did not seem to be recognized by any physical or virtual machines.  Some hours earlier, I had started it on a project of decompressing one of its folders.  That folder contained some large files.  So now it seemed that the drive was going to just stay locked in that process until it was done.  I left it for quite a while but, hours later, the hard drive light was still on, steady, without flickering.  I shut it down and started it back up.  Now, after a minute, Ubuntu saw it.  I went into the VM and connected to it.  When the VM saw it, I went back into VM > Settings > Options > Shared Folders and tried to add it.  But the VM still couldn't see it.  I suspected that the VM was reading from the fstab.  To explore that possibility, I disconnected from the USB drive in the VM, went back to Ubuntu, and, following some advice from one of my old posts, when Ubuntu saw the external drive again, I opened Terminal and typed "sudo blkid" and copied the UUID for the drive in question (named DAILY).  In a separate Terminal session, I typed "sudo gedit /etc/fstab" and added that UUID in two lines that looked like this:

# Entry for /dev/sde5 :

UUID=ADBG2454DBD /media/DAILY ntfs-3g defaults,locale=en_US.UTF-8 0 0

I went back into the VM and connected to the external USB drive again, and then tried again with the VM's Shared Folders option.  DAILY was still not visible there.  Maybe it was a question of what drives were visible when the VM started up?  This external drive was probably not connected and turned on at that time.  I rebooted the VM to see what would happen if DAILY was connected the whole time.  That definitely took care of the drive recognition problem, but I still got the "not accessible" error when I tried to go into the folder I was trying to view.  So I went back into the VM's Shared Folders setting and tried to add DAILY to the list of shared partitions.  Unfortunately, it was still not listed.  Ah, but back in Ubuntu, I had an error message:

Unable to mount DAILY

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

mount:  only root can mount /dev/sde5 on /media/DAILY

This gave me an idea.  Did I have to be running Workstation as root in order to add DAILY as a Shared Folder in the VM?  I disconnected DAILY from the VM and went to Ubuntu to take a look at the drive permissions.  DAILY wasn't visible on Nautilus until I clicked the computer icon in the toolbar.  When I did that, it became visible on the right side of Nautilus, and that also reproduced the "Unable to mount DAILY" error message.  So it seemed that message had been generated by Ubuntu's effort to mount DAILY when I disconnected it from the VM.  But why did root have to mount DAILY?  I right-clicked on DAILY (on the right side of Nautilus) and went to Properties > Permissions.  But it said the permissions could not be determined.  So, OK, I ran "sudo nautilus" and tried that again.  But DAILY wasn't visible in Nautilus.  So I exited that and tried "sudo blkid."  DAILY was still at /dev/sde5.  nixCraft told me to make a mount point for it (in this case, "sudo mkdir /media/DAILY").  Now "sudo fdisk -l" told me that /dev/sde 5 was NTFS, in which case I could use "sudo mount -t ntfs -o nls=utf8,umask=0222 /dev/sde5 /media/DAILY" to mount it.  Now at least I was able to see that its permissions were root (not me).  Using "sudo nautilus," I went to File System > media and right-clicked on DAILY.  But I was not able to change its permissions; they changed back after I tried.  Following Merlin's advice, I went into Ubuntu's System > Administration > Users and Groups.  There, it looked like "ray" was the name of both my user and my group.  So I typed "sudo chown -R ray:ray /media/DAILY" to change the ownership of that drive (and everything on it) to ray.  This caused the external drive to grind away for maybe five minutes.  But the Permissions were still the same:  root.  Sebastian Abate made me think I might have to unmount the drive to change the permissions, and that the change of permissions would actually apply to the mount point, so I typed "sudo umount /media/DAILY."  Then I tried the "sudo chown" command again.  This time, of course, it did not make the external drive grind away.  Now I tried Sebastian's version of the "sudo mount" command:  first "sudo chmod 777 /media/DAILY" and that was the answer.  I now owned DAILY.

I went back into the VM, connected the external drive, and tried to play with it in Windows Explorer.  As I may have realized before (a day or two had passed by this point), the problem was peculiar to just one folder that I had created while the drive was owned by root.  So, OK, it seemed I needed to disconnect the drive from the VM again, go back to Ubuntu, and run "chmod -R 777 /media/DAILY."  The -R option would run the chmod command recursively, through everything on DAILY.  But that gave me "cannot access `/media/DAILY': Input/output error."  It sounded like this might have been caused by an improper shutdown, so I plugged the DAILY external drive into a WinXP computer, right-clicked on it, and did Properties > Tools > Check Now > Automatically fix file system errors > Start > Yes.  So now it would check that drive after I rebooted the Windows computer.  Meanwhile, I tried to manipulate that troublesome folder in Windows Explorer on that Windows machine, and what did I see but the same "access is denied" message!  It wasn't an Ubuntu or VM issue; it was an ntfs hard drive issue.  I rebooted and let CHKDSK do its thing.  Unfortunately, that didn't do it.  It seemed this folder was really very screwed up.  I rebooted with the Windows XP installation CD and ran CHKDSK /R from its Recovery Console.  For this 750GB hard drive, this took more than 24 hours to run twice (i.e., until CHKDSK /R reported no more errors fixed).  When it was done, I went back into that uncooperative folder.  Access was still denied.  I rebooted that dual-booting computer into Ubuntu and examined the folder there.  Ubuntu had no problems with it.  Right-clicking showed me that the folder was owned by root.  I re-ran chmod, this time specifying "sudo chmod -R 777 /media/DAILY/EXTERNAL," where "EXTERNAL" was the name of the folder in question.  This changed nothing.  I backed up another step to "sudo chown -R ray:ray /media/DAILY/EXTERNAL."  Then I re-ran chmod.  Still no change of permissions.  I tried "sudo nautilus," with Windows-style manual change of permissions but, as before, no effect.  WinXP's CHKDSK may have been good for the drive generally, but it did not seem to have changed anything regarding the recalcitrant directory.

Using Nautilus, I created a new folder, EXTERNAL2, and (in normal user mode, not root mode) I copied everything from EXTERNAL to EXTERNAL2.  Permissions were not changed.  I ran chown and chmod on EXTERNAL2.  As before, this changed nothing.  Using VMware Workstation, I went into a WinXP VM, set up DAILY as a shared folder, mapped it in Windows Explorer (Tools > Map Network Drive), and used WinEx to take another look.  Unlike in WinEx elsewhere, here I was able to view the contents of EXTERNAL and EXTERNAL2.  I deleted the contents of EXTERNAL2 in WinEx and copied them again from EXTERNAL.  Again, that in itself did not change permissions, nor did the same chown and chmod commands make any difference.  In Nautilus, I deleted EXTERNAL and renamed EXTERNAL2 to be EXTERNAL.  To delete EXTERNAL, I had to manually delete some files with names like .fuse_hidden0000ef520000009d.  In some cases, though, those files seemed to be recreated after deletion.  I found that I could delete them, one folder at a time, using the right-click Delete rather than hitting the Delete key, followed by F5.  So I did wind up with EXTERNAL2 renamed, in WinEx, to be EXTERNAL.  I bailed out of Ubuntu and rebooted into WinXP.  I noticed that, while the letters of EXTERNAL had previously been colored blue (indicating that it was a compressed folder, where it seemed that the problem may have arisen from an interruption of the compression process), this newly remade EXTERNAL folder was black (indicating no compression).  I was now able to go into EXTERNAL, see its contents, and rearrange its files and folders. I still did not know how to change its permissions in Ubuntu, but apparently that was not going to prevent me from working with it in Windows.

Summary

I think what fixed the drive was to view it in Ubuntu's Nautilus, make a copy of it, and then delete the original. I did not figure out how to change its permissions, but I was nonetheless now able to use it in Windows XP.

Problems Installing Updates on Windows XP (KB976881 and KB977713)

I ran Automatic Updates in Windows XP Pro, running as a guest machine in VMware Workstation 7 on Ubuntu 9.10 (Karmic Koala).  I had problems with two of the updates, namely, Security Update for Microsoft Office PowerPoint 2003 (KB976881) and Update for Microsoft Office Outlook 2003 Junk Email Filter (KB977713).  All other updates had installed without a problem; but when I ran these two updates, I got "Some updates could not be installed" and then the list of these two.  I went to the manual download pages for KB976881 and KB977713, but when I ran them manually (either from the website or after saving them to a named file on my system), I got "The update cannot be applied."   This problem persisted after rebooting the virtual machine and the system.  Unfortunately, searches for those messages yielded nothing helpful.

In Control Panel > Add or Remove Programs, I selected Microsoft Office Professional Edition 2003 and clicked Change.  I tried Reinstall or Repair > Detect and Repair and clicked the Install button.  This ran for a while and then said, "Installation ended prematurely because of an error" and then "Fatal error during installation."  I tried Change again, and this time chose Add or Remove Features.  Interestingly, Outlook did not even seem to be installed, leading me to wonder why Microsoft Updates was trying to update its junk email filter.  PowerPoint was installed, though.  I reversed this:  I unchecked PowerPoint, and I checked Outlook, and then clicked the Update button.  This, too, gave me "Installation ended prematurely because of an error."  I tried the same thing again, but this time I only tried one of the two:  that is, I unchecked PowerPoint, but did not check Outlook.  This, too, ended prematurely.  I tried once more, this time leaving PowerPoint checked and also checking Outlook.  Once again, installation ended prematurely.

In Add or Remove Programs, I clicked Change > Reinstall or Repair > Reinstall Office.  But that, too, ended prematurely.  So, using the last card in the deck, I chose Change > Uninstall.  This successfully uninstalled Office 2003.  While I was removing things, I also tried to uninstall Microsoft Office Live Add-in 1.3, but evidently I should have uninstalled that before uninstalling Office.  I ran a cleanup program (Advanced WindowsCare V2 Personal) repeatedly, until there were no more registry errors, and then reinstalled Office 2003.  Early in the installation process, I got a message, "Setup has detected pre-release or trial versions of Microsoft Office products on this computer.  To continue installation, Setup must remove these products."  This was a surprise to me, but I said OK.  I did a Custom Install, installing everything but InfoPath, which I never used.  When installation was done, I did not go immediately to look for updates on the Web, but instead installed Service Packs 1 and 2 from my computer, since I had already downloaded them.  Then I went to the Office Update page and saw that I probably should have just installed Service Pack 3, since it seemed to include SP1 and SP2.  I downloaded SP3 so I would have it for future use, and installed it from the download.  Then I went to Microsoft Update and ran repeated Express installations until there was nothing left, followed by a Custom search, to see what else they had for me.  There was nothing.  Just to be sure, I rebooted and tried the Custom search again.  Still nothing.  It seemed I had resolved the problem.

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.

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.