Re: initramfs-tools & nbd
On Fri, Dec 28, 2007 at 01:03:50AM +0100, maximilian attems wrote:
> 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.
Hehe :)
> > 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.
Exactly.
> 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.
That would replace part or all of the "init" script, right?
I'm afraid that's not a very good idea. Once connected, an NBD device is
a regular block device, which can contain swap partitions, filesystems,
and other muck. I don't want to deal with those; all I want to do is to
allow initramfs to connect an NBD device. After that, it should no
longer be my problem.
For that to work properly, I need the "init" script to work as it would
under normal circumstances.
> > 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.
Eh, well.
To me, it's important that configure_networking works, somehow. By
looking at the code, I *think* that requires IPOPTS to be exported, but
I didn't actually test or anything; so if you're telling me that this is
not true, great.
However you decide to make it work, that's up to you of course.
> > - 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.
That was the idea :)
> well afaik nbd is not merged upstream?
What do you mean by that?
> is there support for nbd root in another distro?
No
> if there is already some initrd usage history please base your cmdline
> args on it.
There are currently two implementations of root-on-NBD that I'm aware
of:
- One, by Christian Laurs, at http://borderworlds.dk/projects/#nr which
he wrote a few years back. His implementation uses "nbdroot=ip:port".
It's a small C implementation that still uses pivot_root, and is quite
inflexible in that it doesn't support anything but ext2 as the root
filesystem (I'm fairly sure it is so old that ext3 didn't even exist
yet at the time). Of course the code is pretty trivial, so patching it
to support something else than ext2 is fairly simple; but still.
- The second is done by the LTSP guys. This is *very* LTSP-specific, to
the point that they use a tftp client to fetch a file called
"lts.conf" from the same server and look up a server and port number
in there.
The problem with the "nbdroot" parameter is that I do plan to implement
IPv6 support in NBD at some point; and then separating the IP address
from the port by a colon is going to prove problematic.
I don't think Christian's version has seen much usage, so
> 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
Autotools did that. I don't think it's very important...
> conftest.o: In function `main':
> /tmp/nbd-2.9.9/conftest.c:77: undefined reference to `ferror'
> seems time i push that into klibc. :)
Only configure uses it; nbd-client itself doesn't.
That said, how do I compile anything against klibc? I seem to be missing
the documentation... and it might be nice to just be able to tell the
configure script that I want it to use klibc for the client, but glibc
for the server.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: