On 05/23/2009 09:00 PM, David Dillow wrote:
* I haven't found other initramfs's using NBD, but I've not searched
very hard.
Debian/Ubuntu's initramfs-tools allows you to hard-code a NBD server and
port during initrd generation.
NFS
* Kernel command line, as documented in Documentation/filesystems/nfsroot.txt
root=/dev/nfs
nfsroot=[ip:]path[,options]
Replaces %s in path with text IP address
If option missing, path defaults to "/tftpboot/%s"
If IP is missing, uses server address from ip= line
This is an abomination. I haven't anyone ever use this. In-kernel dhcp
client? How do you control which interface to use? Seems like a lot of
room for error. Also it seems this relies on having no initrd,
bypassing other things you may want to do before mounting rootfs like
load policy?
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.
* 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?
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.
Debian style syntax. With the base device being an optional number to indicate
the nbd device to use.
root=/dev/nbd[0-9]* nbdroot=server.ip.add.ress,port[,nbd basedevice]
This is from Andreas' suggested patch for nbd root, where this is the
third supported method of booting nbd. I think we should DROP this.
The reason for this is it used to be necessary to define a specific nbd
device number because old versions of nbd-client did not have a method
to detect if a nbd device is already connected and in-use. Modern
versions do not have this problem. Code using it simply iterates
looking for the first unused nbd device.
The ability to specify a nbd mount point with cmdline should be using
the new syntax. We should drop this old syntax because it is redundant,
and more error prone.
Using root-path as full info:
server:path
Current dracut uses DHCP root-path option:
nfs://server/path
Where did this syntax come from? Is there precedent? If not, I don't
think Dracut should be inventing something new only because it visually
looks better.
My udev nfsroot patchset uses DHCP root-path option with command line override:
[ip:]path[:options]
What are possible options for nfs?
URI scheme proposed at http://apps.sourceforge.net/trac/dracut/wiki/commandline
root=nfs://server:port/path
root=nbd://server:port/path
root=iscsi://server:port/target
(Same note as above, I don't think Dracut should be inventing new syntax
only because it looks better, especially when it is functionally less
expressive than the existing RFC's and implementations.)
Open issues:
* How to handle authentication data for iSCSI and NFS, if at all.
Does this always involve certificates or keys? If so, we might have no
option but to make it embedded in the initrd during generation.
* How to handle unionfs/aufs mounts?
Debian/Ubuntu and possibly others will demand this, as this is their
solution to read-only root netboot. How to sanely define this in the
initrd while still maintaining a generalized initrd? Perhaps not possible.
* How to handle dm-snapshot, eg for LiveCD overlays.
Same problem as above.
* FCoE/AoE/DBRD/SRP -- I didn't search for examples on these.
* Lustre/network filesystem du jour support -- I think these are
possible, just need to be careful parsing things out. Not
terribly important right now.
Define a sane standard for our existing protocols first, then it might
become more clear what we should do for others?
* Using the dracut URI scheme above as a strawman, shouldn't
"root=nfs://...." imply "ip=dhcp" if none is given?
ip=dhcp should be implied if you specify root=dhcp or any other option
that needs dhcp to go online, while not otherwise specified static.
* What about multiple devices?
AFAIK nothing out there supports booting from the second interface. Am
I wrong?
* How many legacy ways of doing this should we support?
I am suggesting *NONE* for the above reasons.
* How do we separate options to the network block transport vs the
filesystem mount?
What network block transport options are you talking about?
* How do we allow use of these features both via the cmdline and via
DHCP?
root=(what would come from root-path?)
If that clashes with in-kernel stuff, we could define our own:
root-path=(what would come from root-path)
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
