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

Hurd Traffic #71 For 13 Dec 2000

Editor: Zack Brown

By Paul Emsley  and  Zack Brown

Mach 4 | Hurd Servers | Debian Hurd Home | Debian Hurd FAQ | debian-hurd List Archives | bug-hurd List Archives | Hurd Reference Manual | Hurd Installation Guide | Cross-Compiling GNUMach | Hurd Hardware Compatibility Guide

Table Of Contents

Introduction

Want to help write KC Debian Hurd? See the KC Authorship page the KC Debian Hurd homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 169 posts in 692K.

There were 54 different contributors. 31 posted more than once. 14 posted last week too.

The top posters of the week were:

1. Gnumach and Hurd Basics

20 Nov 2000 - 4 Dec 2000 (8 posts) Archive Link: "some questions on Hurd"

Summary By Paul Emsley

Topics: FS: ext2

People: Neil WalfieldPaul Emsley

Henning Riedel started off with some common questions about the Hurd. Neil Walfield answered many of his questions:

To explain the difference between a port bucket and a port class Neil used this analogy: " A person needs to send a message to someone else so they hire a messenger. The messenger gets in his vehicle (i.e. his port) and starts it (class: is it a gas car? an electric one? some thing else? Internally they all start differently) and gets on the road that takes him to where he is going (bucket: more than one type of vehicle can travel on a road, however, each road has its own rules, etc.). "

2. Sysvinit

30 Nov 2000 - 3 Dec 2000 (6 posts) Archive Link: "sysvinit"

Summary By Paul Emsley

People: Robert BihlmeyerMarcus Brinkmann

Carson Chittom found that bsdutils required sysvinit, but there was no such package. Robert Bihlmeyer replied "There is no init for the Hurd yet. I think the general opinion is that init & runlevels are Unix cruft that will be replaced by something better on a GNU architecture." He added that the bsdutils of the Hurd binary was old and the current version (1:2.10q-1) did not require sysvinit. Marcus Brinkmann followed up that it was not possible to update bsdutils on the new Hurd binary, because it (bsdutils) was part of the source package util-linux, which was not yet ported.

3. Installing GNU/Hurd From Suse 7.0, Onto ufs; Or From FreeBSD

1 Dec 2000 - 5 Dec 2000 (8 posts) Archive Link: "cross compile gnumach and hurd"

Summary By Paul Emsley

Topics: FS: ext2

People: Roland McGrathFarid HajjiNeal Walfield

Henning Riedel asked if it was possible to cross compile the Hurd using SuSe 7.0. Neal Walfield replied that it was possible, but that he was unsure whether that this could be done using the Debian packages. He added that it was not necessary to cross-compile the Hurd in order to get it running - one simply needed a working dpkg, and the cross-install script would do the rest.

Roland McGrath explained the ufs issue:

The Hurd uses a ufs format that is mostly compatible with BSD, though I am not sure that the Hurd does the right thing with the newest BSD ufs format details if they have changed in recent years (it works with original 4.3BSD and 4.4BSD formats).

The need for this is so that e2fsck will know about the translator blocks. The situation is similar in ufs, but no BSD fsck that I know of knows to check for the Hurd's translator blocks. For both ufs and ext2fs, the Hurd uses the traditional format except for a couple of new inode fields (which occupy space that was unused in the traditional inode formats). The only one of these that involves any hair is the translator field: the Hurd allocates a disk block to hold a passive translator setting, and stores this block number in the inode's translator field. If fsck does not know about this field, it will decide that the block was not really in use and it will mark it for reuse (you will see a complaint "salvaging unused blocks not in allocation bitmap" or something along those lines). In the case of ext2fs, e2fsck checks the "creator os" field in the superblock (this is what "mke2fs -o hurd" sets) and when it's set to the hurd value it knows about the translator inode field and does the right thing. In the case of ufs, you need to use the Hurd's native fsck since that is the only implementation around that knows about the translator field (it would be easy to hack any current BSD system's fsck to grok it).

Farid Hajji mentioned that he was able to cross-compile the Hurd on FreeBSD, the biggest problem being that FreeBSD couldn't make ext file systems. He posted a summary of his cross-compiling experience:

This is a summary of what I had to do to cross-compile the Hurd on a FreeBSD box. Thanks to arkadi for helpful hints. Please send updates or bug-fixes directly to me <farid.hajji@ob.kamp.net>. Thanks.

0. get [or update] from CVS gnumach, hurd, mig, glibc [and probably grub]

1. create a build directory structure like this:

build/
build/binutils -> $(SRC)/binutils-2.10/
build/binutils.build
build/gcc -> $(SRC)/gcc-2.95.2/
build/gccc.build
build/gnumach -> $(SRC)/gnumach/
build/gnumach.build
build/mig -> $(SRC)/mig/
build/mig.build
build/hurd -> $(SRC)/hurd/
build/hurd.build

2. get and install the following tools, if they are not already prsent on your system:

gcc-2.95.2 native build-chain.
gawk-3.0.4
sed-3.02 GNU version of sed!
binutils-2.10 native build chain.

3. create cross-binutils:

make sure that binutils-2.10.tar.bz2 was unpacked in $(SRC)/binutils-2.10/ before resuming...

# set CFLAGS to this, so that no -g flag is used:
export CFLAGS="-march=i586 -O2 -fomit-frame-pointer"

# ensure that GNU sed is in the PATH before FreeBSD's sed:
export PATH=/usr/local/bin:$PATH

# configure binutils in the build.binutils directory,
# then build and install them.
cd build.binutils
../binutils/configure --prefix=/usr/local --target=i586-pc-gnu -v
gmake
gmake check
gmake install (as root, remember to set CFLAGS, PATH)
cd ..

4. start making gcc cross-compiler.

unpack gcc-core-2.95.2.tar.bz2 in $(SRC)/gcc-2.95.2/ then start first step of cross-compiler making...

cd build/gcc.build
../gcc/configure --prefix=/usr/local --target=i586-pc-gnu --with-gnu-as \
--with-gnu-ld
gmake -k

This will fail while trying to make libgcc2.a with the following symptoms:

-----------
In file included from tconfig.h:5,
from ../../gcc-2.95.2/gcc/libgcc2.c:33:
../../gcc-2.95.2/gcc/config/xm-gnu.h:31: fcntl.h: No such file or directory
../../gcc-2.95.2/gcc/libgcc2.c:41: stdlib.h: No such file or directory
../../gcc-2.95.2/gcc/libgcc2.c:42: unistd.h: No such file or directory
gmake[1]: *** [libgcc2.a] Error 1
/users/farid/build/gcc.build/gcc/xgcc -B/users/farid/build/gcc.build/gcc/
-B/usr/local/i586-pc-gnu/bin/
+-I/usr/local/i586-pc-gnu/include -DCROSS_COMPILE -DIN_GCC -march=i586 -O2
-fomit-frame-pointer -I./include
+-c ../../gcc-2.95.2/gcc/libgcc1-test.c
../../gcc-2.95.2/gcc/libgcc1-test.c:101: warning: conflicting types for built-in
function `memcpy'
----------

This error is _expected_ because the headers needed by the cross-compiler are not yet installed. this is why we said -k in the make.

We'll return to finishing the cross gcc make later, when we have installed the mach, hurd and glibc headers (in /usr/local/i586-pc-gnu/include)

For now, just install some headers and stuff of gcc;

cd build/gcc.build
gmake -k install
ln -s /usr/local/i586-pc-gnu \
/usr/local/lib/gcc-lib/i586-pc-gnu/2.95.2/i586-pc-gnu

5. install mach headers

cd build/gnumach.build
../gnumach/configure --build=i386-unknown-freebsdelf --host=i586-pc-gnu
# become root, set CFLAGS and PATH...
gmake -k install-headers prefix=/usr/local/i586-pc-gnu

6. build mig

cd build/mig.build
../mig/configure --target=i586-pc-gnu --host=i386-unknown-freebsdelf \
--prefix=/usr/local
gmake
# as root:
cd /usr/local/i586-pc-gnu/include/mach
ln -s i386 machine
# as normal user:
gmake
gmake install (as root)

7. install hurd headers:

# first of all, generate a configure script from build/hurd/configure.in
cd build/hurd
autoconf

cd build/hurd.build
../hurd/configure --build=i386-unknown-freebsdelf --host=i586-pc-gnu \
--prefix=/usr/local/i586-pc-gnu --disable-profile
# as root (CFLAGS="-march=i586 -g"):
gmake install-headers no_deps=t

8. install glibc headers:

cd build/glibc.build
../glibc/configure --without-cvs --enable-add-ons=crypt \
--build=i586-unknown-freebsdelf --host=i586-pc-gnu \
--prefix= \
--disable-profile

# now install glibc headers:
# (as root):
gmake -k install-headers install_root=/usr/local/i586-pc-gnu
cp ../glibc/include/features.h /usr/local/i586-pc-gnu/include/features.h
mkdir /usr/local/i586-pc-gnu/include/gnu
touch /usr/local/i586-pc-gnu/include/gnu/stubs.h

9. let's finish building cross gcc, now that we have all headers we need:

cd build/gcc.build
export CFLAGS="-march=i586 -O2 -fomit-frame-pointer"
export C_INCLUDE_PATH=/usr/local/i586-pc-gnu/include
gmake

# as root:
gmake install

10. let's finish build of cross-glibc:

make sure, that at least here, gnu sed is in your PATH before any other sed!!!

cd build/glibc.build
gmake <<< this takes a LONG time!

as root:
gmake install install_root=/usr/local/i586-pc-gnu

11. let's build gnumach now (from scratch):

erase and remake build.gnumach, then:

cd build/gnumach.build
../gnumach/configure --build=i386-unknown-freebsdelf --host=i586-pc-gnu \
--enable-floppy --enable-ide --enable-aic7xxx \
--enable-ul
# edit i386/Makefile: MAKE is set to make, not gmake! change this
# to reflect FreeBSD speciality. Then:
gmake << (lots of warnings can be ignored)

# this completes the build of gnumach kernel.

12. install gnumach kernel somewhere:

  1. mkdir /gnu
  2. ln -s /usr/local/i586-pc-gnu/include /gnu/include
    ln -s /usr/local/i586-pc-gnu/lib /gnu/lib
    alternatively: copy contents into /gnu/include, /gnu/lib, but it's better to symlink right now, and copy from i586-pc-gnu to /gnu/{include,lib} later.
  3. as root in build/gnumach.build:
    gmake install-kernel prefix=/gnu

13. fix a bug with libc symlinks: (do this _every_ time you make install glibc, since libc.so is overwritten)

(as root:)
ln -s -f /usr/local/i586-pc-gnu/lib/libc.so.0.2 \
/usr/local/i586-pc-gnu/libc/libc.so

14. rebuild hurd from scratch:

rmdir build/hurd.build
mkdir build/hurd.build
cd build/hurd.build

# manually fix a bug in ../hurd/Makeconf:
# edit ../hurd/Makeconf: comment out definition of CFLAGS
# # CFLAGS=-Wall -g -O3

# remember: CFLAGS="-march=i586 -O2 -fomit-frame-pointer"
# if you want debug infos: -g -Winline (and probably -O)
# because of hurd_fail being inline...

../hurd/configure --build=i386-unknown-freebsdelf --host=i586-pc-gnu \
--prefix=/gnu --disable-profile
(ignore warning about ELF interpreter /lib/ld.so not found...)
gmake (takes a long time, ignore all warnings...)

15. install hurd

(as root:)
export CFLAGS="-march=i586 -O2 -fomit-frame-pointer"
export PATH=/usr/local/bin:$PATH
export MAKE=/usr/local/bin/gmake
cd build/hurd.build
gmake install prefix=/gnu

cp ../hurd/debian/servers.boot /gnu/boot

16. cross-compile install bash and other stuff to get a fully functional system, mke2fs -O sparse_super -o hurd /dev/hdXXXX mount this on newgnu and copy everything from /gnu to /newgnu... then, native-install etc...

4. pfinet Problems

1 Dec 2000 - 2 Dec 2000 (5 posts) Archive Link: "Bug#78524: hurd: pfinet(?) doesn't release bind'ed sockets"

Summary By Zack Brown

People: Marcus BrinkmannRoland McGrath

Marcus Brinkmann reported, "Run nfsd, interrupt it with ^C and try to run it again. It will complain with EADDRINUSE. That's the same problem that prevents restarting X. Killing pfinet let's you start it again." Roland McGrath suggested there might be something holding the port even after the program exited; he suggested that Marcus "watch the no-senders notification arrive in pfinet when the port is deallocated, and see it do the deref. See if there is an internal reference still there from someplace in pfinet." Marcus replied, "yes, I can trace it now. There is indeed a reference count of 1 after the whole processing, so that the port stays around and is not deallocated. I have not yet found out where it is coming from, though." The thread ended there.

5. X Missing From Latest Hurd Snapshot

3 Dec 2000 - 4 Dec 2000 (4 posts) Archive Link: "some trouble"

Summary By Zack Brown

People: Petros SidiropoulosMarcus BrinkmannPetros Sidiropo

Petros Sidiropoulos reported, "If I upgrade to hurd_20001127.deb (from 20001126) the X window system doesn't work." Marcus Brinkmann leaped out of his chair and replied, "Whoa, I forgot to include the X patches...."

6. Install Information

4 Dec 2000 - 5 Dec 2000 (7 posts) Archive Link: "Understanding "The Way Things Go""

Summary By Paul Emsley

Topics: Apt

People: Philip CharlesBob HamMarcus Brinkmann

Bob Ham needed some basic information about how to get the Hurd onto his machine. Marcus Brinkmann answered saying that install information could be found at http://www.debian.org/ports/hurd/hurd-install and www.walfield.org/papers/hurd-installation-guide/. Marcus added that sometimes the dependencies were messed up because of Linux/Hurd synchronization issues and that alpha.gnu.org contained packages which didn't build from the official Debian source (X, apt and util-linux).

Philip Charles added "hurd-D1.iso is the fourth cut at making a Hurd installation CD. The boot-floppies work well; this will boot, partition HDDs," [appropriately format the partition] "and install the tarball. The debian-cd part is not so good, but improving and is of some use; this provides the .deb packages file systems suitable for dpkg, apt etc. hurd-E1 is being worked on at the moment and the debian-cd side has improved, but there is still some way to go before I will be satisfied with it. "

7. Status Of FTPFS

5 Dec 2000 - 7 Dec 2000 (4 posts) Archive Link: "Status of ftpfs?"

Summary By Paul Emsley

Topics: FS: FTPFS

People: Neil WalfieldMichael ObergMark Kettenis

Michael Oberg enquired about the current status of the ftpfs translator. Neil Walfield replied that Mark Kettenis claimed it worked but that he, Neil, had not got it working. Michael then tried it and was able to connect to ftp://ftp.debian.org and copy files (slowly). Neil then said that it might now work for him because Roland had included the Linux TCP/IP stack. He said he'd try again and report back.

8. New Packages And /etc/mtab

5 Dec 2000 - 9 Dec 2000 (27 posts) Archive Link: "Packages needing to be tested"

Summary By Paul Emsley

People: Neil WalfieldNeal WalfieldMarcus BrinkmannPeter HungRobert BihlmeyerCord BeermannRoland McGrathIgor Khavkine

Neil Walfield announced:

For those who want to contribute to the hurd and do not think they know how to or do not have a lot of time or for what ever reason, here is a chance to contribute.

There are many packages that have been compiled for the hurd, however, there are several thousand that have not yet been processed at all.

So, what are those packages? I have generated a script that will find all the packages in Debian/main/i386 that are not in Debian/main/hurd-i386. It is run nightly and is here:

http://walfield.org/hurd/need_compile/

Many should work out of the box. Many will have MAXPATHLEN problems. There may be others.

Give it a go and report any results that you get.

Neil later added, "As Marcus has kindly pointed out to me (which I was trying my best to ignore) is that many of the packages are Linux only packages. (Take a look at base -- kernel modules? Not gnumach or hurd stuff). Thus, take the list with a grain of salt. "

Marcus Brinkmann added, " People interested in software doing this should look at http://sourceforge.net/projects/turtle which I wrote exactly to solve autobuilding the Debian packages for the Hurd, but can be used for other autobuilding as well."

When Peter Hung tried to rebuild some packages he got the problem " dpkg-deb: parse error, in file `debian/gcc/DEBIAN/control' near line 6 package +`g++': `Depends' field, missing package name, or garbage where package name expected dh_builddeb: command returned error code " and line 6 of debian/gcc/DEBIAN/control was "Depends: , libc0.2 (>= 2.1.97), libhz0,libhz0". When he removed the first ",", it would be OK, he said.

Robert Bihlmeyer said " This looks suspiciously like ${shlibs:Depends} getting expanded to nothing. After package building, "debian/substvars" should contain a line beginning with "shlibs:Depends=", is this the case?" . There was no reply to this question.

Cord Beermann inspired a sub-tread with: " slocate compiles without any problem, but it wants /etc/mtab. i changed that to /etc/fstab and as far as i can see it works... "

Neil Walfield suggested that he write an mtab translator " This should not be hard to write, the question is what to include in mtab. My feelings on this are any file filesystem in /etc/fstab that is mounted should be listed (either started or not), however, what is involved in determining what is mounted is another can of worms (think cdrom, etc.). "

Igor Khavkine suggested that translators register with /etc/mtab like processes do with proc, which generated some discussion about which translators should show up in /etc/mtab (so that it is available for use by locate) and what actually starts translators ('stat'ing the directory, at least, it turns out).

Roland McGrath added " Thomas and I discussed many ideas around this a long time ago. The conclusion that we came to is that the only purposes we have for anything like mtab (or its in-core equivalents on other unix systems) is to have a list of "interesting filesystems" for df to show you by default. Perhaps also you might like something a la unix's mount with no args to show you the fsysopts output for each interesting filesystem. On unix, only root can designate a filesystem as interesting so that df will print it, and this is done by the explicit action of running mount. So for the Hurd, there doesn't seem to be a reason for anything other than a hand-maintained file to list the "interesting" filesystems. Since /etc/fstab is already just such a file that is used for fsck at boot time, it seems reasonable enough to use that for df too. " . He also mentioned that /etc/fstab is used for df as well ask fsck.

9. Microkernels On Other Processors

6 Dec 2000 - 9 Dec 2000 (5 posts) Archive Link: "porting to other architectures (68k no mmu family)"

Summary By Paul Emsley

People: Craig ComstockChristopher BrowneFarid HajjiPaul Emsley

Craig Comstock asked " how possible would it be to port Hurd to processors like 68328/68EZ328/etc... (yes, palm pilots...)" . Paul Emsley replied that it is possible but a substantial undertaking, the porting/re-writting of gnumach to take account of the lack of memory management would be most time consuming. Farid Hajji pointed out that other versions of Mach supported different architectures and that perhaps Craig would be interested in RTEMS. Christopher Browne added "Another good place to look would be http://xmach.org/ ; that is apparently reasonably active in building a BSD "user space" on top of Mach. "

10. Status Of Installation Media

8 Dec 2000 - 9 Dec 2000 (3 posts) Archive Link: "Install report"

Summary By Zack Brown

People: Bob HamPhilip Charles

Bob Ham did a Hurd install using Philip Charles' CD image. He reported:

Last night I completed an install using the hurd-D1.iso cd image. I did, however, have some problems. The method that I was to mount the image file on a loop device and use the cross-install, dpkg-hurd and native-install scripts that I downloaded a couple of months ago.

All was fine until running native-install the second time. It seems that libnss-db and libdb2-util were not install, and so dpkg was throwing dependency fits. After getting the .debs on the hurd partition and sorting those packages out, I came accross another problem.

Doing a 'dpkg --configure hurd' caused the error message 'install-info: failed to lock dir for editing! No such file or directory'. This error also came up on a lot of other packages when I tried to run 'dpkg --configure --pending'. Then, while trying to view /var/lib/dpkg/info/hurd.postinst, I accidentally ran it. I tried to ^C it, but I don't think that worked, as I still got an error message about not being called with inappropriate arguements or something. Then, doing a 'dpkg --configure hurd' worked, as did --pending.

So, all's now installed and (relatively) happy. However, there were another couple of things. On boot, I get an error (I believe from some part of the kernel): "hd03: bad access: block=28, count=2, blockend=30, nr_sects2".

Also, I've got a few suggested additions for the CD image for Mr Charles. Firstly, it would be good if the cross-install & co. scripts were there, as I had to use versions from quite a while back. Also, the kernel source would be a good idea. And just one more small thing: the hurd-doc/walf-install.html file has '@option{-o}' style bits about the place, which I assume are markup and shouldn't be there?

 

 

 

 

 

 

Sharon And Joy
 

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.