Re: Installation of the Hurd
Roland Stigge <stigge@informatik.hu-berlin.de> writes:
Hi,
[...]
> > > I observed that ftp://ftp.gnuab.org/pub/gnu/gnu.tar.bz2 is much smaller
> > > than http://people.debian.org/~rmh/gnu/gnu.tar.bz2 (just about the
> > > half). E.g. /usr/share/doc/ package directories are missing, so I
> > > couldn't check easily the changelog and date.
> >
> > This tarball was prepared using crosshurd, IIRC. Is it possible the
> > tarball is this big because all debs are in it (IIRC it was something
> > like that)?
>
> Yes. There seem to be 62 debs in /var/cache/apt/archives/ in ~rmh's
> tarball. But nevertheless, shouldn't be crosshurd the right tool here
> instead of unpacking a tarball?
The tarball mainly exists because crosshurd is only available for
debian.
> > > Indeed, on "ls -l", it reports just the uids, not the names. Trying
> > > "adduser", the system responded that perl is not available.
> >
> > How did you install? Crosshurd or the tarball?
>
> Both don't have /etc/passwd after install (and ./native-install).
Did you use crosshurd from unstable, btw (IIRC you should)? It would
be nice if you can report this bug using the debian BTS. (I have no
idea what the procedures are or if it is possible to report this)
[...]
> Maybe this is related to it: The last message of ./native-install is
> "./native-install: Cannot make pipe for command substitution: Protocol
> family not supported". I get a similar output on MAKEDEV. But the
> respective devices seem to be created ok after MAKEDEV. Another typical
> error on the remaining screen is "./native-install: line 219: umount:
> command not found".
Pipes are not available until the pflocal translator is set. I do not
exactly remember how that works, but IIRC it was:
settrans -acp /servers/sockets/1 /hurd/pflocal
Can someone please correct me if I am wrong. It is a while ago since
I did this and I'm too lazy to start my GNU/Hurd box ATM. :)
Someone was working on this problem, AFAIK. There was some discussion
about this on IRC but I don't remember if it was fixed.
> Since the only place where the other "known bugs" are currently recorded
> publicly are the mailing list archives, I will possibly file them to the
> Debian BTS. (Even the GNU Hurd page suggests using it.) I mean:
Please do!
> * Too_much_memory bug (workaround: uppermem ...)
> * /hurd/ext2fs.static I/O error messages
Please report this on savannah (as well):
http://savannah.nongnu.org/bugs/?group=hurd
Please report all bugs in GNUMach, MiG and the Hurd here. Not every
Hurd hacker looks at the Debian BTS. But reporting it to the Debian
BTS is useful aswell. I think it can't hurt to report it at both
places.
> * The directly above described bug(s)
> * Wishlist: GNUmach should be updated. I discovered that the current
> version is 1.2 installed by crosshurd
Are you sure it is 1.2? The problem is that GNUMach 1.3 displays a
message that is is 1.2 (or something like that). Did you check the
package version or the on screen messages.
> Is crosshurd the right package here to file all those against? What's up
> with the "hurd" package? Last upload from 2002-11-20 with some
> outstanding bugs.
Jeff will upload the new glibc soon. After that the new Hurd package
will made and uploaded.
Can someone please explain me why the Hurd depends on this new glibc?
This makes no sense to me at all...
Thanks a lot for the reports of the problems/bugs you encountered. I
can only wish that everyone who installs GNU/Hurd sends such detailed
reports.
--
Marco
Reply to: