Re: initramfs-tools & nbd
good evening,
On Thu, Dec 27, 2007 at 11:48:56PM +0100, Wouter Verhelst wrote:
> I've been looking into writing the necessary code to support doing root
> on NBD. After reading initramfs-tools(8), I think I understand that
> there will be no networking unless the system is configured for an NFS
> root setup.
the current use cases of networking inside initramfs are NFS.
yes there is currently no other tested path,
but that doesn't mean it should stay so.
> One way to work around that problem would be to trick initramfs-tools'
> 'init' script into believing that we're trying to do an NFS mount, only
> to change the world from under it at the very last moment and to tell it
> that we're actually going to do a somewhat local mount, triggering the
> regular "local" block device handling in the process.
nack this sounds like a bad hack.
i asssume to have ndb working you have to install some user tools
that could just also ship the according i-t hook and boot scripts.
live-initramfs uses it's own boot method, which results in
-- snipp init
maybe_break mount
log_begin_msg "Mounting root file system..."
. /scripts/${BOOT}
--
this is something you should definetly look into.
> Since that sounds incredibly ugly, I think it's probably best if I just
> make sure that the configure_networking function from /scripts/functions
> is called from my nbd boot script, which should be in local-top.
see aboves.
i don't think so.
> This is much cleaner, but there are still some minor issues:
>
> - configure_networking needs IPOPTS to be set, which is not exported
> into the environment. Re-parsing the commandline from my boot script
> to make sure IPOPTS is set would obviously work, but that seems
> somewhat brittle. Would it make sense to export this variable from
> /init, so that my boot script can call it if necessary?
hmm
doesn't seem to be export candidate, but if yes convince me.
currently works in nfs although didn't trace why right now.
yes please try to use that function it was explictly taken out
of scripts/nfs to get more wider usage. if something is wrong
there don't hesitate to bug.
> - I would need to somehow set the server we're connecting to, and the
> port on which we're trying to connect to that server; it seems to me
> that the best way to do this is to create more commandline variables;
> I suggest "nbdsrv=" for the server, and "nbdport=" for the port.
> Perhaps you might want to add those to your documentation (once the
> support is actually there, that is)
namespace appears sane.
well afaik nbd is not merged upstream?
is there support for nbd root in another distro?
if there is already some initrd usage history please base your cmdline
args on it.
yes for such special cases please parse the chosen bootargs in
your own boot scritps as later mentioned cryptsetup.
> - It would appear that currently, if you want to figure out whether
> something uses a specific block device (or even a block device of
> which the name matches a regular expression) under some layers of lvm
> or other device-mapper trickery, you need to script that on your own.
> Is this true? If not, what function should I be calling? If so,
> wouldn't it be interesting to add such a function?
lvm had historicaly a big trouble that
vgchange -a y
could potentialy lead to data trouble,
that's why it is a bit of a pain if you can't rely on it's userspace
implementation to detect itself, otherwise you should just be able
to do:
run_scripts /scripts/local-top
> Comments?
checking for strings.h... no
that is an very old bsdism not needed use string.h
conftest.o: In function `main':
/tmp/nbd-2.9.9/conftest.c:77: undefined reference to `ferror'
seems time i push that into klibc. :)
regards
--
maks
Reply to: