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
