[The Path to Root - SysAdmin Blog (Beta)] VMware Server Virtual Lab, Part 1b:...

[treehead]

[http://www.treehead.net/root/log/]

It's been a while since I first attacked the challenge of setting up a virtual lab to study for my Microsoft certification upgrades. Now I am forced to return to it, because today I registered to take exam 70-292 in 2 weeks. No backing out now.

In "VMware Server Virtual Lab, Part 1: Obtaining the OS," I downloaded a trial copy of Windows Server 2003 R2 and in "VMware Server on Ubuntu Server 6.06.1 LTS," I had gone so far as to install VMWare on Ubuntu Server. Now, in "VMware Server Virtual Lab, Part 1b: Uninstalling VMWare on Ubuntu," I return to the project and attempt to marry the two by installing Windows Server 2003 R2 on VMware on Ubuntu Server. My first snag came when I set up the Windows Server Virtual Machine (VM) and got an error message when attempting to boot "x11-03905.iso." Of course, I should have taken a screenshot, but forgot in the heat of the moment. I am hoping (perhaps foolishly) that upgrading VMware will correct this problem (even though I don't see any applicable issues in the VMware server release notes). A new version, 1.0.3, is available and I'm going to install that. First, though, I am taking the opportunity to upgrade to the latest version of Ubuntu: 7.04 (AKA, "Feisty Fawn"). I will illustrate the steps here. Ubuntu.com has a handy guide to upgrading Ubuntu. First, we uninstall VMware...

root@edu:/var/vm# vmware-uninstall.pl
Uninstalling the tar installation of VMware Server.
...
The removal of VMware Server 1.0.1 build-29996 for Linux completed
successfully. Thank you for having tried this software.

So, now that we have VMware uninstalled, let's upgrade Ubuntu...

Upgrading Ubuntu 6.10 to Ubuntu 7.04

Now we upgrade Ubuntu from 6.10 (AKA "Dapper Drake") to 7.04 (AKA "Feisty Fawn"). The first thing to do is install the new update manager by installing "update-manager-core". First things first... we update our package list and then install the package, right?

root@edu:~# apt-get update
...
Fetched 489kB in 1s (251kB/s)
Reading package lists... Done

root@edu:~# apt-get install update-manager-core
Reading package lists... Done
Building dependency tree... Done
E: Couldn't find package update-manager-core

...but we've got a problem. apt doesn't know what update-manager-core is, because it's in the Feisty repository and we're pointed to the Dapper repositories. So we have to point apt to the Feisty repositories by editing our sources list:

vi /etc/apt/sources.list
...
:%s/dapper/feisty/g

...and save the changes:

:wq

That's it. Doesn't vi rock? Of course, if you're really smart, you'll just use sed:

sed -e `€™s/\edgy/ feisty/g` -i /etc/apt/sources.list

Now we can update against the Feisty repositories...

root@edu:~# apt-get update
...
Fetched 6342kB in 15s (399kB/s)
Reading package lists... Done 

...and install update-manager-core...

root@edu:~# apt-get install update-manager-core
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
apt apt-utils aptitude binutils cpp cpp-4.1 dbus dpkg evolution evolution-common evolution-data-server
...
91 upgraded, 47 newly installed, 21 to remove and 465 not upgraded.
Need to get 86.0MB of archives.
After unpacking 36.3MB of additional disk space will be used.
Do you want to continue [Y/n]?

...and of course, we do. This will take a while (relatively speaking) but once it is done, we can proceed with actually running the update-manager and upgrading to 7.04. Aside: During the update, I was prompted with a message about restarting affected services, which was just ssh in my case. I selected "Ok," the update continued and, as you can see, restarted ssh:

Restarting services possibly affected by the upgrade:
ssh: stopping...starting...done.

Services restarted successfully.

What's interesting is that I was ssh'ed into the system and my connection was never interrupted. I'm not sure if this is typical Linux behavior, but I would like to investigate. At any rate, I decide to log out and log back in, just in case. Now for the upgrade... Because I am doing this over ssh, and because upgrading is such a big deal (we don't want the process interrupted), I am going to run screen so that if I lose my ssh session, all I have to do is log back on and reattach my screen session. The upgrade will continue to run in the event that I lose my session. What you'll notice here is that I attempt to run screen and it is not installed:

root@edu:~# screen
bash: screen: command not found

So I will attempt to install it:

root@edu:~# apt-get install screen
Reading package lists... Done
Building dependency tree... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
gnome-menus: Breaks: gnome-panel (<= 2.16.2-0ubuntu3) but 2.14.3-0ubuntu1 is to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

..but I have unmet dependencies that need cleaning up, so I clear that up first

root@edu:~# apt-get -f install

Now I can install screen:

root@edu:~# apt-get install screen

When you start screen, you get a little welcome message, so I just hit enter and then proceed with the upgrade. Don't be weirded-out about the fact that you just get thrown back into your shell prompt. screen is actually running:

root@edu:~# ps aux | grep screen
root      8326  0.0  0.0   2776  1076 pts/0    S+   19:59   0:00 screen
root      8341  0.0  0.0   1772   668 pts/1    S+   20:05   0:00 grep screen

So on with the upgrade, right? Wrong. Of course, as will all learning experiences, you learn from your mistakes. It is at this point that I realize that the command "do-release-upgrade" is meant to invoke a GUI. This, of course, does not work if you are not running X Windows, so I must back-track and use an alternate method of upgrading. Further investigation turned up a helpful explanation of the two methods of upgrading Ubuntu, from which I chose the second, shell-based apt-get method. This makes more sense, as I was a bit confused by the "do-release-upgrade" command to begin with. If you have done a dist-upgrade in Debian before, this is virtually identical, as you'd expect:

root@edu:~# apt-get dist-upgrade
...
447 upgraded, 69 newly installed, 11 to remove and 8 not upgraded.
Need to get 219MB of archives.
After unpacking 199MB of additional disk space will be used.
Do you want to continue [Y/n]?

...and away we go! Now this really will take a while, so go get a cup of coffee and a copy of UNIX Power Tools and watch the beautiful scrolling stdout. During this time, I received several prompts for pre-existing files such as:

Configuration file `/etc/udev/rules.d/95-hal.rules'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** 95-hal.rules (Y/I/N/O/D/Z) [default=N] ? I

For each of these I chose install ("I"), because I have very little configuration information and I can tweak the install later if necessary. I am more interested in having everything behave like an "out-of-the-box" install than keeping any install-specific configuration. The write-ups that I'm looking at specify to execute the following two commands post install:

apt-get -f install

dpkg --configure -a

My question, of course, is: what are these commands and why am I running them? (Which I know is what you're asking too, right? Right). Here's the explanation: apt 0.6.46.4ubuntu10 for linux i386 compiled on Mar 14 2007 17:43:24 Usage: apt-get [options] command apt-get [options] install|remove pkg1 [pkg2 ...] apt-get [options] source pkg1 [pkg2 ...]

root@edu:~# apt-get --help
apt-get is a simple command line interface for downloading and
installing packages. The most frequently used commands are update
and install.

Commands:
   update - Retrieve new lists of packages
   upgrade - Perform an upgrade
   install - Install new packages (pkg is libc6 not libc6.deb)
   remove - Remove packages
   source - Download source archives
   build-dep - Configure build-dependencies for source packages
   dist-upgrade - Distribution upgrade, see apt-get(8)
   dselect-upgrade - Follow dselect selections
   clean - Erase downloaded archive files
   autoclean - Erase old downloaded archive files
   check - Verify that there are no broken dependencies

Options:
  -h  This help text.
  -q  Loggable output - no progress indicator
  -qq No output except for errors
  -d  Download only - do NOT install or unpack archives
  -s  No-act. Perform ordering simulation
  -y  Assume Yes to all queries and do not prompt
  -f  Attempt to continue if the integrity check fails
  -m  Attempt to continue if archives are unlocatable
  -u  Show a list of upgraded packages as well
  -b  Build the source package after fetching it
  -V  Show verbose version numbers
  -c=? Read this configuration file
  -o=? Set an arbitrary configuration option, eg -o dir::cache=/tmp
See the apt-get(8), sources.list(5) and apt.conf(5) manual
pages for more information and options.
                       This APT has Super Cow Powers.

So obviously we would be attempting to install all new packages (I'm assuming this is clean-up for those apt wasn't able to install, which is probably why we're specifying the "-f" option—to install the packages regardless of whether they pass integrity checks. Why you would want to do this is beyond me.

root@edu:~# man dpkg
      dpkg --configure package ... | -a | --pending
             Reconfigure  an  unpacked  package.  If  -a  or --pending is given instead of package, all unpacked but
             unconfigured packages are configured.

             Configuring consists of the following steps:

             1. Unpack the configuration files, and at the same time back up the old configuration  files,  so  that
             they can be restored if something goes wrong.

             2. Run postinst script, if provided by the package.

This makes a bit more sense: Run post installation scripts for all packages ("-a") for unpacked packages. Again, this appears to be clean-up. In both cases, there was nothing for either of these commands to do, which is a good indication the upgrade went smoothly. Some write-ups have you reboot at this point but, as all Linux geeks know, there is *rarely* a good reason to reboot. All we need to do is take the system to single user mode and back up to multi-user with telinit. First, let's check our current runlevel:

 root@edu:~# runlevel
N 2

...which tells us the previous runlevel ("N" stands for none. In otherwords, no other runlevel has been used but "2" since the last system boot), and our current run level (runlevel 2), respectively. Runlevel 2 is the default runlevel in Debian and Ubuntu, and is full multi-user mode. So now we switch to single user mode:

root@edu:~# telinit 1
root@edu:~# Connection to edu closed by remote host.
Connection to edu closed.

...which kicks us out of our ssh session. Obviously, you'd use the reboot command if you're doing this from a very remote location. For me, it just means a trip to the basement. All we do in single user mode is give the root password to logon and telinit to runlevel 2. Now we can log back in and reinstall VMware. First, let's verify what version of Ubuntu we're using:

root@edu:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 7.04
Release:        7.04
Codename:       feisty

Yep, we're good. Incidentally, if you're wondering what the lsb_release command is like I did, here's the scoop from the man page:

...
DESCRIPTION
       FSG lsb_release v2.0 prints certain LSB (Linux Standard Base) and Dis-
       tribution information.

       With no OPTION specified defaults to -v.
...
FILES
       If the installation is  LSB  compliant, the  "/etc/lsb-release"  file
       should  contain the LSB_VERSION field. The value of the field should
       be a colon separated list of supported module versions indicating  the
       LSB  specification  modules to which the installation is compliant. If
       the installation is not compliant,  the above  field  should  not  be
       present.
...

If you know the Linux Standard Base, then you might have intuited that like I did, but it's always good to get more information. Information is our friend. -v is your friend.

Installing VMware Server 1.0.3 on Ubuntu 7.04

Now that we have Ubuntu upgraded, it's just a matter of installing VMware server, and I can't come up with a better how-to than the one at HowToForge.com: "How To Install VMware Server On Ubuntu 7.04 (Feisty Fawn)." And there you have it. I think we can safely say that Part 1 of the VMware Virtual Lab is complete. Addendum: I just discovered via a comment on HowToForge that Ubuntu has a Commercial repository that contains VMware server, and although it is version 1.0.2-2, I think I will install it:

root@edu:~# aptitude show vmware-server
Package: vmware-server
New: yes
State: not installed
Version: 1.0.2-2
Priority: optional
Section: misc
Maintainer: VMware Build Team 
Uncompressed Size: 131M
Depends: netbase, netkit-inetd | inetd, update-inetd, vmware-server-kernel-modules, libart-2.0-2 (>= 2.3.16),
         libatk1.0-0 (>= 1.9.0), libc6 (>= 2.3.4-1), libexpat1 (>= 1.95.8), libfontconfig1 (>= 2.3.0), libfreetype6 (>=
         2.1.5-1), libgcc1 (>= 1:4.0.1), libglib2.0-0 (>= 2.8.0), libgtk2.0-0 (>= 2.8.0), libice6, libjpeg62,
         libpango1.0-0 (>= 1.10.1), libpng12-0 (>= 1.2.8rel), librsvg2-2 (>= 2.9.5), librsvg2-common (>= 2.9.5), libsm6,

         libssl0.9.7, libstdc++5 (>= 1:3.3.4-1), libx11-6, libxext6, libxft2 (> 2.1.1), libxi6, libxml2 (>= 2.6.20),
         libxrender1, libxt6, libxtst6, zlib1g (>= 1:1.2.1)
PreDepends: debconf (>= 0.5) | debconf-2.0
Conflicts: xinetd, vmware-player, libdbus-1-2
Description: Free virtual machine server from VMware
 The free VMware Server lets you run pre-built virtual machines on your desktop.  You can run multiple operating systems

 side-by-side, easing the process of software development, testing, and evaluation.

 Virtual machines developed in VMware Workstation or ESX Server can be run in VMware Server.

 To run the VMware Server Console, just run /usr/bin/vmware from within X.

 Note: You will also need the VMware Server kernel modules to run vmware. These can be built from source from
 vmware-server -kernel-source, or you can install a pre-built vmware-server-kernel-modules package for your kernel.

I have more confidence in the Ubuntu development team than the patch I would have to apply in order to install 1.0.3. If you want to do this yourself, just add the repository to your apt sources list:

deb http://archive.canonical.com/ubuntu feisty-commercial main

You will also have to uncomment the multiverse repository or add it as shown here:

deb http://us.archive.ubuntu.com/ubuntu/ feisty multiverse

This repository contains the vmware-server-kernel-modules package, a prerequisite of vmware-server.

root@edu:~# vi /etc/apt/sources.list
root@edu:~# apt-get update
root@edu:~# aptitude install vmware-server vmware-server-kernel-modules
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages have been kept back:
  ubuntu-minimal xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-elographics xserver-xorg-input-evdev
  xserver-xorg-input-kbd xserver-xorg-input-mouse
The following NEW packages will be installed:
  vmware-server
0 packages upgraded, 1 newly installed, 0 to remove and 7 not upgraded.
Need to get 0B/79.4MB of archives. After unpacking 131MB will be used.
Writing extended state information... Done
Preconfiguring packages ...
Selecting previously deselected package vmware-server.
(Reading database ... 66915 files and directories currently installed.)
Unpacking vmware-server (from .../vmware-server_1.0.2-2_i386.deb) ...

...watch that finish and you're done. I should note that I had an error for the vmnet interfaces:

Starting VMware services:
   Virtual machine monitor                                            failed
   Virtual ethernet                                                   failed
Module vmnet is not loaded.  Please verify that it is loaded before
running this script.

I removed vmware-server, rebooted, and (*sigh*) reinstalled it, then everything was fine. I believe the reason for this was that the vmnet modules had not been loaded. There are, of course, other ways than rebooting to load the modules, but this was the quickest fix at 2 AM. When the interfaces are properly configured and up, you should receive no errors from the vmware-server install script, and the interfaces should show as up:

root@edu:~# ifconfig
eth0      ...

lo        ...

vmnet1    Link encap:Ethernet  HWaddr ...
          inet addr:192.168.129.1  Bcast:192.168.129.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

vmnet8    Link encap:Ethernet  HWaddr ...
          inet addr:192.168.23.1  Bcast:192.168.23.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

--
Posted By treehead to The Path to Root - SysAdmin Blog (Beta) at 5/10/2007 05:48:00 PM