Ubuntu 10.04: Connecting to Synology DS109 NAS

I had tried once before to connect a Synology DS109 network attached storage (NAS) device to a computer running Ubuntu 10.04 (Lucid Lynx).  It was a frustrating, confusing experience.  But when I rebooted that computer into Windows XP, it connected it right away, with a little help from Synology's extremely responsive tech support.  Now I was ready to try again in Ubuntu.

The first part was easy.  I navigated to the folder where I had placed the downloaded, unzipped copy of Synology Assistant for Linux.  That is, in Ubuntu's Applications > Accessories > Terminal, I typed "cd /media/LOCAL/[foldername]."  (If there are spaces in the foldername, you would have to put quotation marks around everything after "cd.")  This folder now contained a couple of "How to Install" (or Uninstall) items and a file named "install.sh," along with the .tar.gz file.  I typed "sudo sh install.sh" and that installed Synology Assistant.  I designated /usr/local as the install path.  It told me that I could run the Assistant program from /usr/local/SynologyAssistant/SynologyAssistant, or through the symbolic link at /usr/local/bin/SynologyAssistant.  I right-clicked on the word "Applications" on the menu and chose Edit Menus > System Tools > New Item.  I filled in the name as Synology Assistant and I browsed to the symbolic link and selected it.  Now I had a working menu link under System Tools.  I ran that and got the Management tab in Synology Assistant.  I double-clicked on DiskStation and that opened up a tab in my Internet browser.  In theory, I could access the Synology DS109 from here.  I closed the Assistant and logged in on the browser tab.  I went into the File Browser and, what do you know, it was all working fine.  Having already run the firmware updater on the DS109, as described in the previous post, I didn't need to do that again, as I confirmed in Synology's Control Panel > DSM Update.  In short, it seemed that the easy approach, for this part, would have been for me to start with the Windows setup, where I was more familiar with everything, and set up the DS109 that way, and then come to this point in Ubuntu.

Now there was the matter of being able to work with files and folders on the DS109 from within Nautilus or Terminal.  This was where I had gotten stuck last time.  In Nautilus, near the top left corner, I clicked on the Tree option that I normally used and changed it to Places.  It showed several items that seemed to be a legacy of my previous attempts to set up networking. 

At this point, I contacted Synology tech support again.  They had used TeamViewer last time to troubleshoot my problem, so I went to PortableLinuxApps.org and downloaded TeamViewer 5.  It downloaded to my home folder.  I wasn't able to figure out how to run it, so I posted a note on it.  I tried to show my network devices by typing "sudo lshw -C network," but that just showed me my ethernet controller.  Meanwhile, though, Synology tech support pointed me toward an article on their wiki, on how to map a network drive in Linux.  In essence, they had me type these lines:

sudo mkdir /mount/SYNDATA
sudo gedit /etc/cifspwd

(I tried using that second line because what they actually recommended, "echo username=[username] > /etc/cifspwd," gave me a "Permission denied" error, even when I preceded it with "sudo."  So on the first line of that blank new cifspwd file that I was creating in gedit, I typed the Synology username I wanted to use, and on the second line I typed that username's password.  I hit Enter after the password but didn't type anything on the third line.  I saved and closed the cifspwd file.  This, however, was not the right approach.  After some trial and error, I guessed that maybe what I was supposed to put into the cifspwd file was not this:

[username]
[password]

but rather this:

username=[username]
password=[password]

I had assumed that the program would know that what I was typing on the first line was the username, but now it seemed that, no, I had to say so.  So if my username was "ray," then the first line would read "username=ray."

This got me partway there.  The other part was to type "sudo gedit /etc/fstab" and add these two lines to the fstab:

#Entry for SYNDATA
//192.168.2.1/SYNDATA                /media/SYNDATA        cifs    user,uid=ray,gid=users,rw,suid,credentials=/etc/cifspwd,iocharset=utf8 0 0

where 192.168.2.1 was the number I got from Synology's Main Menu > System Information > General tab > Network section > IP address and "ray" was the username on the computer (not on the Synology).  I found that, if you had more than one device like SYNDATA, you could still use the same IP address on a separate fstab line, and otherwise everything except for the name (e.g., SYNDATA) would be the same.  After finishing my edits to fstab, I saved and closed it and typed these lines:

sudo chmod 0600 /etc/cifspwd
sudo mount -a

First time around, when I had the wrong fstab entry (i.e., referring to "synologybox" rather than 192.168.2.1), this gave me an error:

mount: wrong fs type, bad option, bad superblock on //synologybox/SYNDATA, missing codepage or helper program, or other error (for several filesystems (e.g., nfs, cifs) you might need a /sbin/mount. helper program)
In some cases useful info is found in syslog - try dmesg | tail or so

I had also gotten another error, "mount point /media/SYNDATA does not exist," but I had fixed that by typing "sudo mkdir /media/SYNDATA."  In the course of troubleshooting, again with great help from the Synology tech support lady, I also discovered the alternative of mounting the DS109 from the command line, with something like this:

sudo mount -t cifs //192.168.2.1/SYNDATA /media/SYNDATA -o username=[username],password=[password],iocharset=utf8

A bit of playing with that led me to discover that the password I was using contained an exclamation mark (!), and while that was no problem when logging in from the Windows machine, it was a problem on the Ubuntu machine, at least if I was logging in from the command line.  After adjusting to resolve that problem, I was able to connect to the Synology, and now I was showing SYNDATA as a drive in Nautilus, just like other partitions.  I still wasn't sure what to do about those Windows Network and DISKSTATION entries that showed up in Nautilus > Places > Network, but I decided to let that be a problem for another day.  I typed "sudo gedit /etc/fstab" and corrected the line to read as shown above.

Incidental notes:  another troubleshooting step taken at some point (not sure when) was to type "sudo mount -t cifs."  Another problem was the demand, "Enter password to unlock your login keyring," but every password I tried failed.  I wanted to bail out, but the thing kept giving me the same dialogs.  I had to use Force Quit to get it to shut up.  Second time around, though, I tried Cancel instead, and that let me go right on through.  Weird.

Also, at one point in the troubleshooting process, the computer became completely unable to contact the outside world.  Firefox wasn't reaching webpages, and some of my Synology-related commands were producing a "Network is unreachable" error.  That seemed to be a pretty common problem.  I fiddled with some random commands, and it seemed that one of them had adjusted the situation.  The command in question might have been "dhclient eth0" but more likely was "/sbin/route add -net 0.0.0.0 gw 1.1.1.1 eth0" (replacing 1.1.1.1 with 192.168.2.1 in my case -- see above).  But then that turned out to be a false dawn; I was soon back at the "network is unreachable" error.  A day later, however, without any intervention by me other than to reboot the system, the computer was able to go online.

So at this point, writing up these notes a day or two after I was finally able to get to the Synology DS109 through the Ubuntu machine, the main things that I did seem to have been to add the username and password to the cifspwd file in the correct format and use the right syntax in the fstab entry, as shown above.

Ubuntu 10.04 Installation: The Streamlined Version

In another recent post, I described the process of installing Ubuntu 10.04.  This post offers a streamlined version of that post.  That is, it describes another such installation, performed on the basis of that post.

The first step was to install Ubuntu from the live CD.  As before, in this step I installed everything into one root partition.  When installation was complete, I copied my saved fstab from a separate partition to replace the existing /etc/fstab, and then typed "sudo gedit /etc/fstab."  There, I replaced the UUID for the root partition with the new one shown in another Terminal session via "sudo blkid."  I saved and closed fstab.  This part still did not go smoothly -- I still had not mastered the translation of the Ubuntu Community Documentation webpage into terms that fit my situation -- but essentially I typed "cd /" and then "sudo mv /home /old_home" to park the newly installed but largely empty /home folder; then "sudo mkdir /media/home."  On reboot, my desktop was restored to its previous condition.  I deleted the /old_home folder.

Next, I went to the folder where I had saved my backup copy of sources.list and typed "sudo cp sources.list /etc/apt/."  I opened sources.list, copied the commented command lines, and ran them.  They generated what appeared to be error messages.  In Software Sources, I triggered a reload.  It closed without errors.  In Synaptic, I installed these programs:  acroread, acroread-fonts, adobe-flashplugin, boinc, dvgrab, fdutils, gparted, mplayer, nautilus-open-terminal, ntfs-config, p7zip-full, sysinfo, ubuntu-tweak, unetbootin, and webhttrack, as well as these font packages:  ttf-mscorefonts-installer, sun-java6-fonts, ttf-sil-gentium, ttf-sil-gentium-basic, ttf-dustin, and ttf-georgewilliams.  As before, I typed "sudo sh" to install my .bin and .bundle downloads (e.g., GoogleEarthLinux.bin) and double-clicked to install my .deb downloads.  Then I went into Update Manager, and ran and reran it until I was all caught up.

Monitor driver installation and BOINC configuration were as described in the "Settings and Adjustments" section of the previous post.  The GRUB2 menu edits, as described more carefully in that post, were as follows:  to get rid of the Memtest+ options, I typed "sudo chmod -x /etc/grub.d/20_memtest86+."  To let Ubuntu remember which operating system it had used last, I typed "sudo gedit /etc/default/grub," changed the first line to be "GRUB_DEFAULT=saved," and added a second line that said "GRUB_SAVEDEFAULT=true.  To limit the number of Ubuntu kernels shown, I typed "sudo gedit /etc/grub.d/10_linux," added "GRUB_DISABLE_LINUX_RECOVERY=true" at the top, and changed two lines at the bottom to be three that read as follows:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
list=`version_find_latest $list`
done

I saved and closed that and typed "sudo update-grub."  I typed "sudo vmware" and made some root adjustments there.  I rebooted and everything looked good.  There were a few rough spots, but I could see that this might not take very long at all, once you got the hang of it.

Ubuntu 10.04: UDEVADM Trigger Is Not Permitted While UDEV Is Unconfigured

In the process of installing Ubuntu 10.04, I got an error message:  "udevadm trigger is not permitted while udev is unconfigured."  Trying to reboot into Windows XP on that dual-boot computer led to the same error message.  This post describes my efforts to resolve that error.

As I looked into it, I found some indications that this was due to a bug in Ubuntu.  In my case, the immediate trigger seemed to be the decision to use an "installed-software" package (as described in the main installation post) to restore many of my previously installed programs at once.  Alternately, it may have been due to the concomitant effort to set up a separate home partition.

At least one user fixed this problem by using a different kernel.  I didn't seem to have any other kernels on my machine at this point, so I started over and re-did the basic Ubuntu installation.  This time, I installed everything to the root partition.  I rebooted, copied over my backup of fstab, changed it to reflect the new root partition's UUID, and rebooted.  Having discovered that I had made some mistakes in the separate home partition process, I tried that once more, and now that worked too.  I rebooted and ran installed-software (above).  This time, I declined to erase previously downloaded .deb files.  I rebooted again.  Unfortunately, I now had that udevadm message again.  Examining it more closely, I saw that, after a minute or two, it went on to say this:

ALERT!  /dev/disk/by-uuid/xxxxxxxxxxx does not exist. Dropping to a shell!

where "xxxxxxxxxxx" stands for a UUID.  Which UUID?  I could not figure out how to do things in the shell that opened up, so I rebooted with the Ubuntu Live CD.

According to fstab, the UUID belonged to my Ubuntu programs partition.  I typed "sudo blkid" and compared its output.  Fstab was correct:  it was identifying the UUID for that partition.  So when Ubuntu would try to boot, it would not find itself.  How was that possible?  This seemed to be a GRUB problem.  Following advice, I opened /etc/default/Grub and uncommented (i.e., removed the leading # sign from) the line that read "GRUB_DISABLE_LINUX_UUID=true."

I was then supposed to run update-grub, but I didn't know how to do that from a Live CD boot.  One post said that it was possible; I needed to do so "from inside a chroot environment."  Wikipedia seemed to say that chroot means "change root"; the idea was that I would use chroot so that, when I was running a program (e.g., update-grub) as root, the "root user" doing so would be that of the hard drive, not of the CD.  A Community Documentation page told me that it was "a special directory on your computer which prevents applications, if run from inside that directory, from accessing files outside that directory . . . like installing another operating system inside your existing operating system."  In other words, I needed to use chroot and then run update-grub as the root of my Ubuntu installation.  Unfortunately, the procedure described in that Community Documentation page required me to begin by installing dchroot and debootstrap, and I wasn't able to do that.

Something made me think that Super Grub Disk, which I had forgotten about, could provide a solution.  Looking into that led me to Rescatux instead.  But then the Super Grub Disk wiki said that Auto Super Grub Disk (ASGD) was the easiest solution for a Windows user.  Working on another computer, I downloaded it.  I expected an ISO, but it was an executable (.exe) file, so I ran it.  It gave me a dialog that seemed to be wiling to install ASGD on a USB drive, so I plugged one in, designated ASGD (not SGD) and USB (not hard drive) as my options (I had to restart ASGD to get it to see the drive), and clicked OK.  After a minute, it said "Installation Complete, Reboot."  So I plugged the USB drive into the troubled computer and did that, making sure to choose USB (actually, USB-HDD) as my first boot device in BIOS.  But it said, "BOOTMGR is missing."

So now I did try Rescatux.  I downloaded it, burned it to a CD, and booted it.  Its wizard came up, and I killed it.  But then it turned out that the wizard was the main thing, though the program did have a nice interface reminiscent of BartPE, with an applications menu and so forth.  Unfortunately, I couldn't figure out how to get the wizard back, so I had to restart it.  (The instructions on the SGD wiki were incorrect, and it was apparently not possible to edit pages or become a new user of the wiki.)  This time, from the Rescatux wizard, I chose GRUB options > grub-install > run.  It auto-selected my Ubuntu partition.  But then it said, "Which hard disk to install Linux on?"  I didn't want it to install Linux anywhere.  It made me nervous.  Anyway, I didn't want it to install GRUB either; I feared that would just wipe out the Windows part of my GRUB menu and give me a new problem to fix.

I tried again, this time with Super GRUB2 Disk.  The SGD wiki advised me to enter certain commands from the prompt, but did not say how to get to a prompt.  I tried the SGD option for "Detect any GRUB2 configuration file (grub.cfg)."  It found only one and seemed to be offering to load it.  I went with that.  It ran the GRUB menu OK and that took me to the udevadm error message.  Great.  I rebooted the SGD and tried the "Enable serial terminal" option.  But that just brought me back to the menu.  Tried it again; same result.

Back to the drawing board.  I found a different Ubuntu wiki page on how to recover GRUB2 via Live CD.  This seemed more on target.  It called for booting the Ubuntu Live CD, opening Terminal, and typing "sudo blkid" to get the device where Ubuntu was installed.  In my case, it was /dev/sdb8.  So then I typed "sudo mount /dev/sdb8 /mnt."  I didn't have /boot or /var on separate partitions, so I could just go directly to these commands:

sudo mount --bind /dev /mnt/devsudo mount --bind /proc /mnt/procsudo mount --bind /sys /mnt/syssudo chroot /mntupdate-grubexitsudo umount /mnt/devsudo umount /mnt/syssudo umount /mnt/procsudo umount /mnt

Then I rebooted.  Went through the GRUB menu; still got the UDEVADM message.  Back at the starting point, I tried searching again for answers to that error message.  Following an approach that seemed to work for some people, I started by booting the system and getting to my GRUB menu.  I hit the down-arrow key to stop the clock so that I could copy down the number of the Linux kernel I was trying to install.  In my case, it was 2.6.32-24-generic-pae.  (Alternately, I could have just typed "ls /boot" as one of the following commands.)  Having already found that Ubuntu was installed on /dev/sdb8, I rebooted with the Live CD, opened Terminal, and typed this:

sudo mkdir /media/newrootsudo mount /dev/sdb8 /media/newrootsudo chroot /media/newrootapt-get updateapt-get dist-upgrade

I rebooted and sat back to watch.  No joy.  Still got UDEVADM.  I rebooted the live CD and tried a modification of those commands:  redid the first three, down through the chroot step, but then typed "sudo update-initramfs -u -k 2.6.32-24-generic-pae."  This brought several error messages:  "Unable to resolve host ubuntu" and "No such file or directory" (in connection with an automatically generated "grep:  /proc/modules" command).  I rebooted, wishing these error messages wouldn't matter -- and, woo hoo! what do you know, they didn't!  I was booting into Ubuntu.  It ran a check on my disks, and that was the end of the story!

Ubuntu 10.04 Reinstallation: Another Go

I had previously installed Ubuntu 10.04 once or twice.  This post provides a synthesis of the process, done on a Windows XP dual-boot machine.

Things to Save

The first thing to think about was, What did I want to save from my previous installation?  I was already keeping my data in an NTFS partition that WinXP recognized as D:.  I had named that partition DATA in both operating systems (OSs).  So I did not have most of my data on the root (commonly referred to with a simple slash, "/") partition containing my Ubuntu program installation.  The main exception was what Ubuntu knows as the /home partition.  (This and other Ubuntu folders, being included on a partition formatted in ext3 or ext4, were invisible to Windows.)  The /home partition was the default location for user data files.  My own files -- documents, PDFs, etc. -- were no longer there, but Ubuntu would still save various settings and other things there.  So I decided to try create a new /home partition, and copy the old /home folder's contents to the new /home partition, before reinstalling Ubuntu.  That little effort became the subject of a separate post.

Just in case, I saved my open tabs in Firefox (Ubuntu) using an extension whose name was not visible to me at this writing -- called (I believe) CopyAllURLs.  I also used the FEBE addon to save my complete Firefox setup; and since FEBE had failed in the past, I used the InfoLister addon to save at least the list of addons that I had currently installed.  I had previously saved their settings separately, for those addons (e.g., Tab Mix Plus, Forecastfox) that allowed me to do so.  I saved all of these things to my data drive, not to the Ubuntu programs drive that I was about to wipe out.  All of these steps proved to be unnecessary:  the separate /home partition (below) saved my entire Firefox setup just as I had left it.

I started up Chrome and Opera, both of which I had installed on this machine, and saved a list of their open URLs.  This, too, was unnecessary, thanks to the separate /home partition.  I had already migrated my email and contacts from Thunderbird (Ubuntu) to the Windows portable version of Thunderbird.

There was another thing to save, but I forgot until too late.  I should have run the installed-software command to make a current list of the programs I had installed on Ubuntu.  Instead, I was going to have to use the older list that I had saved some months earlier, and any programs installed since then would have to be rediscovered and reinstalled one at a time.

I should also have saved /etc/fstab.  My set of hard drive partitions had mostly not changed.  I could have just edited that instead of starting over from scratch (below).

That was pretty much all that I needed to save from the old Ubuntu programs partition that I was about to wipe out.  Most of my work was done in Windows virtual machines running on VMware Workstation, and those were on a separate partition already.  So now it was time to begin the installation.

Installation from CD

This time, I installed Ubuntu 10.04 from scratch, using the CD.  Previous inquiries had suggested that the PAE-enabled kernel would be installed automatically when installing from the CD.  (PAE allowed 32-bit Ubuntu to access RAM well beyond the 4GB theoretical limit -- apparently up to 64GB.)  By right-clicking on individual items in the partition install screen during installation, I manually designated a 30GB root ("/") partition for programs.  The installer automatically detected my previously formatted 5GB swap partition.  It seemed that people were still having problems with ext4, so I formatted the root partition as ext3.  At reboot, GRUB did say that I was installing a PAE kernel, so that was good.

Installing Software

Now I ran the second half of the installed-software command (above) to restore the set of programs that I had installed on Ubuntu at various points.  This involved using Nautilus to put a copy of my installed-software list someplace accessible (I chose my Desktop), using "cd ~/Desktop" as the short way of getting to the desktop, and then typing the necessary commands:

sudo dpkg --set-selections < installed-software
sudo apt-get install dselect
sudo dselect

This gave me a menu, from which I chose option 3, "Install and upgrade wanted packages."  It did so.  It took about an hour.  During the process, it asked "Do you want to erase any previously downloaded .deb files?"  My search yielded no clear answer to this question.  I guessed, from a couple of things I saw in that search, that this was like the question that came up in some Windows installations (in Microsoft Office, perhaps), where you would have the option of keeping downloads on the hard drive to make future fixes or upgrades faster, at the expense of consuming additional disk space.  I tried the Yes option.  It paused for a minute and then put me back at the menu.  So I guess it deleted some .deb files.  Anyway, the installed packages included ntfs-config, so now I could run that ("sudo ntfs-config"), so that Ubuntu would recognize my NTFS (Windows) partitions and put appropriate entries in /etc/fstab.  So then /home would be recognized on reboot.

Unfortunately, something in the install-software process screwed up my system, leading to a "udevadm" error message and a whole separate post.  But then, when I rebooted, I had another problem.  I was looking at a nearly blank screen.  It just showed the name of Ubuntu across the top ("Ubuntu 10.04.1 LTS P4 tty1," where P4 was the name of my computer) and then gave me a simple login prompt:  "P4 login."  I wasn't sure what to search for, to solve this problem, so I booted with the alternative installation CD and chose the "Rescue a broken system" option.  Ultimately, it gave me two basic options:  either reinstall GRUB or execute a shell in my Ubuntu program partition (in my case, /dev/sdb8).  I had no idea what to type at the prompt, and I didn't seem to be having a GRUB problem, so I tried a search; but it turned up stuff dealing with monitor problems.  I tried another search and came across the idea that I could just type "startx" to open the graphical user interface (GUI), so I rebooted, entered my username and password at that prompt, and then typed startx.  But this gave me some error messages:  "Failed to open device," "No valid modes," and "Screen(s) found, but none have a usable configuration."

Basically, it seemed that the installed-software process had messed up my system.  So I started over, installing Ubuntu from scratch, and this time I didn't use the installed-software option.  I had to go back through the process of setting up my separate /home partition, and then I worked manually through the installed-software process.  That entailed setting up my repositories.  After that process, some programs were still not installed.  Drawing upon my previous installation and its follow-on comments (as well as notes in a few other posts), I used System > Administration > Synaptic Package Manager to install acroread, adobe-flashplugin, boinc, dvgrab, fdutils, gparted, mplayer, nautilus-open-terminal, ntfsprogs, p7zip-full, sysinfo, ubuntu-tweak, unetbootin, and webhttrack.  Then I installed several programs that I had downloaded separately, on the assumption they were not available via Synaptic.  These included VMware Workstation 7, which I installed, as I had learned to do, by typing "sh VMware-Workstation-Full-7.1.0-261024.i386.bundle" in the folder containing that downloaded bundle file.  The simple "sudo sh" prefix was also adequate for installing my separate .bin downloads (i.e., GoogleEarthLinux.bin).  I installed Beyond Compare, Opera, and Google Chrome by just double-clicking on the .deb downloads.

Settings and Adjustments

Creating the separate /home partition had preserved most of my Nautilus settings, but I still had to tweak a few of those manually.  It had not saved my monitor driver settings, so now I went into System > Administration > Hardware Drivers, searched for available drivers and, for my machine, found NVIDIA accelerated graphics driver (current version) > Activate. This, like other installation and activation steps, would work only when there was no other Synaptic or software installer running.  I rebooted to activate the hardware driver.  Unfortunately, I was still getting some bad ghosting.  Tightening my video cable connectors solved the problem.

Most of my newly installed programs did not require immediate configuration.  To configure BOINC, I went to Applications > System Tools > BOINC Manager > Next > Choose a Project > World Community Grid > Next, and then went into Advanced > Settings to adjust my preferences.

GRUB2 had lost the setting by which it would remember which operating system I had booted last, and would reboot that one instead of 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 added another line, right after it, that said "GRUB_SAVEDEFAULT=true"; I saved and closed that file; and then I typed "sudo update-grub."

Following a previous post, I pruned the list of entries shown in the GRUB2 menu at bootup.  First, I typed "sudo gedit /etc/grub.d/10_linux" and added a line, immediately after the comments section at the top, that said "GRUB_DISABLE_LINUX_RECOVERY=true" (without quotes, as always).  That would prevent me from seeing the "recovery" versions of Linux kernels in that menu.  At the end of that same file, I searched for the place that had these two lines:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
done

and changed it by inserting another list line between those two:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
list=`version_find_latest $list`
done

(Note that backticks ( ` ) are not the same as single quotes ( ' ) in such files.)  This, I hoped, would show me just the one or two most recent Linux kernels.  Finally, I saved and closed 10_linux and modified its companion file with this command:  "sudo chmod -x /etc/grub.d/20_memtest86+."  This command would hopefully prevent me from seeing the memtest options in the GRUB2 menu.  I rebooted and confirmed that it worked.

Other settings did remain intact via the preserved /home partition.  Unlike the steps described in the previous installation and in another tweak post, I did not have to make manual adjustments to prevent icons for mounted drives from appearing on the desktop.  My previous list of programs that should run at startup remained intact.  Gedit was still my default crontab editor.  The permissions giving me access to various partitions as ordinary user, not root, were still in place.  My VMware settings seemed to have been preserved, except for what may have been a few new root-level settings in the new version of VMware Workstation that I had just installed.

When these steps were complete, I ran Update Manager one last time, rebooted, and confirmed that everything looked good.  Then I rebooted with a CD and made an Acronis disk image on a separate partition.  Done!

Ubuntu 10.04: Creating a Separate Home Partition

I was reinstalling Ubuntu 10.04. In the previous installations, I had gone with the default approach. In particular, I had kept the /home folder in the root ("/") partition. That meant some extra work to save and/or recreate my user settings. This time around, I decided to create a separate /home partition to store those settings. This post describes that effort.

As I looked into this idea, I noticed that some guides to this process were a bit vague about key details, and other guides admitted that it could be complicated and it didn't work for everyone.  So I decided the safest bet was to start with the Ubuntu Community Documentation webpage.  For the partitioning, I rebooted with an Ubuntu Live CD and went into System > Administration > GParted.  To figure out how big to make the partition, I mounted the partition containing my Ubuntu installation and then went into Applications > Accessories > Disk Usage Analyzer and drilled down until I got to my /home partition, which was under /media.  Its name was a long string of random numbers and letters, something like 4bas83ng-gabbdd-adbg-fb37abd.  (It's a unique identifier, different for each computer and device.)  The /home partition for me, with almost all of my data elsewhere, was only about 120MB.  I decided on 1GB, to be on the safe side, and called it "home."  When GParted was done, I shut it down, exited the Live CD, and rebooted Ubuntu normally (i.e., without the Live CD).  Then I went into Applications > Accessories > Terminal, and typed "sudo blkid" to find the UUID for the new 1GB partition.  Following the Community Documentation, I then followed the advice to make a backup of fstab by typing these two lines:

sudo cp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)
cmp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)

(Note:  shell commands are case-sensitive, and punctuation is important.)  The second line was almost identical to the first, so I didn't actually retype it; I just hit the Up arrow key and then the Home key and edited the first few characters, and then hit Enter.  Now I was ready to edit fstab:  "sudo gedit /etc/fstab."  I added a line for the new home partition.

At about this time, I got distracted and strayed from the advice on the Community Documentation page at this point.  I ran into problems.  For reference purposes, the following section describes some error messages and other steps I took while trying to fix things.  After the following section, this post describes how I got back on track.

********************************************

DETOUR:  IF YOU HAVE FOLLOWED ME HERE, YOU ARE NOW LOST

********************************************

One of the first things that went wrong, aside from entering the wrong commands, was that I rebooted somewhere in the middle of the process, so Ubuntu read the fstab and assumed that my /home folder was on that new partition -- but I had not yet copied anything there, so the bootup froze.  So I had to reboot with the Live CD again, go into GParted, and delete that new home partition.  Then I rebooted without the CD, went back into GParted, recreated it, and did the copying step ("sudo rsync" etc., above).   Except that it didn't work.  I ran out of space.  Apparently I had not correctly calculated the necessary size of the new /home partition.  I went back into GParted and tried again.  This time I took the overkill approach:  30GB for /home.  (I had the extra space lying around, so why not?)  After a lot of fooling around with "sudo mkdir" this and "sudo umount" that, I did reach a point at which I had the right /dev/sd?? mounted at /media/home, and then the rsync command worked.  Then, as instructed, I renamed the old /home folder so that it wouldn't be detected as my /home folder:

cd /
sudo mv /home /old_home

I rebooted and sat back to see what would happen.  I got this on the initial Ubuntu reboot screen:

The disk drive for /home is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery 

This called for some additional screwing around.  I wrote down what happened; but when I returned to this post after an absence of a few days, I observed that Blogger had decided that what I wrote was garbage, and deleted it.  Thanks, Blogger!  I believe the gist of it was that I had forgotten that the new home partition would have, of course, a new UUID.  So I had to change fstab to account for that.  I also wound up running the rsync command (above) from a Live CD boot, after mounting the root and /home partitions, in this format:

sudo rsync -axS --exclude='/*/.gvfs' /media/UBUNTU/home/. /media/home/.

where UBUNTU was the label of my Ubuntu (root) program partition.  After rsync ran successfully, this new home partition contained about 4GB of files.  Booting with an Ubuntu Live CD, I ran GParted and resized /home to 10GB.  I had to do a reboot or two to get past the error messages and complete this repartitioning process, as often happened with GParted.  I then tried to install Ubuntu, designating separate root ("/") and /home partitions.  I told the installer to format the root partition but not the home partition, where I was saving settings from the previous installation.  But while I was installing from the CD, the installation program disappeared.  This happened three times with two separate installation CDs.  But when I told the installer to just put everything in root (i.e., not to recognize a separate /home partition), it went ahead, and the installation process was complete.

So now I apparently had to get Ubuntu to recognize my old /home partition in place of the new one that it had just installed.  I started Nautilus (i.e., Ubuntu's File Browser, from the Places > Computer menu pick), right-clicked on home, and saw that Mount was an option, implying that it was not yet mounted.  So that meant that, whatever I was doing with a /home folder right now, I would be doing to the newly installed one.  I went into Applications > Accessories > Terminal and typed the same commands as above:

cd /
sudo mv /home /old_home

That parked the new /home folder under the name /old_home, where it would still exist just in case, but would not operate.  Now I needed to tell Ubuntu to mount my saved /home partition at boot.  I typed "sudo blkid" and used the mouse (with right-clicks) to copy the UUID for home.  I typed "sudo gedit /etc/fstab" but this gave me never-ending error messages.  Oops.  Apparently gedit needed /home.  I killed that Terminal session, started a new one, reversed the mv command shown above (i.e., "sudo mv /old_home /home"), and tried gedit again.  This time it worked.  I noticed that fstab didn't list most of my drives, so I went to my main installation post and executed its steps related to ntfs-config.  I checked /home in Nautilus again and verified that the separate home partition was still not mounted.  Now I hoped that "sudo mv /home /old_home would put the newly installed home partition out of the way, and that my old one would operate.  But on reboot, I got several errors, one after another:

Could not update ICEauthority file /home/ray/.ICEauthority

There is a problem with the configuration server.
(/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256)

Nautilus could not create the following required folders:  /home/ray/Desktop, /home/ray/.nautilus

The last one made me think that my /home partition was not being recognized.  But following the advice in a thread where they seemed to be discussing all of these messages, I didn't pursue that; instead, I rebooted with the Ubuntu alternative installation CD and chose the "Rescue a broken system" option and chose to "Execute a shell in the installer environment."  But this didn't seem to be the best route to a command-line option, so I bailed out.

(Note:  I also ran into a "udevadm" error during this process.  It did not appear to be due to this home partition effort, but there is a possibility that it was.)

****************************

END OF DETOUR

**************************** 

Eventually, I reinstalled Ubuntu, made my way back to the Community Documentation page, and tried again.  My entry in fstab now looked like this:

UUID=xxxxxxxx /media/home ext3 nodev,nosuid  0  2

I had already created /media/home and had done the rsync part from my previous installation (above), so now I tried these commands:

cd /
sudo mv /home /old_home
sudo mkdir -p /home/ray

where "ray" was my username.  Then I went back to fstab and changed it again to this:

UUID=xxxxxxxx /home ext3 nodev,nosuid  0  2 

and rebooted.  This time, rebooting went fine:  no error messages, and my desktop was back in its configured condition, with panels and buttons where I had put them before reinstalling.  Very nice.

Ubuntu 10.04: Useless Mount Woes

I was using Ubuntu 10.04.  I had begun using Ubuntu in the belief that I would have a more logical computing experience than I had had in Windows, and in many ways that had been true.  But the whole realm of file permissions just baffled me, and once again it was causing me hassles and lost time.

This time, the problem had to do with what I might call "ghost mountpoints."  I had previously had my external USB drive (named DAILY) listed in fstab, for some purpose or other, but then it seemed that that had been causing a problem, so I removed it.  So now I had a new problem.  Apparently Ubuntu would just take it upon itself to create a nonexistent "mount point" in the /media folder, bearing the same name (i.e., DAILY); and if you unplugged and replugged the drive, it would not adopt the old one, but would instead create a new one, with an underscore appended to it.  So now I had /media/DAILY and /media/DAILY_ and /media/DAILY__ mountpoints, and when I tried to use scripts and such that would refer to plain old DAILY, they would not find it.

The problem, as it had now developed, was that I could not delete those old mountpoints.  They were all empty, but when I went to them in Nautilus -- to, say, /media/DAILY -- and right-clicked on it, the "Move to Trash" option was greyed out; and if I chose Unmount, it said this:

Unable to unmount DAILY
umount: /media/DAILY mount disagrees with the fstab

It said that because I had just now typed "sudo gedit /etc/fstab" and had revived the line that I had previously commented out, the one that provided for recognition of DAILY; and then I had typed "sudo mount -a" to mount the damned thing.  On the other hand, if I went to its sister, DAILY_, and tried the same steps, I got this:

Unable to unmount DAILY
umount: /media/DAILY_ is not in the fstab (and you are not root)

both of which were true.  But then if I typed "sudo nautilus" and went at it through the administrator's (root's) Nautilus, the Unmount option would do nothing, and the Move to Trash option would leave me with this:

Cannot move file to trash, do you want to delete immediately?
The file "DAILY_" cannot be moved to the trash.
Unable to trash file: Device or resource busy

But the Delete option would then give me this:

Error while deleting.
There was an error deleting DAILY_.
Error removing file: Device or resource busy

But what was it busy with?  There was nothing in it!  I did a search for that last error message and, sure enough, found a total of nine hits from the entire Google version of the Internet.  One source gave me the idea of trying "sudo umount -d /media/DAILY."  But I forgot the -d and that command just hung.  I killed that Terminal session and tried again, but it still hung.  I left that hang and tried the same thing with DAILY_.  That hung too.  Back at the drawing board, I tried the same thing but with -f instead of -d.  (This was what I had meant to do in the first place, but the smell of dinner had distracted me.)  Those hung too.

I found a tutorial on solving the problem on a jump drive, where you could just copy your files over to another drive and then delete directories etc.  I didn't want to have to do that with a 500GB external drive.  I tried rebooting the system without the external USB drive connected.  A disk check ran during reboot.  I also got a notice, during reboot, that DAILY was not connected; it noticed, now that I had it included in fstab.  When the system came back up, those DAILY, DAILY_, and DAILY__ entries were gone.  I wished there were a better way of getting rid of them -- it remained to be seen whether that problem would recur, now that DAILY was listed in fstab -- but at least a reboot and/or disk check had done it this time.

Ubuntu 10.04: "rsync: failed to set permissions on [folder]: Operation not permitted" -- and Beyond Compare

Using rsync to automate backups on Ubuntu 10.04 (Lucid Lynx), I got a million iterations of this message:  "rsync: failed to set permissions on [target drive & folder]: Operation not permitted."

I had previously had a somewhat similar problem with an external USB drive.  The solution there had been to reformat the drive.  I didn't want to have to do that again if it wasn't necessary.  I ran a search and, following what i understood from one post, I set out to change ownership on the target folder so as to match the ownership of the source folder.  To do that, I went into Ubuntu's Terminal and typed "sudo nautilus," and then navigated Nautilus to File System/media/[target drive].  (It could instead have been in File System/mnt/.)  I right-clicked on that and got Properties > Permissions.  The owner was root.  When I tried to change it, it changed back.

I exited Nautilus and followed instructions in Ubuntu Community Documentation, combined with advice from another post and the Ubuntu manual page for chown.  I typed "sudo chown -R ray /media/[target drive]."  That ran for five or ten minutes, as the chown (change ownership) command recursed (i.e., -R) all of the subdirectories on the target drive.  But that, by itself, did not fix the problem; indeed, it didn't seem to change anything.  Root was still the owner of the target drive.  Then again, the properties of the target allowed others to create and delete files as well, so why was rsync complaining?

There appeared to be another way.  In Terminal, I typed "sudo gedit /etc/fstab."  I already had a line for the target drive, which I'll call simply TARGET.  That line was as follows:

UUID=[UUID for the drive] /media/TARGET ntfs-3g defaults,umask=000 0 0

The Ubuntu documentation I was now looking at said, "Permissions are set at the time of mounting the partition with umask, dmask, and fmask and can not be changed with commands such as chown or chmod."  So possibly that's why my chown command wasn't doing anything.  Following the advice, I changed it to dmask=027,fmask=137, since this was going to be just a backup drive anyway.  I also saw that "defaults" meant these options:  rw,suid,dev,exec,auto,nouser,async.  All of those were fine, as far as I knew, except for this information from the documentation:

user - Permit any user to mount the filesystem. This automatically implies noexec, nosuid,nodev unless overridden.

nouser - Only permit root to mount the filesystem. This is also a default setting.

I wanted user, not nouser.  I decided it might be easier to spot this sort of thing, in future visits to fstab, if I just changed all occurrences of "defaults" to make these options explicit.  Besides, in light of the statements just quoted, it seemed that I would have to override several defaults anyway.  So the resulting fstab line looked like this:

UUID=[UUID for the drive] /media/TARGET ntfs-3g rw,suid,dev,exec,auto,user,async,dmask=027,fmask=137 0 0

I saved fstab and, in Terminal, typed "sudo mount -a" to mount the partitions according to these new instructions.  Then I ran the rsync command again.  Sadly, these changes made no visible difference.  I still got a million error messages.  So, OK.  I had been overlooking the first three error lines in the log output of my rsync command.  The second and third lines followed the pattern of this first line, but were for subdirectories:

rsync: failed to set times on /media/TARGET/.": Operation not permitted (1)

I hadn't previously investigated the "failed to set times" error, so now I did.  What I got out of the forums I came across was that possibly I had a syntax error in my rsync command.  Here's how it went:

rsync -qhlEtrip --progress --delete-after --ignore-errors --force --exclude=/.Trash-0 --exclude=/.Trash-1000/ --exclude=/lost+found/ /media/SOURCE /media/TARGET 2> /media/SOURCE/Backuplog.log

This was identical to the perfectly working rsync command that I was occasionally using to back up SOURCE to a different partition, with one exception:  in the one shown above, I didn't have a slash after Trash-0.  So I changed that to --exclude=/.Trash-0/ and re-ran it.  That didn't solve it.  I then noticed (I was using two desktops) that I had gotten a message telling me that the system was not able to mount the partition:  "Device or resource busy."  So possibly that fstab step still needed to be tested.  I rebooted the system.  None of the the parittions that I had adjusted in fstab were mounted.  I went back, deleted the dmask and fmask parts, and returned it to umask=000, and rebooted.  Now the partitions were all mounted.  I ran the rsync command again.  The problem had not changed.

I found an informative thread in which bscbrit suggested trying to use cp to copy a single file from the source partition to the target partition.  If it worked, s/he said, the problem was not with permissions; it was just with trying to use rsync.  So in SOURCE I copied a file, renamed it "x.txt," and typed "cp /media/SOURCE/x.txt /media/TARGET," and it worked:  there was a copy of x.txt on TARGET.  It sounded like there could be a kind of mismatch between the ext3 source drive and the ntfs target.  I also came across an informative post by djgrandmarquis that said rsync could have problems with Windows file systems.  That was in response to a question about very slow backup times, which  I had also experienced.  I needed Windows file systems because I was backing up to an offsite drive that I sometimes shared with a Windows system.

I had previously investigated Beyond Compare (BC) as another way of synchronizing drives.  BC had drawn  a lot of praise.  Since my previous writeup, I had bought a copy and had been using it for several months on Ubuntu, WinXP, and Linux.  I had subsequently found a comparison of many such programs; but since I had already bought BC and was using it with good results, I didn't explore that comparison.  I could verify that BC was fast and trouble-free when compared to rsync, especially when going between ext3 and ntfs drives.  I also liked the visible information about what was being changed and backed up.  So I decided to stop using rsync and start relying only on BC for my backups.

There were a few differences between the Windows and Linux versions of BC; but in an impressively thorough reply to my post, Craig from BC said that the portable version of BC ran well on Wine in Ubuntu.  I had already installed Wine, and I had also already been using the portable version of BC3; I preferred portable versions to save time during reinstallations, as I was able to save them elsewhere than drive C and therefore they weren't wiped out during a Windows reinstall.  So to try this out, I copied over the BC3 portable installation and tried using a funky procedure involving PortableApps to try the Windows version.  But now it seemed I had not properly understood or used that procedure:  PortableApps now appeared to be looking, not for .exe files, but for ".paf exe" files.  Meanwhile, it looked like Beyond Compare 3 would run fairly well under Wine, so I gave it a try.  Following the steps described in that previous post, in Terminal I navigated to the folder where I had the original BC installer, typed "ls" to get the exact filename, and typed "wine BCompare-3.1.10.11626.exe" to install that file.  Terminal reported some "fixme" and "err" messages; nonetheless, the Beyond Compare 3 Setup Wizard ran.  I had a licensed version, so I entered the license key, and followed the instruction to restart.  It worked, but now I came to the new realization that Windows identifies drives by letter (C: etc.), while Ubuntu identifies them by name (/media/DATA, etc.).  So of course a Windows version of Beyond Compare, looking for Windows-type folder paths, running in Ubuntu, is going to find only a limited number of Ubuntu locations.  I didn't pursue that problem.

This left at least one issue unresolved.  While I was OK with doing manual comparisons for now, I was still not at the point of being able to write scripts to automate BC backup processes.  I started another post on that.

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

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

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

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

SWAP: waiting for UUID=[UUID number]

Press ESC to enter a recovery shell.

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

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.

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.