[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linux 2.6 PATCH] support for Hurd ext2 format extensions

From: Michael Banck
Subject: Re: [Linux 2.6 PATCH] support for Hurd ext2 format extensions
Date: Mon, 1 Mar 2004 17:12:03 +0100
User-agent: Mutt/

On Fri, Feb 20, 2004 at 02:46:36PM -0800, Roland McGrath wrote:
> I am not going to submit this to Linus et al until I've gotten
> positive reports that people are actually using it in practice and
> successfully.

I've did some more testing of your patch yesterday. For that, I
bootstrapped a new Debian GNU/Hurd installation with crosshurd, did some
minimal configuration and then tarred up the installation with 'star
artype=exustar -xattr ...' from Linux.

I then tried to extract the tar.bz2 on another machine, from Linux. The
first round went pretty bad, it crashed when it came to /hurd or
/libexec (the files in there seem to have a gnu.author set, as opposed
to all other files in /bin, /sbin, /lib, etc. At least star was
complaining abut not being able to setxattr, while it was quiet for the
other files).

Extracting the tarball without -xattr still resulted in the hangup I
described in an earlier mail.

I then booted into Linux-2.4, extracted the tarball and rebooted to
Linux-2.6-xattr-hurd. I removed /servers and /dev and extracted just a
couple of translators at once with star, unmounting and fscking the
partition in between. That seemed to work pretty well, I was able to
boot into single-user mode and use pipes (e.g. cat native-install |
tail) or run programs without ever setting any passive translator while
running GNU/Hurd natively.

I was not able to get the login prompt though. Eventually, the bootup
seemed fine until the end of /libexec/rc, but the console did not come
up (which might well be due to not having all essential translators
extracted or an unrelated error on my part (I modified
/libexec/runsystem.gnu to run the Hurd console by default)).

I have to add that I finally encountered some file system corruption
similar to what I described earlier (which was pretty isolated though,
and could be fixed by removing and re-extracting the translators of the
affected inode, usually) and that trying to extract the whole /dev at
once quite reliably resulted in a crash.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]