Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Hurd Traffic #61 For 4 Oct 2000

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
 
-- Linus Torvalds, 1991

Table Of Contents

 

1. Installation Gets Easier
20 Sep 2000 - 25 Sep 2000 (6 posts) Archive Link: "Hurd installation CD"
People: Philip CharlesJames FranklinMarcus Brinkmann

Philip Charles announced:

This is coming along nicely. I have successfully installed Hurd from a stack of floppies, 11 in all not counting Grub. Boot-floppies is now at the stage where it can be linked up to build a Hurd installation system ready for an installation CD.

The installation can be performed directly from the CD, from floppies or a combination of both. The plethora of Debian's alternative boot and root floppies built specifically for Hurd will be available and Hurd partitions can be created from the main installation menu. No more typos!

The Hurd .deb packages from gnu.org will be the default packages available to dselect. I am proposing to include the Hurd .deb packages from debian.org as a separate file system. Has anyone got any better ideas?

I am also intending to use the latest tarball and Grub. Are their any reasons not to do this?

There is one problem. I not able to create /dev/hd1 and mount the cdrom onto it. This has to be done after running native-install and before any other packages are installed. Could someone give me some advice please, or better still write something I can include in the documentation.

A number of cosmetic modifications have been made to messages and the main installation menu, but there are more that can be made. These will require some serious rewriting so I am not going to break my neck over them.

The release date should be the middle of next week. I will doing some serious negotiation locally to see if I can get the images on a Dunedin NZ site.

Marcus Brinkmann replied that Philip should wait for the next release of the tarball before making his images. Marcus planned to upload the tarball within a few hours or a day, to fix a bug in 'gnumach' that could cause crashes. James Franklin suggested, "Perhaps even hold off for a few days on the new tarball to be sure it is quite stable before creating the iso image." There was also some discussion of Philip's problem creating and mounting the CD partition, though it seemed to resolve itself, at least partially, over the course of discussion.

 

2. Tarball Directory Structure Changes
25 Sep 2000 (1 post) Archive Link: "root in tar file"
People: Marcus Brinkmann

Marcus Brinkmann announced:

I probably created some confusion about the root of the tar file. In 1999, I started with bin/, etc, so that the tar file extracts in the current directory. Then, I switched over to gnu/bin, etc, so that all files in the tar file are prefixed by /gnu.

I switched back now. The hurd-20000925.tar.gz which I uploaded now extracts in the local directory, and I will stick to that.

Usually, I think that tar files should not extract into the local directory. But this is a very special case, as it contains the base of an entire operating system, and prefixing it requires to use gnu/ as the mountpoint or create a symlink or move the files after extraction. This is also consistent with the Debian base.tar.gz.

So, please check all install guides that they make the correct assumption. I think the easy guide does it right (but please double check, Matthew), and the small guide at debian.org does it right as well. I don't know about the other guides.

People should always check the content with tar tzf before extracting anyway.

There was no reply.

 

3. Things To Help With The Hurd
25 Sep 2000 - 26 Sep 2000 (3 posts) Archive Link: "Help offered"
People: Brent Fulgham

Someone offered to help out with the Hurd, and Brent Fulgham said:

Marcus just got X working. If you could install the X packages from alpha.gnu.org, then try to build X applications. This is uncharted territory for us, so any help here is great.

Just download source packages and try to configure and build them. Report back here with any problems you have.

And Prabhu Ramachandran gave a link into the archives, where Brent had listed other things that needed doing.

 

4. GUI Desktop On The Hurd?
26 Sep 2000 (2 posts) Archive Link: "Packages coming soon"
People: Marcus BrinkmannRamakrishnan M

Marcus Brinkmann announced:

this is my current task list for packages to compile and upload, just so that everyone is informed (and shiver in aticipation or just avoid duplicated efforts).

1. fvwm and rxvt (their upload was rejected, because I messed it up).

2. libungif, imlib, gqview, orbit, gnome-libs Some of them have small problems (libtool version, one MAXPATHLEN issue) but basically work.

3. gnome-core, bonobo, enlightenment, gnome-games, gnome-applets I will try those, but don't know how well they work yet.

You see, we will get some gnome stuff soon. I also want to try sawmill.

4. glibc 2.1.94 (pre-2.2), gcc, db2, nss-db The transition requires building gcc twice, glibc twice as well, and some other packages, so this is something for a long weekend :)

Ramakrishnan M's eyes bugged out and he said, "Wow!!" and added, "I am already shivering!!!"

(ed. [] I know how he feels. The Hurd has made such strides recently, it's starting to really look usable. I think PPP remains the Achilles heel for wide doption by curious experimenters.)

 

5. The Hurd On VMWare
28 Sep 2000 - 29 Sep 2000 (5 posts) Archive Link: "How I installed the Hurd on VMware."
Topics: Emulators: VMWare, Emulators: plex86, FS: NFS, FS: ext2
People: Eric HanchrowWerner Koch

Eric Hanchrow described his recent success (quoted in full):

VMWare 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/index.html" 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!

Radovan Garabik asked if Eric would make his virtual disk image available somewhere so folks could play around on it without having to go through the full install.

And Werner Koch commented:

[Tsss, the real GNU system running as task of a proprietary software]

There is a free project named plex86 which aims to do the same as VMware and it would be a Good Thing to support this project to mature to a level where it can be used to develop free OSes.

For other coverage of the Hurd on VMWare, it was working way back in Issue #8, Section #1  (19 Jun 1999: VMWare And The Hurd) . Almost right away there were criticisms of it's nonfree status, as in Issue #9, Section #2  (22 Jul 1999: Partition Sizing; VMWare; Booting From A Disk Image) . The subject was fairly quiet until Issue #38, Section #1  (29 Feb 2000: Hurd On VMWare/plex86; Philosophy Of Using Free Software) when the politics surrounding VMWare came a bit clearer. Throughout all of this, more and more folks were getting the Hurd up on VMWare and posting their HOWTO's for it, as in Issue #43, Section #3  (4 Apr 2000: Installation Report) . It seems that, free or not, a lot of people find VMWare an easy path to experimenting with the Hurd.

 

6. More Work On Installation CD
29 Sep 2000 - 30 Sep 2000 (7 posts) Archive Link: "Installation CD"
Topics: Bootloaders
People: Philip CharlesMarcus BrinkmannOKUJI Yoshinori

Philip Charles reported that the installation CD was building nicely, both US and non-US versions, and amounted to about 200M, which would take about 17 hours to upload to a given site. He asked, "I am using the latest tarball and include grub-boot-19990907.bin, is there any reason to change these?" Marcus Brinkmann replied:

If the latest tarball is 20000925, that's okay.

The grub-boot though is utterly out of date.

Check out

alpha.gnu.org/gnu/grub/grub-boot-0.5.93.1.image

please.

Philip replied that the tarball was in fact 20000925, and that he'd use the latest GRUB boot image from that site. OKUJI Yoshinori remarked that the image Marcus had listed was also out-of-date, and Marcus concurred, saying that grub-boot-0.5.95.image was the latest.

 

7. Modems Now Work; Getting Closer To PPP
29 Sep 2000 - 1 Oct 2000 (8 posts) Archive Link: "modems should work now (who was going to work on ppp?)"
People: Marcus BrinkmannSteve BowmanRoland McGrath

Marcus Brinkmann fixed a significant bug in gnumach, and reported, "I was able to talk to my modem with minicom (I think I needed to disable m_flush, but I am not sure about my hack. So if minicom doesn't work for you, ...), and dial out." He invited folks to work on PPP. Steve Bowman replied:

Well, I'm not sure about volunteering to take the lead on this, but I have started working on it. It's going to take awhile so be patient. I may come back to the list a few times for questions/guidance.

So far, I've got the ppp network interface device mostly wired into gnumach (slip, too). I've got a few critical pieces ifdef'd out so I can see if I've got the build flags and dependencies mostly worked out which I do. The resulting kernel boots. I'll have to look more at the critical pieces to see what's needed to make them work. The pieces already done are mostly just scavenged from linux (from kernel 2.0.36 which is the version of the other linux sources - to reduce kernel drift incompatibilities to a minimum.). The critical pieces ifdef'd out need to be wired into mach/hurd and have to do with process management and ttys. This is where I'll have to spend awhile longer studying the source and my time is quite limited. This is also where I'll probably need some pointers.

All of this is just the first step, there's still the porting of the ppp daemon itself which I've also started (started with ppp 2.4.0f before I started working on gnumach. The linux code put into gnumach looks like about vintage 2.3.7 IIRC so I'm going to restart this with the 2.3.11 ppp source available in potato. Most of the work will be writing a pppd/sys-gnu.c file. I have no idea how much of sys-linux.c can be used.), then stopped pending gnumach support.

Roland McGrath and Marcus both said that wiring network interface devices into gnumach was not the right approach, and Steve replied, "Well, I'm glad I posted before I went any further. :-) I'll think about it some more." He went back into the list archives and found the earlier discussions. These were most recently covered last issue in Issue #60, Section #5  (13 Sep 2000: PPP: Will The Saga Continue?) , which also gives links to previous discussions.

 

8. More PPP Work
1 Oct 2000 (3 posts) Archive Link: "PPP"
People: Daniel E. BaumannMarcus Brinkmann

Daniel E. Baumann announced, "I heard that there was a patch for pfinet to allow it to have multiple interfaces so my question is where is it? Is it usable and if so is there a reason why it is not in CVS? If it is not usable (or I am mistaken and something like this does not exist) then is it true that whoever does implement PPP will have to help rewrite pfinet? I still have two more months to devote to it (I do have some other classes though, but they are HSS classes, not much hacking going on there :P ). I hope at the very least I can help get pfinet rewritten then the porting of some user space utilities (BSD ppp or whatever) would be the next logical step, right?" Marcus Brinkmann replied that the status of pfinet was unclear, but that, "No, a rewrite is not necessary, but an extension. The task is to get a tunnel interface in pfinet by having pfinet translate /dev/tun0 as well. This requires adding a portclass, implementing trivfs stubs for this (select will be a bit hard), and porting ppp to this interface."

 

 

 

 

 

 

We Hope You Enjoy Hurd Traffic
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.