Re: "New" Installation Method of the Hurd, please tes, develop and comment
> Someone also mentioned that it might be possible to boot the Hurd from a
> subdirectory of an ext2 filesystem (as if it were in a chrooted environment..)
Yes, use the --chroot=DIR (aka -C DIR) option to your bootstrap filesystem.
That is, in the ext2fs line of your servers.boot file, add
e.g. --chroot=/usr/local/hurd if your hurd root starts at /usr/local/hurd.
Note that you will have to prepend /usr/local/hurd/ to the filenames in
your servers.boot file and to the ones you give GRUB on its command line or
in its /boot/grub/menu.lst file. (Those two files are read by GRUB and by
serverboot to load the bootstrap filesystem and give it those options, so
they know nothing about any --chroot setting.)
This has probably been discussed in more detail before; please consult the
mailing list archives. Someone should put this in the various FAQs and
such too (and if it's already there, shame on you for not finding it there
before asking! :-).
> What's the status of that? (and if support isn't explicitly there..
I'm not sure how well it's been tested, but it is all there.
You should realize that there is substantially more risk to your existing
filesystem this way than giving the Hurd its own filesystem in one way or
another. It has been a very long time since anyone has seen a Hurd bug
that scribbled on a filesystem, but if the Hurd scribbles on your
filesystem it could in theory get corrupted such that you lose data from
the other directories on the filesystem (your Linux portion).
The other way to go is to make an ext2fs in a file on your filesystem.
Then figure out what disk blocks that file is on (hopefully it's
contiguous, but it doesn't have to be). Then you can use -Tremap with a
blocklist to tell your hurd bootstrap filesystem to use a virtual disk made
up of those particular disk blocks. The details have been posted here
before, search the list archives for `remap'.
> does chroot work in the Hurd, and could we use
> bootcommand='/usr/local/hurd/bin/chroot /usr/local/hurd /bin/init' to boot up?
chroot does work, but it is not really reasonable to use it in this way.
The core Hurd servers start up before init, and they need to have the right
idea of the root filesystem. The --chroot option essentially does what a
`chroot' would do, but it's done to the very first port to the root
directory as soon as the filesystem starts up, before anything else gets it.
> Would the Hurd's extended filesystem data (translators and so on) mess up the
> ext2 filesystem that was already there?)
No, but you must make the filesystem compatible by setting its `creator_os'
field to `hurd'. You can do this when making the filesystem with the `-o
hurd' flag to mke2fs (it's the default when running mke2fs on the Hurd).
There is a portable shell script installed in `/sbin/e2os' in the Hurd dist
that will diddle the creator_os field on an existing ext2fs using dd. If
you do not do this, you will get `Operation not supported' errors from the
Hurd when you try to set passive translators on that filesystem--and the
Hurd's root filesystem must contain some passive translators for the Hurd
to boot normally.
A `hurd' ext2fs can be used completely normally from Linux. It is safe to
run fsck on Linux, and safe to mount and write files on Linux.
I believe that using e2os to change a linux ext2fs to a hurd ext2fs is
safe, but it uses dd to the device to diddle your superblock, so it's a
fundamentally dicey thing to be doing, and don't come after me with a bat
if you trash your filesystem. The Linux kernel ignores the creator_os
field completely, and e2fsck understands the field and does the right thing
for hurd. Make absolutely sure the filesystem fsck's cleanly before you
tweak it.
Reply to: