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.

VMware in Ubuntu: Failed NVIDIA Fix; Other Fixes

This is a continuation in a series of posts on the process of transitioning from Windows XP to Ubuntu (version 8.04, Hardy Heron), on an AMD X64 system, using 64-bit Ubuntu. I decided that virtualization, and VMware Workstation 6 in particular, would be an essential tool in making that transition successful. The most recent step involved the successful restoration of a previous backup of the Linux system using Acronis True Image 11 Home backup software. Now that I had done that, I found myself having to reinstall a few programs that I had installed since the date of that backup, and also having to install some new stuff. This post describes those continuing steps. Now that I had a working system again, I tried VMware Workstation. It ran, but its memory was still set at 4384MB, which had been insufficient to run three 1GB virtual machines and two 512MB VMs (that is, three VMs in which I had allocated 1GB of RAM each in Workstation, and two more that were given 512MB each). My experimentation had suggested that 4500MB was sufficient for that purpose. But I had seen the hard drive working really hard to load and manipulate all of that stuff. I had gravitated toward a concept where I would use a 1GB machine to save the current status of a single project, mostly containing Microsoft Word and Excel files and Adobe PDF articles. I would just suspend the current state of a virtual machine in VMware Workstation when I was done with it for the present. I didn't expect to need to have three different projects open at once, since my projects were typically independent of one another. So I decided to make more RAM available to the underlying Ubuntu layer, where VMware ran, by cutting back to just two 512MB and two 1GB VMs open at any one time. At the bare minimum, that should have required at least 3072MB (2 x 512 + 2 x 1024) of RAM. But by that calculation, I should have been able to run two 512MB machines and three 1GB machines with 4096MB, when in my experience 4384MB had not been enough. I didn't know exactly where the cutoff was, but we seemed to need at least a 7% overhead but not necessarily as much as 10%. Using the 10% figure for now, I restarted Workstation as root ("sudo vmware") and allocated 3379MB in Edit > Preferences > Memory. I noticed that VM > Settings > Options > Shared Folders indicated that those partitions which I had not accessed in the current Ubuntu session received a "The path does not exist on this host" error message, so I needed to review the changes I had made to /etc/fstab to mount all partitions at bootup. A quick glance suggested that I might just replace it with the copy of fstab that I had just recently saved in the Files.tgz backup (above). Unfortunately, I could not just copy fstab from that files.tgz archive using Archive Manager (which had opened up when I had double-clicked on files.tgz in Nautilus (i.e., File Browser). I had to extract it to somewhere and the cut and paste it into /etc. I restarted the computer. Ubuntu loaded without a problem this time. I started up Workstation and powered up two 512MB and two 1GB machines. Before I could do that, I had to enter my serial number, having upgraded from trial to registered user since the date of the Acronis backup. When I tried to power up the second 1GB machine, I got an indication that I needed 3386MB, not 3379MB. So my 10% calculation had actually fallen 7MB short; the safer figure would have been 11%, or 3409MB (i.e., 3072MB of RAM for the actual machines, plus up to 11% for overhead). I could have gone with exactly 3386MB, but the wording of the error message led me to think that this could fluctuate somewhat. But anyway, on a superficial level at least, VMware seemed to be functioning fine following the Acronis restore process. It did not seem that having more memory available was making any difference in Workstation's performance. Meanwhile, I was having to sit and wait for machines to suspend or restore. So after some minor tinkering with a couple of VMs, I suspended them all, shut down Workstation, restarted as root, and upped the total RAM available to VMs to 4500MB. That was more like 10% above 4096MB, but I had already found that 4500MB was enough. These calculations were rough, and I could have researched the matter, but RAM was not that tight for me. I noticed the Desktop didn't have the right icons, so I moved whatever was on there to a holding folder and restored my desktop files and shortcuts from files.tgz. They weren't all working quite right, though. I figured I had probably better work through my notes, or at least skim them, starting from the date of the Acronis backup. Most of the relevant notes were contained in a single long post. The first thing was that my setxkbmap launcher, which I had placed on my desktop and occasionally used to fix some screen and keyboard problems caused by going into full-screen view in VMware, was not operational. I thought that would be easily fixed by clicking its Properties > Permissions > Allow executing file as program. Maybe it was; maybe it was working; but I wasn't able to move between Ubuntu desktops by scrolling my mouse wheel, and I had thought setxkbmap had been the fix for that. I didn't try to fix the Adobe Flash plugin problem this time around. It was a little confusing. I had thought that my 64-bit Ubuntu installation was unable to run it, but I had then noticed that it (or something like it) seemed to be running just fine in Ubuntu on the secondary computer. Maybe I had installed a fix there and had forgotten about it. Whatever. I felt I would have to work through that issue later on, unless the next version of Ubuntu fixed it for me. I hadn't yet completed the project of setting up desktop icons I could click on to run specified programs or to open specified files or folders each day, or week, or month. I had set that up on the secondary computer, but had not yet proceeded with it on the primary computer. So that was one more issue from the past two weeks that I would be dealing with later, but that I did not need to fool with right now in order to get my system caught back up to where it had been before it went south and I needed to restore the Acronis image. I also wanted to get Google Earth working again. I had the shortcut on my desktop, but it was not operational. It also wasn't listed in my Applications. I searched this blog for information on how I had done it last time. I found only a brief mention, with a link to a webpage that advised me to use wget to download the stable version. That reminded me to take a look in System > Administration > Synaptic Package Manager. I searched and found that I had apparently already installed googleearth-package -- which wasn't surprising, since I remembered wrestling with it several times -- with eventual success, as I recalled. I usually used it on the secondary computer, but it did seem that I had gotten it running on the primary computer as well. I hit Alt-F2 for a command box and typed googleearth. That didn't work. Neither did googleearth-package. In File Browser, I searched File System for google. Turns out there were tons of files naming Google Earth or googleearth or whatever, but I wasn't seeing anything that looked like a clickable icon. Since I wasn't too sure how to start the program, and also wasn't sure it had been functioning correctly even at the end of the previous installation, I decided to uninstall and reinstall it in Synaptic. But where had it gone? I couldn't find it in File Browser, and typing googleearth or googleearth-package accomplished nothing in Terminal. I searched File System again, this time for googleearth. The search turned up a googleearth-package folder containing a README.Debian file. When I opened that text file, I saw an instruction to run make-googleearth-package. I did that and, as promised, it created a Debian package which, in this case, was called googleearth-package_0.5.2_all.deb. The README said I coudl install that package with the command "dpkg --install." I typed "man dpkg" in Terminal to see the manual on this dpkg command. It said dpkg was the Debian package manager, and the syntax was "dpkg [options] action." "Install," it said, was an action, and the complete syntax for that part of the command was "--install package_file." So it sounded like what I actually needed to type was "dpkg --install (packagename).deb." (I had to use parentheses instead of angle brackets, in that sentence, because I had slowly learned that Blogger would interpret angle brackets as HTML commands, i.e., they would vanish from my typed text.) I tried that command in Terminal and it said, "Requested operation requires superuser privilege," so I did it again with "sudo" in front. (Just typing the up arrow, of course, would bring previous commands back to the cursor, so that I did not have to retype them in full; and Home would take me to the start of those previous commands to insert words like "sudo.") Unfortunately, this command yielded a "Cannot access archive: No such file or directory" error. In Terminal, using cd commands, I navigated to the folder where the .deb package had been saved (found by right-clicking on the item where it showed up in the File Browser search), namely, /var/cache/apt/archives, and retried the command there. This time it ran. But I couldn't figure out what it had done, or where it had done it. There weren't any Google Earth icons on the desktop or in Applications, and the README didn't say anything further. I did another search for Google across my entire File System in File Browser, and that turned up a bunch of things, but nothing I could identify as specifically the launcher for Google Earth. I typed Alt-F2 and typed googleearth in the Run Application box, but neither that nor googleearth-package would do anything except give me error messages. After scanning a few discussion threads, I went back into Synaptic and marked googleearth for complete uninstallation. Most of the googleearth entries were now gone from my search of File System, which I had left open during this process. I still had the .deb file and a GoogleEarthLinux.bin file, so I deleted both of those manually. Then I tried a different approach, which required me to type "sudo apt-get install googleearth-4.3." It didn't work, probably because I had failed to first enable the Medibuntu repository:

sudo wget http://www.medibuntu.org/sources.list.d/hardy.list -O /etc/apt/sources.list.d/medibuntu.list sudo apt-get update && sudo apt-get install medibuntu-keyring && sudo apt-get update

(The word wrap may be confusing. There is a total of just two commands there, even if they wrap to four or more lines in this post. In other words, enter all of the first quoted paragraph, above, on one line, and then enter all of the second quoted paragraph on the next line.) I did that, and then tried again with "sudo apt-get install googleearth-4.3." That gave me a Google Earth icon under Applications > Internet, and when I clicked it, Google Earth 4.3 ran. It gave me an error message: "Unknown Graphics Card" and "Google Earth is unable to identify your graphics card." They gave me a link to a webpage that offered driver download and install instructions. But when I clicked on that link, I got another error message:

Could not launch any web browser. Please make sure you have set the $BROWSER environment variable to the filename of the web browser we should launch!

Very few webpages came up in response to my search for this error message, and the ones I saw did not have an answer. I posted a question on that. The answer, which came back shortly, was as follows:

This is how you export a variable (firefox is used in the example): export BROWSER=/usr/bin/firefox This variable only keeps its value until you close the terminal you typed it in. To make it permanent, add it to end of your .bashrc file.

Now I had to find .bashrc. A search of File System turned up four possible candidates. Two were named bash.bashrc and two were named dot.bashrc. I looked at all four of them in gedit (Text Editor). They were all different, but their differences did not provide obvious clues to me. I looked at their properties and noticed that one of each was in /usr/share/doc/adduser/examples/adduser.local.conf.examples. "Examples" sounded like a reference source rather than an operating folder, as compared to /etc or /usr/share/base-files, which was where the other two were located. Between those two, I guessed that bash.bashrc in /etc sounded more official than dot.bashrc in /usr/share/base-files, primarily because /etc seemed to be where fstab and other actively used bootup-type scripts were located. So I typed "sudo gedit /etc/bash.bashrc," created a new last line in it, and typed "export BROWSER=/usr/bin/firefox" there. I tried starting Google Earth, but by this point I had been having the NVIDIA low-resolution problems described below. I got a low-resolution notice from Google Earth, and when I clicked OK on it, the system crashed and restarted. So I couldn't tell, at this point, whether the suggestion had worked or not. While I was waiting for the answer to that BROWSER question, I went ahead and entered the URL manually. Their search page didn't help me, so I entered my own search. One of the few pages that came up reminded me to check the obvious thing: System > Administration > Hardware Drivers. Somehow my NVIDIA accelerated graphics driver had gotten turned off. I enabled it. It said, "Needs computer restart," so I restarted. Or at least I tried to. The system turned off, but she no start again. I punched Reset, and it started to go, but then I got "No Signal," the hard drive light flickered a bit more, and then nothing, again. I did Reset again, and this time went into Recovery Mode in GRUB. The dpkg process there noticed that I needed some upgrades, apparently because I had now enabled the Medibuntu program repository, so it installed those. I also ran the xfix option, and then resume. So maybe it was the Medibuntu deal that was causing the boot problem. Reboot continued normally. Now, back in Ubuntu, I double-checked the hardware drivers, and -- what's this? -- the NVIDIA graphics driver was still not enabled. So, OK, I clicked it again, restarted again, and again got "No Signal" and then a blank screen. Was this going to be a permanent feature of my system from now on? I punched reset and did the recovery thing again. I noticed, when xfix was running, that it said, "Overwriting possibly-customized configuration." After I hit "resume," the system booted normally. Checked the hardware drivers again; enabled them again; restarted again; No Signal again; punched Reset again; recovery mode again. This time, I ran only the dpkg fix, not the xfix fix in recovery mode. No Signal! So the xfix fix was fixing the damage caused by trying to use the NVIDIA drivers. This wasn't what I desired. Reset; recovery mode; this time just do xfix. Ran it twice by mistake. Back in Ubuntu: one more for the road, just to confirm that xfix and the NVIDIA driver were opposing one another. Hardware drivers enabled again; restart required; recovery mode; try Resume without running xfix; No Signal. Reset; recovery mode; xfix only; resume; good boot; NVIDIA driver was disabled. I found a thread that said I should hit Ctrl-Alt-F1. I did that, and I was at a black-and-white command-line screen. It required me to enter my ID and password. The advice was then to type "/etc/init.d/gdm stop". That stopped the GNOME Display Manager. Next, I was supposed to "Go to the directory where the driver package is storeed and run "sh ./NVIDIA(driver package name).run". I had no idea where that directory would be. Here on the secondary computer, I did a search in File Browser for NVIDIA*.run, because that's how I would have done it in Windows, but of course that turned up nothing. I read the rest of that thread and it seemed this advice didn't work for everyone. I noticed they were talking about EnvyNG and downloading various NVIDIA drivers, and this was just where the system had gotten screwed up before, requiring a complete reinstall from my Acronis True Image backup. Before crossing that bridge, it was time to do another Acronis backup, so as to lock in the gains that I had achieved thus far. After doing the backup, I searched File System on the primary computer for NVIDIA- and found all kinds of stuff, but nothing in the nature of NVIDIA-*.run. With the search results still visible, I went into System > Administration > Synaptic Package Manager and searched for nvidia. I uninstalled several nvidia packages. This removed almost all of the items from the search box -- every installed nvidia package except some jockey programs. The NVIDIA drivers were no longer visible in the Hardware Drivers box. I rebooted the system. I decided to start with the EnvyNG approach, since that seemed easiest. So I searched for that in Synaptic and selected envyng-gtk for installation. I installed that and then ran it from Applications > System Tools, selecting Automatic Hardware Detection. When it was done, it wanted me to restart the computer, which I did. I got "No Signal" and then a dead computer. I did the routine: punch reset, select the recovery mode option in GRUB, run the xfix option, and then resume. I ran EnvyNG again, and this time selected manual installation of the driver and chose the second most recent one, 96.43.05, rather than 173.14.12. EnvyNG ran and allowed me to reboot again. In each of these many reboots, I would get a number of messages, some of which looked like error messages, from Ubuntu; but typically I did not understand them and/or they would flash by too quickly. So I had not been trying to fix each of them, though I began to think that maybe I should have been. Anyway, this NVIDIA driver failed too: No Display and a dead machine. I did the recovery mode routine again. I tried EnvyNG one last time, choosing the oldest driver shown: 71.86.04. This didn't work much better: I didn't get a dead machine, but I did get the "Ubuntu is running in low-graphics mode" message. Since the bootup did at least complete this time, I tried System > Administration > Hardware Drivers. It said "No proprietary drivers are in use on this system." So this was a bust. At this point, I got a notification, "Software updates available," so I ran that, to see what would happen. My guess was that these were packages I had incidentally uninstalled, when I was uninstalling all those nvidia packages earlier. After they installed, there was still nothing listed in Hardware Drivers. I rebooted, just for old times' sake, and I was still in the same boat: poor resolution, nothing in Hardware Drivers. I concluded that the EnvyNG approach was not going to work on this computer, so I used it to uninstall the drivers, and then I uninstalled it in Synaptic. It now occurred to me to try downloading the drivers directly from NVIDIA's website. For my EVGA 256-P2-N624-AR GeForce 7900GS video card, the recommended driver, provided by their recommended manual search, specifying 64-bit Linux, was indeed the version 173.14.12, released July 30, 2008, that EnvyNG had identified. Their recommended steps, for installing this driver, were basically (1) download the driver file, NVIDIA-Linux-x86_64-173.14.12-pkg2.run; and then (2) figure out where it went -- to the Desktop, in my case; and then (3) log in as root and navigate to that location -- in my case, it was "cd /home/ray/Desktop"; and then (4) type "sh NVIDIA-Linux-x86_64-173.14.12-pkg2.run" to install. But I wasn't out of the woods yet. I got an error message: "You appear to be running an X server; please exit X before installing." They directed me to "the section INSTALLING THE NVIDIA DRIVER in the README available on the Linux driver download page at www.nvidia.com," which as far as I could tell does not exist. I did a couple of Google searches and finally found chapter 2 of the NVIDIA Accelerated Linux Driver Set README and Installation Guide. Chapter 2, Installing the NVIDIA Driver, recommended that I exit the X server and kill all OpenGL applications; and for guidance in that, they directed me toward chapter 8, Tips for New Linux Users. It recommended editing /etc/inittab, which did not exist on my system. A search of the file system revealed nothing called inittab except a Perl script, "migrage-inittab.pl," which appeared to be designed to edit inittab if it existed. After several searches, I finally found someone who claimed that inittab had been replaced, in Ubuntu, by upstart. This was not too helpful: a search of my file system turned up a dozen or more files or folders whose names mentioned "upstart." Basically, these NVIDIA instructions were not tending to provide very useful guidance to me. I looked further. A Debian website said that, aside from 0 (halt) and 6 (reboot), runlevels were either 1 (single-user, troubleshooting mode) or 2 through 5 (all the same, all multiuser mode). It said you could determine your current runlevel by just typing "runlevel" at the Terminal prompt. I did. I got back N 2, meaning I was on runlevel 2. I found another thread with more advice that wasn't crystal-clear. I posted a question on it and got a response within 10-15 minutes. The essence of the instructions, in my case, was:

(1) Use Ubuntu's shutdown button and select Log Out. (2) Hit Ctrl-Alt-F1. (3) Log in. (4) Type this to stop Gnome: sudo /etc/init.d/gdm stop (5) cd /home/ray/Desktop (which is where the downloaded NVIDIA installation file was). (6) Type this to make sure the NVIDIA installer has executable permissions: chmod +x NVIDIA*.run (7) Run the installer: sudo ./NVIDIA-Linux-x86_64-173.14.12-pkg2.run

I did that and got this message:

No precompiled kernel interface was found to match your kernel; would you like the installer to attempt to download a kernel interface for your kernel from the NVIDIA ftp site (ftp://download.nvidia.com)?

It sounded like the kind of offer I couldn't refuse. I guessed this came up because I had uninstalled so much NVIDIA stuff. Next, it said,

No matching precompiled kernel interface was found on the NVIDIA ftp site; this means that the installer will need to compile a kernel interface for your kernel.

Again, I was the very picture of agreeableness as I clicked OK, that being the only option available. I also went right along when they suggested,

Install NVIDIA's 32-bit compatibility OpenGL libraries?

that being, again, the default (although they did give me a chance to say no). And now I had this:

Would you like to run the nvidia-xconfig utility to automatically update your X configuration file so that the NVIDIA X driver will be used when you restart X? Any pre-existing X configuration file will be backed up.

And of course you know what I said. That completed the installation. The advice from my posted question now continued as follows:

(8) When it has built and installed the new kernel module and libraries you should be able to restart Gnome (if you've got the Ubuntu LRM (Linux Restricted Modules) installed you might see an error report due to a bad script in /sbin/lrm-video - if that happens, ask me for how to fix it. sudo /etc/init.d/gdm start

I typed that last line at the prompt and, hard to imagine, I got -- would you believe -- No Signal! Dead monitor! I updated my posted question but, you know, this time I was not getting such a quick response. As of 14 hours later, nothing. It was time to review the situation. I needed to move this project ahead, as I had big plans for this whole VMware setup. I seemed to have a graphics problem that not everyone with this hardware and software combination was having. Something had evidently happened to my Ubuntu installation to make it graphically fubar. I could restore the Acronis backup again, but apparently the seeds of destruction had already been sown at the time when that backup was made. I could reinstall Ubuntu from scratch, and maybe that wasn't going to be such a big deal. I hated not to solve the problem. The previous thread had been in the x64 Ubuntu forum. I decided to post a revised version of my question in the Hardware & Laptops forum. I had a response in 40 minutes, containing a number of bits of advice. I didn't understand them all -- for example, the advisor recommended "boot the newer kernel," but I had no idea what that meant. I updated my question and then set to work on the parts that I could understand. One was to use nvidia-glx-new, so I went to Synaptic and installed that. The person had advised "remove the installed mess," but in my search for "nvidia" in Synaptic, this would now be the only installed package other than jockey-common and jockey-gtk, which were user interfaces for drivers. But Hardware Drivers still said, "No proprietary drivers are in use on this system." Nothing had changed in the display. I rebooted, to see if that would make a difference. It didn't. The person also recommended looking at a website, but I had already tried its advice and it hadn't worked. I was not having these problems with the secondary computer. It didn't appear to be a fundamental problem with Ubuntu or NVIDIA. The system was just messed up, and there didn't appear to be any more obvious solutions to work through. Another hour had passed and my posted questions had received no further responses. It seemed to be time to bite the bullet and reinstall Ubuntu, not from the Acronis backup, but from scratch. I reviewed the advice I had received earlier on how to do that, to make sure I had already put everything into place. It seemed safe to proceed with a reinstall. That became the subject of another post.