Re: NFS -- Hurd
> Has anyone succeeded in getting a mostly- or entirely- NFS-based
> installation working? That is, anyone running out of a little tiny
> hard drive partition with the rest of the filesystem over NFS? This
> would make installation much more convenient for many people ---
> especially if the PC could be entirely diskless.
It is not currently possible to have a system entirely diskless. I think
it ought to work fine to have only /hurd, /lib, and /servers on the root
filesystem and everything else over nfs. But I don't know of anyone who
has actually tried it, so caveat emptor.
Once you get that working, if that minimal root filesystem image is small
enough to fit in memory, it will not take all that much hacking to be able
to netboot a multiboot image containing it.
> Alternatively, has anyone set up a Debian GNU/Hurd install out of a
> disk file or out of some directory in a GNU/Linux installation? I
> have heard that such things are possible...
This is definitely doable.
The simplest thing (though also the riskiest option) is to use a
subdirectory of an ext2fs filesystem you already have for GNU/Linux. Gord
has previously described this scheme here (using e2os and --chroot), maybe
it's in some web pages somewhere. Since this leaves the possibility of
bugs in the Hurd's ext2fs scribbling on that filesystem (not that this has
happened to anyone lately), I would not recommend this unless you can stand
to lose that filesystem from your Linux system and recover.
I have previously described the --boot-command option here, but that has
not been well-tested and I think it may be buggy.
What I implemented a while ago but hadn't made any announcement about, is
argument parsing for the `remap' store class. What that means is you can
specify a `store' (a `store' is the Hurd abstraction for the where contents
of a filesystem or "block device file" actually reside) in terms of a
block-list of blocks in another store. The syntax for a block list is the
same as used by GRUB. For example:
-Tremap 7+100,123+100:device:hd0s1
is a store specification that says take the store `-Tdevice hd0s1',
use 100 blocks at block #7, then 100 blocks at block #123, to form
a 200-block "virtual disk".
There are a variety of ways to figure out the block list for a file.
On the Hurd, the command `storeinfo FILE' will tell you about that file.
For example, after:
# settrans -cg zz /hurd/storeio -Tremap 7+100,123+100:device:hd0s1
creates a "block device special file" called `zz' with aforementioned store:
# storeinfo zz
device: hd0s1: 512: 200: 102400: 7+100,123+100
If you don't have a Hurd that groks your file already, it's not as easy. :-)
The Linux `dumpe2fs' program will print voluminous output, including a
block list for each inode (and `ls -li file' shows you the inode number you
are looking for). The `debugfs' program might have a more convenient way
to get you the information you need, I haven't played with it.
I was hacking on a script using `minfo' and `mshowfat' (from mtools) to
produce a block list for an MSDOS/Windows file, but it doesn't quite work.
(If you want to take it and hack it into working, let me know.)
Reply to: