How I installed the Hurd on VMware.
The following message is a courtesy copy of an article
that has been posted to vmware.guest.misc as well.
<a href=http://www.vmware.com>VMware</a> is a nifty (albeit non-free,
alas) program that emulates a physical PC in software. It's ideal for
messing about with a new operating system, when you don't want to
repartition your disk or reboot your machine.
I have what I believe is the latest version of VMware for Linux --
2.0.2 build 621.
First the Executive Summary:
* grub-boot-0.5.95.image appears to have less-than-useful defaults in
the file menu.lst -- "timeout" is set to 0, which means you don't
get to see the boot menu, and "default" is also set to 0, which
means it tries to boot multi-user, with the root device being sd0s1
-- neither of those settings were what I wanted as I installed the
Hurd.
* For some utterly mysterious reason, the Hurd (or Mach, I'm not sure
which) fails to boot when the virtual machine has more than 32MB of
memory, but works fine with exactly 32MB.
Now the details:
[ In almost all cases below, when I talk about rebooting, or about
typing something at a command prompt, I'm referring to rebooting a
*virtual* machine, and typing something at the *virtual machine's*
command prompt, not my actual Linux "host" machine.
The only commands that I recall running on my actual host machine
were those that
* downloaded the files for the Hurd
* started a Web browser to read the instructions
* ran VMware itself
* appended some zeros to the grub boot image (I explain that further
below). ]
I started by reading
http://www.gnu.org/software/hurd/getting-help.html#Installation. That
site referred me to http://pick.sel.cam.ac.uk/~mcv21/hurd.html, but
that site appeared to be down, so I settled for
http://www.gnu.org/software/hurd/easy.html. (I would have preferred
reading the former cam.ac.uk page, since #Installation says that it is
the master, whereas the gnu.org page is only an infrequently-(once per
week) updated copy.)
I then prepared two "virtual" disks for VMware, one for the Hurd's
root and one for swap. Here's how I did it: I started VMware, and
used its Configuration Editor to create two new virtual disks, one 500
MB, the other 200 MB. Then I connected the larger of those disks to a
virtual Linux machine that I already had lying around, and booted it;
following the instructions, I then (at the virtual Linux machine's
prompt), did
fdisk /dev/hdd
In fdisk, I created a standard Linux (type 83) partition spanning the
entire disk. Then, still at the virtual Linux console, I created a
filesystem on it:
mke2fs -O sparse_super -o hurd /dev/hdd1
just as the instructions said (except, of course, I used /dev/hdd1
instead of whichever special file that the instructions mentioned).
I then halted the virtual machine, and installed the other virtual
disk, and used fdisk to create a partition on it, this time making it
type 82 (Linux swap). (I would have preferred to prepare both disks
at once, but the virtual machine only "has" four IDE devices, and
three were already in use, so I could prepare only one disk at a time
-- and the virtual machine requires a reboot whenever you change
"hardware".)
Onto my actual Linux host machine, I downloaded gnu-20000925.tar.gz
and grub-boot-0.5.95.image from
ftp://alpha.gnu.org/pub/gnu/hurd/contrib/marcus/. I made them
available via NFS to the virtual machine, which I once again booted
into Linux. I had the larger of the two disks (the one on which I'd
created a filesystem) installed, and I mounted it under /gnu, and then
did
cd /gnu
tar --same-owner zxpf /blah/blah/blah/gnu-20000925.tar.gz
Note that I believe the command line given on the Web page is wrong --
it says
tar --same-owner -zxvpf /path/to/tarball /gnu
and I believe that the final "/gnu" argument has no effect.
I then shut down the virtual linux machine.
Back on the host machine, I appended some zeros to the grub boot image
with the following shell script. I did this because I believe
(although I'm not sure) that VMware has a bug, or misfeature, in that
it doesn't gracefully deal with floppy images that are smaller than
the expected size for a particular format; I can't remember the
details. In any case, I doubt it hurt.
#!/bin/sh
set -e
# Append some zeros to the named file, in order to make it just the
# right size.
# This is the size of a standard 1.44MB floppy disk, in bytes.
desired_size=1474560
file_name=$1
if [ ! -r $file_name ]; then
echo $file_name is not readable.
exit 1
fi
shift
if [ -n "$1" ]; then
desired_size=$1
fi
actual_size=$(ls -l $file_name | awk '{print $5}')
echo File name : $file_name
echo Desired size: $desired_size
echo Actual size : $actual_size
if [ $actual_size -ge $desired_size ]; then
echo Actual size $actual_size is not smaller than desired size $desired_size.
exit 0
fi
zeroes_needed=$(expr $desired_size - $actual_size)
echo Appending $zeroes_needed zeroes.
tempfile=$(tempfile)
dd if=/dev/zero of=$tempfile bs=$zeroes_needed count=1
cat $file_name $tempfile > $file_name.padded
echo New padded file is $file_name.padded
rm $tempfile
I then configured a new virtual machine for the Hurd. I told VMware
that the operating system type was "other". I also had it "give" the
machine 32 MB of memory (the default for OSs of type "other"), one
Ethernet card, two IDE hard disks -- namely the two that I'd prepared
with Linux -- and one floppy, namely the padded grub boot image that I
just made.
I then held my breath, and booted. However, I did not see, as the
instructions said, "a menu asking you to select one of five options".
Instead, I saw a prompt that informed me that Mach (or the Hurd, or
something) couldn't find the root device sd0s1, and asked me to type
in a new one. So I typed in "hd0s1"; I then accepted the default path
to the servers.boot script. That appeared to work -- I got a shell,
just as the instructions said I would, and I started
"./native-install", as instructed. However, there were a few minor
errors during that process (sorry, I cannot remember what they were);
for reasons made clear below, I don't think those errors were
important.
I poked around, and did various random things which I can't remember,
until it totally freaked out -- emitting the same error message over
and over, and not responding to a control-C. The error message had
the word "paging" or "pager" in it, and vaguely implied that the
machine was out of memory. Again, I don't think this error was
important; I assumed it was a reasonable result of the machine's
having only 32MB of RAM, and no swap.
I shut down the VMware box, and increased its RAM to 96MB. Then when
I rebooted, after I typed in the correct name of the root device, and
accepted the default path to servers.boot, I saw a message to the
effect of
panic: /dev/hd0s1//hurd/ext2fs.static: Not a directory
I don't remember the exact wording of that message, although I can
easily reproduce it if anyone is interested. I am certain, however,
that the word "panic" was in it, and that there were two consecutive
slashes, as I've shown them, and that it ended with "Not a
directory".
At first I figured I hosed the file system, so I reinstalled from
scratch -- recreated the virtual disks, re-ran ext2fs, everything.
That didn't fix the problem.
After hours of trying this and that, I finally restored the virtual
machine's memory to 32MB as it had been the last time things worked,
and that made the problem go away.
Once I'd stumbled onto that workaround, I edited the grub boot menu,
by changing the timeout from "0" to "3600". Then, when I restarted
the installation process, I booted single-user, as the instructions
told me to (on my first installation attempt, I had been booting
multi-user without knowing it); that time, the installation didn't
give any errors that I can recall.
I also had installed a swap disk, which probably explains why I didn't
get hung up on the "paging" or "pager" error the second time around.
I was then able to run "dselect", and download lots of Debian packages
from woody, with *almost* no problems -- a few packages failed to
configure, but there were clear messages about lack of memory, so I
plan on increasing the size of the swap disk, and continuing.
::
Note that the Hurd seems slower than other OSs that I run on VMware,
although I haven't timed anything. Perhaps VMware has been optimized
for those other OSs, and not for the Hurd. Certainly VMware makes no
claim to support the Hurd. Perhaps that will change :)
::
Congratulations to the Hurd developers, who have been slogging away at
this for literally years -- they've already got a usable system, and
they appear to be very close to a drop-in replacement for Linux!
--
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276
Reply to: