On 05/27/2009 08:23 PM, David Dillow wrote:
Options:
1) Re-implement it entirely in dracut without relying on the kernel
implementation. But will it work? The kernel seeing root=/dev/nfs will
try to do its own thing anyway?
2) Drop this entirely. If somebody chooses to use this method of nfs
boot dracut isn't involved.
Well, yes, Warren. If the kernel has CONFIG_ROOT_NFS set and sees these
options, I expect the initrd will not be used. But I don't think any
distro that dracut would support has this set. Certainly it has caused
no problems in my writing and testing the nfsroot code I did last month.
OK, I personally am not interested in this behavior. I will leave it up
to others if dracut should support it.
* DHCP root-path option, with varying forms
Using next-server or server-id opt and root-path as pure path:
${next_server-${server_id}}:${root_path}
This particular method is ambiguous, why next-server or server-id?
If next-server is set, use it. If not, use server-id. This method has
been long used and is unambiguous.
Ditto.
I think we should seriously consider that we shouldn't be concerned with
every possible legacy method of setting up nfsroot. Each generation of
software has the opportunity to configure itself in the way that it
needs. What scenarios are there where this isn't true?
I mean, if you use old software, don't use dracut.
This isn't about using old software, it is about allowing old
configuration methods to work so that dracut can be a drop in
replacement. I'm not saying these are all good ways to do it, or that we
necessarily need to support all of them, but if they are easy to map to
our solution once we choose it, then it makes sense to do so.
It's nice when software is usable without having to read all of the
documentation -- in many ways, this allows a dracut-enabled distro to be
dropped into place in an existing DHCP environment, which may have
thousands of nodes using the existing syntax.
The dracut documentation should reduce confusion by describing one
official syntax. I'll leave it up to others to decide if dracut should
support legacy/deprecated syntaxes. I guess I don't care too much to
fight it.
* What about multiple devices?
AFAIK nothing out there supports booting from the second interface. Am
I wrong?
gedi-tools.sf.net will boot from whatever interface and remap it to
eth0. You yourself were complaining about issues with wireless. I have
several machines in which the interface they should boot of off is not
eth0, and it is not possible to swap the order of the cards.
Besides, it is already implemented, sans bugs from my forward port.
OK, another case where I don't care about it, as long as other people
make the code work.
Might I ask though, if no ip= line is supplied, assume dhcp and use only
whatever it thinks is eth0.
Warren Togami
wtogami@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
