[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#697017: An improved patch over Jonathan's



On Tue, 1 Jan 2013 11:56:00 -0500 (EST) Stephen Powell
<zlinuxman@wowway.com> wrote:
> On Tue, 01 Jan 2013 10:18:06 -0500 (EST), Gabriel Klawitter wrote:
> > Your patch will sort out cases like 08:02 but not the case where root
> > equals 'facade', 'added' or 'dead01'.
> > I'm using the root= parameter for giving the name of the boot profile,
> > which might differ from 'compute'.
>
> Hmm.  I'm not familiar with the term "boot profile".  Either my
> ignorance is showing, or you are using the "root=" kernel boot parameter
> for something for which it was not intended.

I'd like to respectfully disagree with the assertion that root= was
only ever intended for those cases which init/do_mounts.c
recognizes—the kernel comment you cite is in code that's only relevant
when there is no initrd! In fact the code is written so as not to look
at root= arguments in the presence of a sensible initrd, and I'm
pretty sure that was indeed what it was intended for. I think some
confusion arises because the kernel nfsroot code predates the
introduction of the general initrd mechanism, and the root=/dev/nfs
kludge is left over from those days. Today, I think the right thing to
do is to use the same string as the root= argument that you expect to
pass to mount(8), or its closest equivalent, as first argument.

So, to reiterate:
 - the code in do_mounts.c's prepare_namespace codepath is very old
code that is not being run if we have a sensible initrd (one that
provides /init).
 - instead, root= is being passed through to /init to do with as it pleases.
 - it's sensible enough to use it for whatever argument mount(8) sees

The same applies to the ip= argument, whose handler, even if present,
is careful not to do anything in the absence of a known argument.
Thus, we're free to use ip=whatever for IP configuration, and I
propose to do that to use DHCPv6 or IPv6 SLAAC to setup IPv6-only
root-on-some-sort-of-network-fs machines.

My situation is that I'm mounting a non-NFS network file system as
root, and I feel quite strongly that the correct way to do so is to
specify "root=server:/path rootfstype=diod boot=diod" on the kernel
command line rather than inventing new variables (which would require
modifying initramfs-tools/init, I think!) or abusing nfsroot= to pass
in the server path. To make matters worse, that approach currently
works (with an appropriate /etc/initramfs-tools/scripts/diod script),
but fails mysteriously when the server name is changed to one that
begins with a hexadecimal digit, which is very unintuitive behaviour.

That said, it's more important to me to get this working at all
without having to modify (a future) initramfs-tools, rather than
insisting on doing it in a particular way. (Possibly this should be a
separate post, but for context, here is what I want to do; maybe I'm
just missing a good way of doing all this without modifying /init or
/scripts/functions:
1. specify a server:/path argument to mount -t diod server:/path /root
2. use DHCPv6 (or potentially IPv6 SLAAC) instead of dhcp to discover
the (IPv6) IP to use to mount the root fs
3. use DHCPv6 to discover a name server to use to resolve "server"
4. run mount -t diod server:/path /root in lieu of nfs_mount_root()

Here's how I propose to do this
1. root=server:/path in the kernel command line, modify parse_numeric
not to complain about that
2. ip=dhcpv6 in the kernel command line, modify configure_networking
to source a script file for unknown ip=* options
3. handle this in the ip=dhcpv6 code
4. put this into a scripts/diod file

but I'm open to other suggestions. I have things working, I'm just not
sure what the best way is of packaging/sharing my setup)


Reply to: