Re: initramfs-tools & nbd
On Fri, 28 Dec 2007, Wouter Verhelst wrote:
> On Fri, Dec 28, 2007 at 01:03:50AM +0100, maximilian attems wrote:
> >
> > On Thu, Dec 27, 2007 at 11:48:56PM +0100, Wouter Verhelst wrote:
>
> > 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?
no a different boot method adds it script to scripts/ topdir
but according to belows that could be overkill.
> 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.
i see thanks for info, in that case yes local-top sounds like the
right place to put the nbd boot script.
> > 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.
indeed as simple hook file you can need it to be exported.
fine with me, i can add that for next release.
> That was the idea :)
>
> > well afaik nbd is not merged upstream?
>
> What do you mean by that?
kernel side, or is it entirely usperspace?
> > 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:
<snipp 2 implementations>
i see ok so no need to match their interfaces.
> 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.
hmm can nfs4 do over ipv6, never tested nfsroot over ipv6 so..
> > > 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...
strings.h should die, it's completly useless since long ;)
> > 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.
yeah but i have an hacked up klibc with some features
that is not pushed upstream that has it need to sit down
at some point.
> 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.
oh that is very easy, two liner:
apt-get install libklibc-dev
./configure CC=klcc
make
but i didn't get far yet on plain klibc as you see above,
currently udev and module-init-tools are supported.
need to get mdadm working too and maybe lvm2 later
of course patches welcome
git clone git://git.kernel.org/pub/scm/libs/klibc/klibc.git
the promising branch is the one with the stdio work.
--
maks
Reply to: