ASUS Eee PC: Booting from USB: Second Cut: Ubuntu

I had previously done a lot of flailing around, in an effort to boot an ASUS Eee PC from a USB thumb drive (a/k/a USB stick, pen drive, jump drive, flash drive).  It was time to try again.  This time, there seemed to be some easier and more promising avenues of attack.  This post describes this renewed effort, with a particular focus on booting Ubuntu 11.10.

First, the basics.  In the BIOS Setup Utility, I had set my BIOS to boot first from the USB drive.  I got into the BIOS setup by hitting F2 repeatedly while the the Eee was booting.  I already knew that F2 or Del tended to be the keys to hit, on various computers, if I wanted to go into BIOS setup.  But if I hadn't known that, it would have been wise to get into BIOS somehow and change a certain setting, so that instructions and information would come up onscreen while the computer was booting.  The setting to change for that purpose would logically have been in BIOS Setup > Boot > Boot Settings Configuration > Quiet Boot > Disabled.  But that was greyed out and already set to Disabled on my machine, and yet I wasn't getting those boottime instructions.  The answer was to go, instead, into BIOS Setup > Boot > Boot Booster > Disabled.

With that done, I was all set to reboot the Eee and see, onscreen, the information that I should hit F2 to run Setup.  If it went by too quickly, I could hit Pause (note that, on the Eee, Pause was actually Shift-Pause).  For some reason, I had to hit it twice to make it pause.  Maybe I had bad timing.

I wanted to go into the BIOS Setup, for purposes of booting with the USB stick, in order to tell the computer to boot, first, from the USB stick.  If I didn't do that, it would default to booting from the CD drive (nonexistent, in my Eee) or from the hard drive.  The place to make this change, in BIOS Setup, was at Boot > Boot Device Priority.  The item that needed to be first on the list was "Removable Dev."

Now I was ready to boot my bootable Ubuntu USB stick.  Problem:  I didn't yet have one.  For this, I needed a 4GB USB drive (possibly smaller but not, I think, any larger) with Ubuntu installed on it.  To install Ubuntu on the USB drive, I went to the Ubuntu download webpage, downloaded the Ubuntu 11.10 ISO, and followed their instructions to install it onto the USB drive.  Their instructions were just to download and run the Universal USB Installer from Pendrivelinux.com.  That installer was, itself, a portable program -- no installation needed.  When that installer was running, I needed to select Ubuntu Desktop Edition and follow the instructions.

So I had done that, and therefore I had Ubuntu on my jump drive.  And the Eee was seeing the jump drive when I booted it -- I could see a brief flash of recognition, onscreen, before the stupid thing went ahead and booted into Windows as usual.  This was probably about what I had managed to achieve last time I had tried this.

But, as I say, there were new suggestions and possibilities.  One was that I should have put Eeebuntu rather than Ubuntu Desktop onto that USB drive.  The idea was that Eeebuntu was designed to make it as easy as possible to get Ubuntu working well on an Eee.

To be precise about it, some of the players had changed.  By this point, according to Wikipedia, Eeebuntu had become Aurora.  And, for that matter, Ubuntu Eee (apparently not the same as Eeebuntu) had become Easy Peasy, and Ubuntu Netbook Edition had been merged into Ubuntu Desktop.  A Wikipedia comparison table suggested that there were multiple kinds of netbook-oriented versions of Ubuntu:  some were designed for netbooks generally, some for ASUS Eee netbooks, some for specific kinds of ASUS Eee netbooks, and some for other portable devices (e.g., smartphones).  It made sense to get one designed for an Eee, so at the moment it seemed that an Aurora download (either the promised Gnome edition or one of the original Eeebuntu versions) might provide the road to the future, if I did need to try some other Ubuntu version on that USB drive.

I did not need to do that because, for me, the solution was simpler.  Before I got very far into this project at all, as advised, I tried hitting Esc when I booted, so as to bring up the boot menu.  That gave me an option to boot from the USB drive.  And it worked.  I didn't know whether this would address all of the needs and interests that had prompted me to try booting other programs (e.g., Hiren's, XBoot, Grub4DOS) in my previous try.  But for the moment, I was happy.

Windows 7: BOOTMGR Is Missing

One time, upon rebooting the system, I got this message:

BOOTMGR is missing
Press Ctrl+Alt+Del to restart

I rebooted from the Windows 7 DVD and went to the "Repair your computer" option.  It said "Searching for Windows installations."  Then it showed me the System Recovery Options dialog, listing "Windows 7 Ultimate (recovered)."

But that's not what it showed me the first time.  The first time, it showed me nothing.  I read somewhere that somebody found that they needed to run the Repair Your Computer option a couple of times before it would work, so possibly that was what finally populated this dialog with a Windows 7 entry.  But what I think may have solved the problem was that I booted with an Ubuntu 10.10 Live CD, went into System > Administration > GParted, and used their filesystem repair option (or whatever it was called, exactly) on my Windows 7 partition.  (I'm not sure if GParted is included in more recent versions. If not, the 10.04 version will still be available for a while.)

Anyway, I did now see Windows 7 Ultimate (recovered).  I clicked Next > Startup Repair.  It said "Searching for problems" and then "Attempting repairs."  Then it said, "Restart your computer to complete the repairs."  I did that.  The problem was solved.

Windows 7 Fails to Detect Other Computer on Network

I was becoming acquainted with Windows 7.  Sometimes, when I booted it up, it would immediately recognize the other computer (running Windows XP) on my home network, and would also recognize the (Linux-based) Synology Network Attached Storage (NAS) device I had connected.  At other times, unfortunately, the Win7 computer would only see itself.  This post describes steps I took to resolve that inconsistency.

I did a search on this problem.  I was inspired to undertake this investigation after I used System Restore to restore an earlier state of the computer.  Those other devices were now not visible in Windows Explorer.  They had been visible just a few minutes earlier.  To my knowledge, I had not done anything that would have made those devices more visible, or less so.

When I searched, I noticed a post in which someone said that Windows 7 was also losing track of drive mapping after it went into sleep mode.  I wondered if that was related.  The previous day, the computer had magically mapped drive D, a network drive on the Synology NAS, without any instruction from me to do so.  The poster said that he was experiencing both of these problems.  That particular thread concluded without an indication of a solution.  One poster said, "Ultimately this is just the nature of the way networking is sometimes."  But it seemed to me that it had never been that way between the XP machine and the NAS, or between the NAS and the Ubuntu setup that I had been using before I got Windows 7.

I wondered if it was somehow an XP problem.  The WinXP machine was currently in touch with the NAS.  Was it possibly barring the Win7 machine from seeing either itself or the NAS?  I rebooted the WinXP machine, but that didn't make a difference on the Win7 machine.

It wasn't a hardware problem, or even a networking problem per se.  Access to the Synology unit was through a web-based program.  On the Win7 computer, I could go into that Synology program and could communicate with the Synology NAS unit.  Synology could see the NAS unit, but Microsoft couldn't.  Apparently whatever was keeping Win7 from seeing the NAS was also keeping it from seeing the WinXP machine.  It was all or nothing:  either Win7 could see them both, or (as at present) it could see neither.

After going online in Internet Explorer and accessing the Synology NAS from the Win7 machine, I rebooted the Win7 machine.  That did not make a difference.  The Win7 machine was still unable to see the others.

In Control Panel > Network and Sharing Center > Troubleshoot problems, I tried the Incoming Connections option and said, "Find this computer on the network."  It came back with this advice:

Reconfigure your network

To prevent problems other computers or devices might have when connecting to your computer, no more than one device should perform network address translation (NAT).

I followed the link into Windows Help and Support, but that wasn't actually too helpful and supportive.  I clicked Next, and the Incoming Connections troubleshooter confirmed, "More than one device is performing network address translation (NAT)."  So, OK, which device?  I clicked "View detailed information" and went into Detection Details.  All I could find there that looked like it might be informative was a Network Diagnostics Log.  Following the links there in the Help dialogs, it seemed that, to open that up, I would have to use ThermaData Logger software.  This software seemed to be almost completely unknown through the vendor, ETI Software, that Win7 pointed me to, but I did find plenty of links for it elsewhere.  I had no idea why Microsoft required me to download a 29MB file from a slow connection just to read a log file.  While I was waiting on that, I found ThermoWorks -- the need for using thermal logging software was another mystery -- and was right on the verge of downloading their ThermaData Software Suite for Windows when I looked back at the Help dialog and decided to try instead downloading ThermaData Studio 1.0.5, which was apparently an entirely different deal.  That turned out to be a 12MB file.  While that was downloading, I went back to the dialog and clicked on the "Other Networking Configuration and Logs" link to open NetworkConfiguration.cab.  That led me to two text files:  ipconfig.all.txt and route.print.txt.  Neither contained any obvious references to NAT.  I installed ThermaData Studio.  Back in the dialog, I tried again on the link to the Network Diagnostics Log.  ThermaData Studio wasn't going to read it right there on the spot, so I downloaded the log and tried opening it from there.  But when I double-clicked on it, I got a message, "Windows can't open this file."  I went into the Start Menu and opened ThermaData Studio from there and tried to use it to view the file that I had downloaded.  At first, it didn't see anything -- it was looking for .msdb files -- but when I told it to look for .etl files, it found the download.  It gave me a completely empty file.  ThermaData Studio looked like solid software, but since I did not need it after all, I uninstalled it.

We were left with the question of which devices on my system were set to NAT.  Trying another approach, I disconnected the WinXP machine from the network and re-ran the Win7 Incoming Connections troubleshooter.  That didn't eliminate the NAT problem.  I reconnected the WinXP machine, disconnected the modem from the router, and ran the troubleshooter again.  Now the NAT problem was gone, though now there was a new problem, where the troubleshooter said it needed more information.  So, OK, possibly the modem plus at least one other device was doing NAT on my network.  I had seen a post indicating that modems and routers can both do NAT, so I plugged everything back where it belonged and looked at the pages on port forwarding and putting a router into bridge mode that that post linked to.  Following what the latter seemed to be saying, I looked at a sticker on the bottom of my modem.  (I didn't seem to have a manual for it, but could probably have downloaded one.)  It gave me an IP address to enter into my Internet browser; and when I went to the appropriate page, it asked me for a code that appeared on that sticker.  This led me into the configuration software for the modem.  After poking around for a minute, I found a page for the modem's PPP location.  This seemed to be what I wanted.  It gave me two options:

PPP is on the modem.  This is the normal mode for this modem.  The PPP session is initiated from the modem.

PPP is on the computer, gateway or router.  This should only be used if you need to run a PPPoE client on your PC or you use another device (e.g., gateway or router) to initiate a PPPoE session.  This is often referred to as "Bridged" mode.

Since option A wasn't working for me, and since the post seemed to be saying that I should use option B, I switched to that and saved the change.  This gave me a Location Warning.  It said,

When using Bridged mode, your access to the modem becomes limited.  To return to the DSL modem user interface after this change you need to directly connect your PC to the modem without any gateway or router between the modem and the PC, and configure your computer appropriately.

Configure the IP address of your computer to be on the same network as the modem by using an IP address of the form 198.168.1.x (except 192.168.1.254) and a network mask of 255.255.255.0.

You may also return to the DSL modem user interface by resetting the modem back to its initial defaults.  All configuration changes and other settings will no longer be available if this is done.  To reset the modem press the "Reset" button located on the back of the modem.

We still had a problem.  The modem was supposed to be restarting, but it wasn't working.  It had three green lights on, including the one for the ethernet (i.e., router).  But why wasn't its Internet light on?  I unplugged its power cord, waited a minute or so, and plugged it back in.  That didn't help.  I tried the same thing with its Internet (i.e., telephone) cord.  When it was unplugged, the modem's DSL light was flashing red.  So I seemed to have a mistaken understanding of the difference between its DSL and Internet lights.  Well, whatever.  It wasn't working, is the point.  I thought that possibly AT&T (my ISP) needed the modem to be in the other mode.  I thought about calling them to ask, but Christ, to enter again into that vale of tears:  no way.

Well, I would have liked to research the modem situation further, but there was just one problem:  I couldn't, as I now had no Internet connection.  I ripped off the sticker on the back of the modem that said, "Remove only if advised by tech support" and there, in all its glory, behold:  the Reset Hole.  I jammed a paper clip into it and watched in amazement as this achieved ... nothing.  It seemed the Reset Hole had gone stale.  It took a couple of tries, and possibly the discovery that this unit required a minimum of 30 seconds of pressure in the hole to achieve the desired reset.  Even so, I could get online only by cabling the computer directly to the modem.  The router seemed to be dysfunctional.  There was, inevitably, a call to AT&T after all, and it actually took only ten minutes

I went back to the modem's webpage, but was now getting "Unable to connect."  Taking plan B, I cabled the WinXP computer directly to the modem, as advised above.  But still, no joy.  No Internet light on the modem; Unable to connect in Firefox.  Now I had really done it.  I had gone and given myself no alternative but to call AT&T.  A half-hour later, we emerged with the discovery that I, in keeping with the spirit of the event, had lost my router password and unfortunately could not go online to figure out how to reset it, given that the reset button seemed to be having no effect no matter how thoroughly I massaged it.  Oh, and the modem was back in its original mode.  End of bridge mode strategy.

I ran a search on this reset problem.  It produced some possibilities.  One was that I needed to reset my TCP/IP preferences to match the router's IP address.  Another was that I just wasn't following the right steps to reset it.  Apparently it was too early to call it a brick; but even if it hadn't been, there seemed to be some kind of de-bricking option.  Or maybe I just needed to go through the full set of steps for setting up the network properly.  The part that I may have left out, in resetting the router, was that I did not disconnect all except the power cable before doing the reset.  So I did that now, and held the reset button down for an overly long time.  I replugged the cable between it and a computer.  In the computer's web browser, I went to 192.168.1.1.  This connected me to the router's webpage.  The password to get in, after resetting, was admin.  Now I set Wireless SSDI Broadcast to Disable.  The webpage said I needed to initiate the push-button setup at this point.  It seemed they were referring to the backlit Cisco Systems logo on the front of the unit; pressing it revealed that it was in fact a button, and this produced a message on the webpage:

Accepting clients!

You will be returned to the previous page after SES configuration completed.

It then did its thing for a couple of minutes, and then I was back at the webpage.  The manual seemed to indicate that WPA2 Personal would provide the best available security for my setup.  I enabled Wireless MAC filtering.  The manual said that the option to Filter Internet NAT Redirection "uses port forwarding to block access to local servers from local networked computers."  That sounded vaguely like what someone had said I needed to make my network work again, so I enabled it.  A search led to the advice that I should not enable these until I needed them.  I disabled Wireless Access Web, in this wired setting.  A few more settings, and then I was done -- and still unable to connect to the router.  The troubleshooter was going to be unable to give me much help, it seemed until I connected the router to the modem, so I did that.  That still wasn't working, so I used the router's webpage Administration > Diagnostic options to ping the local IP address of 192.168.1.1.  That worked, but was I just pinging the router itself?  I tried 192.168.1.100.  That worked too.  I thought maybe the Traceroute diagnostic would be more helpful.  It wasn't.

The manual gave some troubleshooting steps.  Following its guidance, I made sure the router's light was solid green.  The other instructions weren't applicable.  For a moment there, I gave up on life.  Then I ate a piece of chocolate and tried removing that NAT Redirection filter.  That wasn't the solution, but it gave me enough cockeyed optimism to try the Internet Connections troubleshooter.  It -- a veritable font of sharp-eyed discernment -- said this:

Your broadband modem is experiencing connectivity issues.

It said I had better power down the modem, wait 10 seconds until the lights were off, and then power it back up.  I decided to also plug its cable back in.  I was hoping that the troubleshooter would at least say, "Hey, we have found your modem -- so far, so good!" and I guess in a sense they did.  With everything duly de- and re-powered and cabled, I tried it again.  Now, by gum, we had a breakthrough:

Your computer appears to be correctly configured, but the device or resource (primary DNS server) is not responding.

What could this mean?  I had no idea.  I rolled the dice again on the Incoming Connections troubleshooter.  While that was running, I realized that a minor miracle had occurred.  Very quietly, while I was over there fixating on the Win7 computer, the computer on which I was writing this post had connected to the Internet -- through the cable, through the router, through the modem, through thick and thin!  And ... er, no, it hadn't.  Correction on that.

But at least there was a glimmer of hope.  By this point in the day, I had moved away from the Windows XP system, on the second computer:  I had rebooted with an Ubuntu live CD for maintenance purposes, and was therefore  writing this post in Firefox on that machine while it endured its maintenance throes.  And on that machine, for a minute there, I thought maybe it had made Contact.  But it had not.  I was in error.

Well, I had blown a good part of a day on a single troubleshooting problem.  This was, thankfully, a less frequent experience than it had been in years past.  I really and truly hated networking, and it probably showed, by this point, in my failure to grasp some obvious solution or to utilize some true-blue technique.  I really had no clue.  The problem wasn't with the modem or the Internet connection; I could save this post when I connected directly from the modem to this computer.  Possibly the problem wasn't between the Win7 computer and the router; the troubleshooter had felt that everything was in place there.

Trying something a little different, I got an ethernet switch off the shelf and connected both computers directly to the modem through that.  And, whoa, that changed everything instantly.  The Win7 computer popped up a dialog asking me to Set Network Location, and it was immediately connected to CNN.com, and the Ubuntu live CD spun up and updated this text shortly thereafter.  So.  It was the router.  I knew it all along.  What could this mean?  It could mean (a) the router was malfunctioning or (b) I did not have its settings right or (c) the real explanation, which I did not presently know.  Putting my money on (b), I reconnected the Win7 machine to the router, went to its webpage, and chose the Administration > Factory Defaults option.  When it was done wiping out all my hard work, it required the no-username, "admin" password entry.  I ran the Win7 Incoming Connections troubleshooter again.  It said it needed more info.  I tried it again with the modem connected to the router.  (CNN.com was not responding at that point.)  This came back with the message about how the modem was experiencing connectivity issues.

We seemed to have the beginnings of insight.  It appeared that I should have tried the ethernet switch and the factory defaults, right away, as alternatives to my custom configuration of the router.  Experiencing success with one or both of those alternative approaches would have clarified matters.

But that wouldn't be networking -- because, now that I had unplugged and replugged the switch a few times, it was no longer doing the job on either computer.  Everything was connected to it, as before, and the modem's lights looked right, but neither computer was able to connect.  With the switch still connected, I tried rebooting the Win7 computer.  It was no use.  The Win7 machine was still not able to see the world, and the Ubuntu computer was pretending to connect.  I powered down the switch and tried a direct connection from the modem to the Ubuntu computer.  Still crawling.  I powered down the modem for a minute.  That did it:  the Ubuntu machine was now going online without a sweat.  I tried the switch again.  That worked on both machines now.  So apparently the switch did get confused and need some time off.

The conclusion seemed to be that, if I needed a router, I needed to try a new one, and otherwise I should just use the switch and power it down for a while if it failed to work.

Both computers were now going online successfully.  What did the Win7 troubleshooters have to say about this?  The Internet Connection troubleshooter said that it "couldn't identify the problem."  This was apparently tactful speech:  it seemed to mean that it couldn't identify *a* problem, but didn't want to tell the user that s/he was imagining things.  The Incoming Connections troubleshooter said this:

Troubleshooting was unable to automatically fix all of the issues found.  You can find more details below.

Problems Found

Windows requires more information to diagnose the problem.

Here, too, there seemed to be a bit of a bullshit factor.  I had been taking these troubleshooters as though they meant exactly what they said -- that, in the latter case, there was a problem, though it was difficult to diagnose -- but now it began to seem that they might say this when there wasn't necessarily a problem.  Pointing me to an online source of the "more information" that the program needed was a funny gesture when, according to the troubleshooter itself, I might not be able to go online.  It seemed pretty lame, worthy of Windows 95.  After all, this was Microsoft's software reporting on Microsoft's software.

What remained, it seemed, was to choose between the switch and a new router.  That was a question for another post.

VMware Workstation 7.1 Unrecoverable Error

I was using VMware Workstation 7.1 on Ubuntu 10.04 with a Windows XP SP3 guest.  I had a WinXP virtual machine (VM) open, and suddenly it crashed, with this error message:

VMware Workstation unrecoverable error: (mks)
Unexpected signal: 11.
A log file is available in "/media/VMS/VMware VMs/WXMUProjectC/vmware.log". Please request support and include the contents of the log file.

To collect data to submit to VMware support, select Help > About and click "Collect Support Data". You can also run the "vm-support" script in the Workstation folder directly.
We will respond on the basis of your support entitlement.

I pursued that option, but it turned out I didn't have a support entitlement, so I turned to this process of researching the solution on my own.  I had gotten a similar error message once before.  I wasn't entirely sure what I had done to solve the problem in that case, other than to keep flailing around until something clicked.  But as I reviewed that previous post, I did recall a different error message that I had gotten when starting the VM.  I started it again and saw this in the lower right-hand corner:

Could not connect Ethernet0 to virtual network "/dev/vmnet8"
More information can be foun din the vmware.log file.
Virtual device Ethernet0 will start disconnected.

I tried a search for that error and came across some possible answers.  One was just to reboot, but I had already done that.  Another was to use the Virtual Network Editor.  I found a VMware video on that.  It told me that vmnet8 was associated with NAT, which was the kind of network connection I had selected in VM > Settings > Hardware tab > Network Adapter.  The video then started to talk about adding a network adapter.

It seemed that this could have two implications for me.  First, I had just put a network interface card (NIC) into the computer, as an alternative to the motherboard's onboard network connector.  I had done that in an attempt to deal with a networking problem that turned out to be just a bad cable.  I did think that, previously, I had been getting the second error message previously, the one just quoted, "Could not connect Ethernet0."  But I had not been getting the crashes previously.  So probably I could fix that error by just removing the unnecessary NIC, instead of trying to figure out how to configure it as described in the video.  Second, I had preserved my Ubuntu /home directory during this most recent installation of Ubuntu.  I had also recently installed a new motherboard.  Possibly the settings that I had saved in that /home directory were still dreaming of the old days, with the previous motherboard; perhaps I would have to configure the VM's ethernet adapter anyway, so as to make it comfortable with the new motherboard.

I started by shutting down the machine, removing that unnecessary NIC, and restarting.  (Before shutting down, I checked Ubuntu's System > Administration > Update Manager, just in case there were updates that would make my life easier in unknown ways.)  I powered up the VM.  No Ethernet0 error message.  OK, one problem solved.  Would it crash?  I worked with the VM for a couple of days, but then it did crash again.  It seemed that the frequency of the crashes was much reduced, so maybe removing the NIC helped.

This time, I took a look at the log file.  It was in the folder containing the other files for the VM, including the .vmdk file, and it was named simply "vmware.log."  It contained a large number of entries, going back days, including what looked like several hundred, at the end of the file, that all occurred within the last second before the crash.  The first one in that last second was "Caught signal 11 -- tid 3652."  There hadn't been any others for several minutes before that, and I also noticed that the "11" was the same number as appeared in the error message onscreen (quoted above).  This did seem to be the beginning of the end.  After that "Caught signal 11" message, there in the log file, I saw many repetitions of a few other types of messages, like these:

mks| SIGNAL: stack B6CE1AE0 : [etc.]
mks| Backtrace[0] [etc.]
mks| SymBacktrace[0] [etc.]
mks| Panic: dropping lock (was bug 49968)
mks| Unexpected signal: 11.
mks| Core dump limit is 0 KB.
mks| Child process 19031 failed to dump core (status 0x6).

mks| Backtrace[0] [etc.]
mks| SymBacktrace[0] [etc.]

where [etc.] refers to various sets of computer gibberish (e.g., 0xb7823410).  It went on from there, but now we seemed to be at the point of no return, where the log showed VMware giving me the "Unexpected signal" error message onscreen.  A search led to a thread in which people were saying that they avoided this error by tinkering with their screen resolution.  When I saw that, I figured that we were talking about a kind of general reaction to somewhat incompatible hardware:  could be the NIC, could be the screen resolution, etc.

I had noticed that this particular crash occurred when I used my KVM to switch from the computer in question to a different computer.  It was a new KVM, an IOGear GCS72U.  I had previously been using a PS/2 KVM without problems, but my new motherboard did not have two PS/2 sockets, so I had to switch to this USB KVM.  Had I installed the KVM before or after taking out the NIC?  I couldn't remember.  But the KVM was a suspect.

Another suspect was the keyboard.  I had also had to get a new keyboard and mouse -- because, of course, I was using PS/2 devices previously, and now I had to have USB devices.  It was an inexpensive keyboard, a Logitech K120, and I had noticed that it did not work consistently on the other computer.  It would be working fine, and then there would suddenly be no more keyboard input.  The mouse was still working, but not the keyboard.  At that point, it didn't matter whether the keyboard was connected to that other computer through the KVM or was plugged into it directly; either way, it wouldn't work.  But I hadn't done a scientific study to determine whether it was the keyboard or the USB KVM that was screwing up.

So, putting it together, what had happened in this case was that I was using VMware on computer no. 1 (C1).  The keyboard and mouse had been working fine on both C1 and C2.  I hit the KVM switch button to move to C2.  That's when VMware crashed; and at the same time, suddenly the keyboard was not working on C2.  But the USB mouse would still work.  So it seemed that either the keyboard or the KVM was sending a funky keyboard-related signal to C2.

C2 was an older system, and I was in the process of upgrading it, and I thought that might solve the problem.  But in the meantime, I plugged my old PS/2 keyboard into C2 and rebooted, with the new keyboard and KVM still connected to both computers.  In this setup, over a period of days, I observed that the PS/2 keyboard continued to work consistently throughout, but the USB keyboard would sometimes stop working on C2, like before.

Then I had another VMware crash on C1, and that made me decide to try another angle.  I unplugged the KVM from C2.  By this time, I had replaced C2; now it was pretty much the same computer as C1 (same kind of motherboard, CPU, and case).  So now the mouse and keyboard connected to the KVM would work only on C1.  On C2, I kept using the PS/2 keyboard, and added a USB mouse.  If there were still crashes or freezes, I would have a better idea of whether the problem was the new USB keyboard or the new USB KVM.  At this writeup, a couple of weeks later, my recollection was that I did not have any further crashes.

I decided to send the KVM back to IOGear.  In the interim, I connected my old PS/2 KVM to both computers, and used it only with the PS/2 keyboard.  So now I had a separate USB mouse for each computer, but only one keyboard for both of them.  It took a while to get used to switching mice when I switched the keyboard from one computer to the other, but the point here is that there were no further crashes.  I had to wait for the replacement KVM to arrive from IOGear before I could say for sure whether it was the keyboard or the KVM; but by that point I had decided to stop using VMware on Ubuntu,

Two Computers: Dividing the Workload

In this post, as part of my New Year's housecleaning, I introduce several investigations, involving various ways of setting up two computers in a workspace.

*  *  *  *  *

KVMs and Monitor-Sharing Options

I had developed the habit of working with two computers, using a KVM switch so I needed only one mouse and keyboard.  A KVM switch would let me use just one monitor with two computers:  it would be showing me what was happening on the computer that the mouse and keyboard were then connected to.

I had two monitors.  I didn't have them connected to the KVM.  Instead, I connected them directly to the two computers, one for each.  So the KVM switch would have me working on computer A or computer B, but monitor A would continue to show what was happening on computer A, and monitor B would continue to display the state of things on computer B.

Actually, one KVM had started malfunctioning, and I had replaced it with another.  In the process, I decided to disconnect the mouse from the KVM too.  So now the KVM just controlled the keyboard.  It made sense:  the keyboard was big.  I couldn't fit two keyboards on my desktop.  But I could fit two mice.  Mouse A, on the left side, was controlled by my left hand, and was controlling computer A, while mouse B was preoccupied with computer B on my right.  I wasn't sure if I liked this arrangement.  It had its advantages.  It gave my hands a more equal workout.  I could glance over at the other computer and click something, to make some process move ahead, without having to hit ScrollLock twice, which was how the KVM switched the keyboard back and forth.  The main problem was that it was hard to tell which computer the keyboard was controlling at any given time.  I was still occasionally hitting the Del key and deleting things on computer A and wondering why they weren't disappearing from monitor B.  It was a bit nutty.  But I was adapting and, like I say, it had its advantages, at least until I worked out something better.

The monitor situation was OK, too.  I had widescreen monitors, so I was able to accommodate a couple of different open windows at the same time on each of them.  But there were times when it would have been helpful to have both monitors attuned to just one computer.  I had previously used an arrangement where monitor A was dedicated to computer A, but monitor B was connected to a second KVM switch, so I could reach up and punch the button and switch monitor B back and forth between computer A and computer B.  This would let me use a multiple monitor approach on computer A, so as to spread out my work.  The problem with this was that, when there was no monitor turned on to computer B, I tended not to use it.  That was a problem because the purpose of having two computers was to let me continue to work when one of them would crash or need maintenance or get involved in some process, like scanning or rendering, that would make it virtually unavailable for other purposes.  I also used this arrangement to write these blog posts, tinkering with one machine and recording the steps in the other.  I found that, if I got too fixated on one computer, the other one tended not to be organized and capable enough to take over when I needed it.

There didn't seem to be a way to share one monitor between two computers simultaneously, with computer B running in a little window in the corner -- a real "monitor" as distinct from a big display.  There was the option of buying a little display, connecting it to the second DVI connector on computer B, and putting it off to the side, so I would always have that information about what was happening on computer B.  But that little monitor would cost more than $100.  I could probably go down to Goodwill and pick up an old CRT for less than $10, but the other problem was that it would still be more clutter, more heat, more power consumption.  And the desk didn't have room for it, so it would have to go onto a side table or shelf or something.  I would also need a video card, since my motherboard only supported one monitor.

A decision on that question of how to use multiple monitors would await the outcome of an investigation of various non-KVM strategies.

*  *  *  *  *

Dual-Booting and Virtual Machines

Over the past couple of years, my two computers had different missions.  Computer A was running Windows XP in a VMware virtual machine on Ubuntu.  Computer B was running WinXP natively.  Now I was moving away from Ubuntu and back to Windows.  I had planned to just install Windows 7 on both.  I'd been having problems with my WinXP installation on computer B, even when I restored from an image, so it seemed like a good time to upgrade rather than continue to fight it.

I liked the idea of dual-booting WinXP and Win7.  Actually, though, I rarely used my dual-boot setups.  I pretty much always went with one or the other.  Right now, for instance, I already had a dual-boot Ubuntu and WinXP setup on computer B, but I couldn't remember the last time I had gone into Ubuntu there.

Meanwhile, on computer A, it seemed like I should consider just replacing Ubuntu with Win7:  continue to run WinXP in a virtual machine (VM), that is, but run it on Windows 7 instead of Ubuntu.  This would give me access to the familiar way of doing things in WinXP, while easing the transition to Win7.  I looked into the VM option in more detail.  It looked like I would be able to use the Windows version of VMware Workstation as long as I wasn't using my Workstation license in Ubuntu.  So the tentative plan was to have WinXP running in VMware on Win7 on one machine, while just running Windows (either XP or 7) natively (i.e., without a VM) on the other.

Although I was moving away from Ubuntu, it occurred to me that this strategy would leave a door open for a possible return to Ubuntu.  Ubuntu had been far more stable than WinXP.  Assuming the virtualization setup worked, I could install Ubuntu as a VM on Win7, essentially reversing what I had tried to do previously, and I could thus continue to identify projects and programs that Ubuntu could handle just as well as Windows for my purposes.

*  *  *  *  *

Differences Between Machines

The decisions described above meant that, contrary to my assumptions, I probably should not set up identical hardware on both computers.  Computer A was probably going to need more muscle to handle the VMs.  WinXP on computer B had been struggling to run video editing software, though that may have been due to a flawed installation.

Part of the tradeoff here was simplicity versus options.  The more operating systems and hardware arrangements I had in play, the more different ways I had of configuring things, and the more time it would take.  I had always viewed the computer hobbying as a means to an end of being more productive, while having its own intrinsic interest too, and for that reason I had tended to think, in recent years, in terms of getting myself set up for the next six months or a year.  During that kind of timeframe, the problems of a setup would tend to emerge and sometimes become overwhelming.  The current Windows XP installation was a case in point.  I had been able to nurse it along despite its obvious dysfunctionality, occasionally replacing its current state with an Acronis image backup, but it was now crashing one or more times per day.  So, oddly, in this case it was the simpler installation that had become the more problematic.

The switch from Windows XP to Windows 7 probably meant that I would be spending quite a bit of time getting up to speed on the best way to configure the latter.  I was probably going to install it in a RAID array, for purposes of performance, with an external backup option.  There would be some things to figure out and play with.  Most likely, some hardware would be getting shuffled around.  So, contrary to my first thoughts during this particular housecleaning, it did not appear likely that the two computers would take on any clear definition:  they would not be mirror images of one another, in hardware terms, so as to simplify maintenance, and they would also not feature one being considerably more powerful than the other.  The plan for the coming six months to a year was just to make them both capable and to explore options without investing more time than I wanted to spare for this kind of project.

Since I was now in a period of computer housecleaning, it seemed likely that my posts over the next few weeks would explore these considerations in more detail.

Farewell, Ubuntu

I first started looking into Linux in the 1990s.  I have been playing, and then subsequently relying on, Ubuntu since I started this blog in 2007.  And now I may be going away from Ubuntu, and Linux, for a while.

My situation is that, throughout this time, I have had work to do.  There were always applications or capabilities that I was using in Windows that I could not yet match in Ubuntu.  As a transitional step, I bought VMware Workstation and ran that on Ubuntu, so that I could use those Windows applications in Windows XP virtual machines while continuing to become more familiar with Ubuntu.  And this worked.  I did become fairly comfortable with Ubuntu.  I have spent what must have been hundreds of hours researching, tinkering, and troubleshooting, as shown in many posts in this blog.  The performance was never as good as on the Windows machine.  But it was a good arrangement nonetheless.

During the past year or so, unfortunately, VMware or the underlying Ubuntu installation grew flaky.  I reinstalled both a couple of times.  It just wasn't working.  The VM was working so slowly, even with faster hardware and a fair amount of attention to performance tweaks.  I still don't know why.  If I knew, I would fix it, because one odd thing I noticed was that Windows XP running in a VMware Workstation virtual machine was vastly more stable than Windows XP running in native mode.

Right now, there are too many things that I still can't do in Linux.  The promise has been a long time in coming, and it's still not here.  I will probably keep a dual-boot on at least one computer, and I may find that I need it sometimes, for some purposes.  I got to the point where installing and tweaking Ubuntu was a lot faster and easier than doing so in Windows.  I like Ubuntu.  But at the end of the day, I need my software to work.  So, for now, I am going back to Windows.

Ubuntu 10.10: Error: Could Not Update ICEauthority File

When I was booting a new Ubuntu 10.10 installation, I got an error message, "Could not update ICEauthority file /home/ray/.ICEauthority." I clicked through that, checked Update Manager, and rebooted. The ICEauthority error message was there again.

Seeking answers to this problem, I ran a search and tried the suggestion to type Ctrl-Alt-F1 to get a text console. There, I hit Enter to get a login prompt. I logged in with my username and password, and this gave me a regular command prompt. I typed "sudo chown -R ray:ray .ICEauthority," where ray was my username. Then I typed "sudo /etc/init.d/gdm restart" to go back into the Gnome GUI. But the ICEauthority error message was still there. (From another post, it appears I could have just entered the chown command in Terminal, without Ctrl-Alt-F1.) People for whom this approach worked seemed to think that the problem was caused by opening a graphical (i.e., not purely text-based) program owned by root using sudo instead of gksudo. If that was relevant, it evidently meant I should have edited fstab by typing "gksudo gedit /etc/fstab." But was gedit a graphical program? Probably the better explanation was that my problem was caused by something else, and that this is why their solution didn't work for me.

Comments in another thread suggested that the problem might have been caused by an update, and also that the chown command (above) wouldn't work on an encrypted home partition. In a variation, I tried this:

sudo -i
chown ray:ray /home/ray/.ICEauthority
chmod 644 /home/ray/.ICEauthority\
exit

But this didn't do it either; the error was back when I rebooted. Somebody else said the problem had to do with changing passwords, and that was possibly relevant for me, so I went into System > Administration > Users and Groups and changed my user password, and also checked the box that said, "Don't ask for password on login."  But Ubuntu hung when I clicked OK; the circle icon (like the Windows hourglass, meaning "I'm working on it") stayed there for a couple of hours.  When I came back to the machine, I killed the dialog box and tried changing the password again, but it hung again.  I ran a search on that subproblem and tried the advice to kill that GUI approach and just type "sudo passwd [username]" in Terminal (my username was ray).  That worked.  So, back to the ICEauthority problem.  I rebooted, but no, the password fix was not the solution; the error message was still there.

Another suggestion was to make sure that the entire home directory belonged to the user (me).  That sounded like it might be on the money.  My impression was that moving around and copying this old /home partition could easily have screwed up the permissions.  So now, how to make sure I owned the whole /home directory?  In Nautilus (i.e., Places > Computer), I right-clicked on Home Folder > Properties > Permissions.  It said root (i.e., not ray) was the owner.  In Terminal, I typed "sudo nautilus" and, using the Tree (i.e., not Places) view (top of left panel), went to File System > home > ray > right-click Properties > Permissions and changed the permissions to me with full access.  I clicked on the "Apply Permissions to Enclosed Files" button, closed out of there, and rebooted.  Eureka!  That was the solution.  Done!

Ubuntu 10.10: Streamlined RAID 0 Installation

I had previously installed Ubuntu 10.04 on a two-drive RAID 0 array.  I did that to make a Windows XP guest virtual machine (VM) run faster in VMware Workstation 7.1.  I had then run into some problems with that installation, and had abandoned it.  Now it was time to try again, but this time with Ubuntu 10.10.  This post describes the process in more streamlined terms, drawing from the previous post in which I logged the details of that earlier attempt.

This time, as before, I had two hard drives for the RAID 0 array, plus a third drive on which I had already installed Windows XP.  The two empty hard drives for RAID were each 320GB.  That third drive also held my /home partition (i.e., the contents of the /home partition from a previous Ubuntu installation), which contained many of my settings and adjustments for various Ubuntu programs.  In other words, my Ubuntu installation would not be like a Windows XP installation, where it would be necessary to reinstall all of my applications (except the portable ones) after reinstalling the operating system.  The third drive also held my Linux swap space, which I probably could have put into the array instead, along with a partition I called LOCAL, which would hold backup copies of the VMware virtual machines.  I was going to put the active VMs into the RAID 0 setup to make them run faster, but of course RAID 0 was riskier in the sense that failure of either of the two hard drives would mean the loss of everything in the RAID 0 array.

I started by downloading and burning the Ubuntu 10.10 alternate (or "alternative") CD.  I booted that CD and chose the "Check disc for defects" option.  This took five or ten minutes, and then it said, "Integrity test successful," and then rebooted.  So then I went through the "Install Ubuntu" option and took the basic steps (selecting my country, my keyboard type, etc.).  The meat of the RAID 0 process began about three minutes into that video by amzertech (speaking, here, of its Part 1, not Part 2), where it was time to partition the drives.  I went to Manual (i.e., not Guided), and this put me into the main "Partition disks" screen, the one beginning with "This is an overview."  I went down to the first of the two hard drives.  It referred to them as SCSI partitions, but it also recognized them as being sdb and sdc.  So it looked like I had correctly cabled that third drive to actually be the first in the system (i.e., sda, a/k/a SCSI3 according to the partitioner), so as to make Windows happy.

The general concept of the RAID setup process was that, first, you designate some free space on each drive as a physical volume for RAID, and then you combine those physical volumes from the two (or more) drives into a single software RAID device.  The following paragraphs provide the details.

First, following the video, I went down to the first of the empty 320GB drives that I was going to use for my RAID array.  In my case, unlike the video, there was not yet any "pri/log" line showing "FREE SPACE" that I could select, under the drive identification line on the screen, so I just highlighted the drive itself and hit Enter.  This gave me the option of creating a new empty partition table on the drive, and I went with that for each of the two drives.  Then I highlighted the pri/log line under the first 320GB drive, showing free space.  There, I hit Enter and chose "Create a new partition."  For its size, I typed "50GB" and made it a primary partition at the end of the drive.  I guessed that this meant the outside of of the physical disc, where I believed data transfers would be faster.  Instead of leaving "Use as" at the default ext4 setting, I highlighted and hit Enter and went down to select "physical volume for RAID" (enter) > "Done setting up the partition."  I went through the same steps with the second 320GB drive, which was sdc on my system.  So now, back on the Partition disks" screen, each of the two drives showed an entry that looked like this:

#1   primary   50.0GB   K   raid

So this would give me a total of 100GB for my Ubuntu program installation, and I would still have several hundred GB left over as free space.  Now, on the main "overview" screen, I went up to the line that said "Configure software RAID" > "Write the changes to the storage devices" > "Create MD device" > RAID0.  This put me at a list of "active devices."  I wanted sdb1 and sdc1 (i.e., I didn't want to use one of the partitions I had previously created on sda, my third hard drive).  These were the only partitions on drives sdb and sdc, so the choice was easy.  For some reason, they showed up here as being 49999MB rather than 50GB.  I selected sdb1 and sdc1.  I highlighted each of those two, hit spacebar to select them, and then tabbed to Continue > Finish.  This put me back in the "overview" screen, where I saw that I now had these new lines, near the top:

RAID0 device #0 - 100.0 GB Software RAID device
   #1       100.0 GB
              131.1 kB         unusable

I highlighted the line that began with #1 and hit Enter > Use as > ext3 (apparently still more reliable than ext4) > Mount point > "/ - the root file system" > "Done setting up the partition."  This put me back in the "overview" screen, where the line now looked like this:

   #1       100.0 GB     f   ext4      /

I decided to go ahead with the video's approach of putting the swap space on the RAID0 partition.  To do this, I went through the same steps as above, starting with the free space line on each of the two drives.  The only differences were:

(a) I allocated only 5GB on each drive for this partition.
(b) This time, I selected sdb2 and sdc2 (instead of sdb1 and sdc1) as my active devices for the array.
(c) Under "Use as," I chose "swap area" instead of ext3.

The result, back in the "overview" screen, was that I had these lines:

RAID0 device #0 - 100.0 GB Linux Software RAID Array
   #1       100.0 GB    F   ext3      /
RAID0 device #1 - 10.0 GB Linux Software RAID Array
   #1         10.0 GB     f  swap     swap
              131.1 kB unusable

At this point, I wanted to vary from the video by adding one more partition, where I would put my VMs and possibly other things.  I went through the same process as with the first RAID device (above), and I used all of the remaining space on the two drives except for about 1GB.  The active devices in this case (when I got to that point in the process) were, of course, sdb3 and sdc3.  Back in the "overview" screen, I saw that I now had RAID0 device #2 of 528GB.  I would never need all of that space for my VMs, but I had no other use for the space, and this RAID setup process was a one-shot deal:  designate the space in some useful form now, or leave it forever unallocated.

So now, the final step.  I needed to create a /boot partition on just one drive.  That was why I needed to save 1GB.  I could have made one of those last active devices (either sdb3 or sdc3) larger than the other, but there was no point:  as I understood it, RAID0 would use only the amount of space that they both had in common.  So I would wind up with 1GB unused on one of the two drives.  Anyway, to create the /boot partition, I selected that remaining free space on sdb (i.e., the first of my two RAID drives) and used it all up on another ext3 partition.  This time, I chose ext3 without first choosing "physical volume for RAID"; and after choosing ext3, I didn't go right to "Done setting up the partition."  Instead, I stopped first at the "Mount point" option, where I chose the "/boot" option.  Back in the "overview" screen, I saw that I now had my three RAID0 devices at the top of the list, and the /boot device as sdb4 down under the first of my two 320GB drives.

In the "overview" screen, I saw that there was too much information; some had scrolled off the bottom of the screen.  I arrowed down until I got to the very bottom of all that, where I chose the "Finish partitioning and write changes to disk" > Yes option.  This started me right into the Ubuntu installation process, where I just entered basic information (e.g., my name).  The installation was very straightforward, and it worked:  Ubuntu booted up.  I then went to System > Administration > System Monitor > File Systems tab.  There, I saw /dev/md0 as root directory and /dev/sdb4 as /boot.  (The video said that the swap would not be visible here, and it wasn't.)  So my next step, at this point, was to refine the basic installation to suit my preferences.  The description of that process appears in a separate post.

Ubuntu 10.10: Tweaked Installation

I had previously installed Ubuntu 10.04, and had arrived at a fast way of adjusting the basic installation to my needs. This post updates and simplifies the separate post in which I described that process.  Here, I was using Ubuntu 10.10, not 10.04.

This post begins with a basic Ubuntu setup already installed.  That basic installation process was very straightforward; but for those unfamiliar with Ubuntu, there were many webpages on how to install Ubuntu 10.10.  The question addressed in this post was, what additional steps did I need to take, in order to make Ubuntu look and act the way I wanted?  Of course, people will have various preferences.  This post does not go into that kind of individual detail.  It is more a matter of how to go about choosing and preserving one's desired setup.

In this case, I had installed Ubuntu 10.10 in a two-drive RAID0 setup.  I have written a separate post on that as well.  It looked and acted the same as a normal single-drive Ubuntu installation.  But the following discussion contains a few references to the setup described in that other post, for those who have come to this description from there.

The Home Partition

If I had been installing Ubuntu without using RAID, I probably would have decided, in the initial installation, to install everything in a single root ("/") partition.  But the RAID process had required the creation of a separate /boot partition, so I now had those two partitions instead of one.  Either way, though, my installation did not yet include a separate /home partition.  I did want a separate /home partition to be part of the mix, because /home was where all kinds of program settings were preserved.

I had retained a copy of my previous /home partition.  It was on a third hard drive.  That is, it was not part of the RAID array, and I did not plan to copy it into the RAID array.  RAID 0 is risky, in the sense that failure of any drive in the array means the end of the entire array and everything on it.  So I was just going to leave the /home partition on that separate drive, and back it up from there.  The question was, how should I get the new installation to recognize that separate /home partition?  I had struggled with this step previously, but now I wanted to write it up in simpler form.

On that third drive, I had a folder called Saved Settings.  In that folder, I had kept a copy of my old fstab (that is, the file called "fstab," from the /etc folder, viewable by typing "sudo gedit /etc/fstab").  I added lines from that copy into my current fstab, making sure that its lines referred to UUIDs (available via "sudo blkid") rather than to drive letters (e.g., sda, sdb), so that the commands in the fstab would still function if I rearranged partitions in my computer.  I also made sure it had a line referring to the correct UUID for the /home partition.  I saved and closed fstab.

To give /home a place to be mounted, I typed "sudo mkdir /media/home."  To prevent the newly installed (and nearly empty) /home partition from interfering with the selection and use of my preferred, preexisting /home partition, I typed "sudo mv /home /old_home."  I had meanwhile allowed Update Manager to install updates, and that process was done, so at this point I rebooted.  I got an error message, "Could not update ICEauthority file /home/ray/.ICEauthority."  I clicked through that, and after a moment my old, preferred desktop layout was there and seemed to be functioning normally.  (I worked through the ICEauthority problem as described in a separate post.  Basically, the solution was to make sure the user (i.e., ray, not root) had ownership of the home folder.)  The last step was to delete the temporary old_home folder I had created by typing "sudo rm -r /old_home."

Repositories

Having the home folder in place meant that about 90% of the work of installing and configuring programs was already done and saved.  This was one huge advantage over Windows XP installations, where the only programs that did not have to be reinstalled in the event of a new operating system installation were portable applications.  This section describes the relatively few steps that I did have to take to install applications and configure my Ubuntu system, as compared to the writeup in a separate post on Windows XP reinstallation.

I could not rely on my previously saved sources.list file to set up my repositories, since I was now dealing with a new version of Ubuntu.  Instead, I went into System > Administration and discovered that, unlike Ubuntu 10.04 (as discussed in a separate post), Ubuntu 10.10 no longer had a Software Sources option.  A search revealed that this change was made to make Ubuntu more user-friendly.  I could either edit the menu to add back the Software Sources option or use System > Administration > Synaptic Package Manager as an alternative.  Choosing the latter, I went into Synaptic's Settings > Repositories > Other Software and selected the non-source options.  In the Authentication tab, I saw a list of Trusted Software Providers, and the names on it were Ubuntu (archive, CD image, and extras), GetDeb, and Google.  I had no problem with any of these except maybe Ubuntu extras.  I wasn't sure if these had come from my previous installation or were pre-supplied with Ubuntu 10.10.  I could have hit "Restore Defaults" to find out, but then I would have had to figure out how to restore them.  I closed out of that and, back in Synaptic, clicked Reload.

In Terminal, I typed "sudo gedit /etc/apt/sources.list."  I saw that it contained a handful of repositories.  I wondered if there were others I should include, so I went to the Ubuntu Sources List Generator and got a list that was more concise and that also included a few third-party repos of interest (i.e., GetDeb, Google, Medibuntu, Wine, and X Updates).  I ran the commands in the "Getting the GPG Keys" list from the bottom of the page, one at a time.  In previous installations, I had saved such commands in a text file and had executed it, but that had made it easier to overlook error messages.  In this case, the Medibuntu command gave me "Unable to locate package medibuntu-keyring."  A search indicated that virtually nobody had gotten precisely that message.  Not a good sign.  A community documentation page gave me a different command to add Medibuntu:

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

... all on one line!  It also said that Medibuntu's repository is deactivated whenever you upgrade to a newer Ubuntu release, so this reinstallation would have to happen each time.  I copied and pasted that command and ran it.  It gave me an error message:

Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

to which the answer was yes, of course, Synaptic is still running.  I shut down Synaptic and tried again.  This time, it ran.  I took another look at the Authentication tab in Synaptic (see above), and now Medibuntu was on the list of trusted software providers.  So the answer to my question was, this was my customized list.

I went back to the process of running commands generated by the Ubuntu Sources List Generator.  They ran without further difficulty.  I typed "sudo gedit /etc/apt/sources.list" again, and replaced its contents with the lines generated by that Generator.  I took another look at Synaptic's Authentication tab, and this produced an error indicating that I had duplicate entries for Medibuntu and, I think, something else.  But when I tried to figure out what that was about, the error went away, and I didn't seem to be able to get it back.  Anyway, the Authentication tab did show that I now had the five third-party repos that had interested me (above), so all that remained was to go into System > Administration > Update Manager > Check and download the additional updates that it detected.

Installing Programs & Other Adjustments

In Terminal, I navigated to my Saved Settings folder (basically, cd "/folder name/" -- using quotes because "folder name" has a space in it) and verified that I had a copy of the installed-software file that I had created, in my previous installation, by typing "dpkg --get-selections > installed-software."  Now that I wanted to restore the programs listed in installed-software, I entered these commands:

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

That opened up dselect.  The dpkg command had provided the list of what I wanted to install, so all I had to do now, in dselect, was to arrow down and hit Enter at the Install option.  This gave me an option of installing a large quantity of stuff, and I said OK, do it.  That took an hour.  At the end, I declined to let it erase previously downloaded .deb files, when it asked.  The last time I used this installed-software approach, I got a bunch of errors after reboot, and had to work back through the process manually.  There were some errors this time, too (see below), but they did not appear to be related to the dselect process.

As before, I navigated to the folders containing other program downloads (with .deb, .gz, .bin, and .bundle extensions).  I typed "sudo sh [filename]" to install my .bin and .bundle downloads (e.g., GoogleEarthLinux.bin).  Double-clicking on the filename in Nautilus no longer installed my .deb downloads; instead, I had to right-click and choose "Open with GDebi Package Installer."  In the case of my Synology software, I typed "sudo sh install.sh."  I wasn't sure where to install it, so I told it to install in /home, just in case that would spare me from having to install it again.  But I should have said /home/ray.  When I was done with all installations, I went into Update Manager, and ran and reran it until I was all caught up.

GRUB2 menu edits were the same as before:  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 also needed to make some adjustments for VMware.  First, I typed "sudo vmware" and made some root adjustments there.  As before, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM; and at the end of that file I added a line that said this:

bios.bootDelay = "10000"

and that bought me ten seconds instead of one or two, when that vmware logo came up.  In a variation from Ubuntu 10.04, the restricted drivers for my monitor were now at System > Administration > Additional Drivers.

Bugs and Other Problems

There were some problems.  First, BOINC would not suspend itself when the system was in use, so I just suspended it, period.  Also, as discussed in a separate post, there were some Firefox errors.  The solution there was to completely uninstall and reinstall Firefox, though possibly it would have been sufficient just to uninstall firefox-gnome-support and delete my profile.

Another problem was that Ubuntu was not clearly recognizing all local and network partitions.  The problem of mapping the drive in my Synology NAS required another separate post.  In that case, it came down to a problem with the line used to mount the drive in fstab.  It had seemed like there were other drive recognition problems, but evidently they sorted themselves out, or perhaps I was just mistaken.  At this point, the drives seemed to be recognized in good form.

There was also the problem that GParted wouldn't run.  It wasn't just in my installation; it wasn't running when I booted from the live CD either.  I guessed that this was some kind of brand-new bug in Ubuntu 10.10 that would be fixed shortly.  When I started GParted from System > Administration, it would start up, but then it would disappear after just a few seconds.  When I typed "sudo gparted" or "gksu gparted," it did the same thing, but it gave me an error message:

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basicI_string::_S_create
aborting...

A search indicated that this was indeed a bug in Ubuntu.  It looked like a new release would be fixing the problem imminently.  Another problem:  Google Earth would not install.  I got this error message:

parser error : Document is empty
parser error: Start tag expected, '<' not found
Couldn't load 'setup.data/setup.xml'

The command I used was "sudo sh GoogleEarthLinux.bin."  The first response to it was "Verifying archive integrity... All good."  Just in case, I downloaded a replacement of GoogleEarthLinux.bin, but got the same result.  It looked like others had also had this problem.  It seemed to be another instance of Ubuntu 10.10 not yet having all the kinks worked out.  I started with a lengthy thread on the issue.  One post in that thread recommended a command-line alternative, which in full form went like this:

sudo apt-get install googleearth-package
sudo make-googleearth-package --force
sudo dpkg -i googleearth_5.2.1.1588+0.5.7-1_i386.deb

I tried that.  The make-googleearth-package command generated a lot of errors that included the sentence, "Can't extract name and version from library name."  I got that long package name shown in the last line (googleearth_5.2.1 etc.) from one of the last lines produced by the make-googleearth-package command:  it said this was the name of the package it was building.  (It also seemed to say that simply "googleearth" was the name of the package, but that didn't work.)  The third command (sudo dpkg etc.) seemed to run successfully.  There was also now a Google Earth icon in Applications > Internet > Google Earth.  I clicked on that, and it worked.

Another problem involved VMCI Sockets.  I have addressed that one in a separate post.  I ran out of time to continue this project at the time.  When I returned to it two months later, I had decided to stop trying to maintain a primarily Ubuntu machine, but instead to return to Windows 7 for the foreseeable future.

Synology DS109 NAS: Unable to Mount - Network Is Unreachable

I was running Ubuntu 10.04 (Lucid Lynx) on a computer to which I had connected a Synology DS109 network-attached storage (NAS) unit.  I had resolved a "no more connections can be made" error on a separate computer, also attached to the DS109, that was running Windows XP.  Now I had a new problem on the Linux machine.  This time, the WinXP machine was connecting to the Internet and to the Synology without a problem, but the Ubuntu computer (referred to here simply as the Ubuntuter) was not connecting to either.

The symptoms included the following:  in Firefox, I was getting "Firefox can't find the server" errors for most webpages; in Nautilus, I would get "Unable to mount" errors when I clicked on the name of a partition on the Synology; and in Synology's DiskStation Manager (DSM), its web-based access to the DS109, an attempt to log in to http://[IP address] (using the IP address from DSM > Control Panel > System Information) gave me a "Processing. Please wait ..." message.

I tried rebooting the Ubuntuter.  That achieved nothing.  Typing "sudo mount -a" gave me this:

mount error(101): Network is unreachable
Refer to the mount.cifs(8) manual page (e.g., man mount.cifs)

I typed "man mount.cifs."  From that, I gathered that I should type something like "sudo mount -ta cifs," though that precise command didn't work.  The "mount -a" command was supposed to mount everything in /etc/fstab, but apparently it could not mount the fstab items that had network locations.  I tried connecting the Ubuntuter directly to the modem, bypassing the router and the rest of the network (i.e., the Synology and the other computer).  This did nothing.  Apparently it was not just a Synology problem.  I rebooted with an Ubuntu live CD and tried Firefox that way.  It was not able to reach webpages either way (i.e., while connected to the router or directly to the modem).  It seemed I had a hardware problem.  I was using a new Gigabyte GA-MA785GM-US2H motherboard.  It looked like a few of its reviewers at Newegg cited intermittent problems in connecting.  The solution, it seemed, was to return the board or try adding a network interface card (NIC).  I tried the latter.

But while I was doing that, I noticed that the little plastic tab on the ethernet cable was gone.  It was possible for the plug to just slide out of the socket.  So I replaced the cable.  That worked on the next bootup.  So at this point the solution seemed to be either (a) if one reboot doens't work, try another, (b) the NIC connector is competitive and will get its act together if you install another card that might take its place, or (c) a better cable.  I gave it some time, to see which it would be.  After several days, I could say with confidence that the simple replacement of the cable made all the difference.

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.

Wiping a Hard Drive in Ubuntu

I had an old ATA (PATA) hard drive that I wanted to wipe and dump. I didn't know if there had ever been anything particularly sensitive on there, but anything is possible, and anyway I wanted to know how to do it in Ubuntu.  This post presents what I learned in that process.

After a preliminary search, I came across this advice:  "The first thing to do is to see if hpa is enabled."  "HPA," according to Thinkwiki, was short for "Hidden Protected Area" or "Host Protected Area."  It was "a special area (usually a few gigabytes in size)."  The recommended way to see if hpa was enabled was to type "sudo hdparm -N /dev/sdx."  I did that and got this:

625142448/4385456(625142448?), HPA setting seems invalid (buggy kernel device driver?)

A search for that error message led to just a dozen or so hits, containing various bits of information.  For instance, thorkelljarl noted that "The HDD utilities supplied by Seagate, Samsung and some other HDD makers can set the HDD capacity and should remove HPA totally."  NeCod suggested trying this:

grep -i HPA /var/log/kern.log

That produced two messages, each beginning with the date and time and then reading as follows:

ubuntu kernel: [    3.076473] ata5.01: HPA unlocked: 625140335 - > 625142448, native 625142448
ubuntu kernel: [    3.482031] ata1.00: HPA unlocked: 156299375 - > 156301488, native 156301488

I wasn't sure what those messages meant.  I thought the system in question might have been confused about the hpa on this drive because I had booted the system using a live Ubuntu CD.  WilliTo offered some advice pertaining to RAID, but the first two steps sounded more generically useful:

1- Disable backup bios to disk in gigabyte bios if enabled
2- Disable HPA with HDAT2 (disk must be in sata mode not raid)

Similarly, that Thinkwiki page said "If the HPA is enabled in the BIOS (mode set to "Normal"), Linux may get confused about the correct partition geometry."  I tried rebooting, hit Del to go into the BIOS settings > Advanced BIOS Features > Dual BIOS Recovery Source.  That didn't have an option to disable this; it just had HPA or Backup BIOS options.  A Launchpad page gave me the impression that this was particularly a Gigabyte motherboard problem:

Virtual BIOS solutions - like GigaByte motherboards use

This is absolutely CRITICAL. When the hd is unlocked and fully used new GigaByte boards tend to write 1.5 MB at the end of IDE or SATA drives in legacy mode as BIOS backup. Then HPA is activated, every OS has to respect this otherwise it will definitely overwrite data. That's usally not directly visable for the user, but it definitely happens. Depending of the filesystem used for the partition using that last mb will immediately kill data or it will take time till it is filled, but corruption is inevitable.

That Launchpad page said that HPA takes only 1.5MB.  But I preferred not to have it there, for purposes of this erasure.  I had seen another note, somewhere, indicating that the person in question was finding that the HPA was more like 8GB.

Going back to WilliTo's advice, I did a search for HDAT2.  According to its homepage, HDAT2 was a "program for test or diagnostics of ATA/ATAPI/SATA, SSD and SCSI/USB devices."  A desultory glance at a few reviews suggested that HDAT2 was an OK program.  My next question was whether I could add it to a BartPE bootable USB stick as one more boot utility, but it looked like UBCD4Win (the Ultimate Boot CD for Windows) and/or UBCD had beat me to it.  Rather than pursue that, however, I found that Darik's Boot And Nuke (DBAN) was a simple and highly recommended bootable eraser, so I went with that.