[RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

We now have mount hooks.  They are sourced in an infinite loop until one of
them actually mounts the real root filesystem.

This makes it easier to add support for arbitrarily complex schemes to find
the root filesystem without having to patch the init script.

Having an infinite loop is definitly a Bad Idea for production systems, but
people testing initramfs'es using code from some random guy on the Internet
know better than to overwrite the old one, right?

Anyways, this should make adding nfsroot, root on iscsi, root on multipath,
and a whole bunch of other stuff I do not have the environment to code and 
test on easier.

As usual, this patch applies cleanly on top on the rest of my patches, and is
also available at http://git.fnordovax.org/dracut/log/?h=hookify-finding-root

comments, flames, etc. welcome.

---
 hooks/mount-partition.sh |   30 ++++++++++++++++++++++++++++
 init                     |   49 ++++++++++++++++-----------------------------
 modules/90crypt.sh       |    2 +-
 modules/99base.sh        |    4 +-
 4 files changed, 51 insertions(+), 34 deletions(-)

diff --git a/hooks/mount-partition.sh b/hooks/mount-partition.sh
new file mode 100755
index 0000000..53a0f4c
--- /dev/null
+++ b/hooks/mount-partition.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+[ "$root" ] || {
+    root=$(getarg root); root=${root#root=}
+    case $root in
+	LABEL=*) root=${root#LABEL=}
+            root="$(echo $root |sed 's,/,\\x2f,g')"
+            root="/dev/disk/by-label/${root}" ;;
+        UUID=*) root="/dev/disk/by-uuid/${root#UUID=}" ;;
+        '') echo "Warning: no root specified"
+            root="/dev/sda1" ;;
+    esac
+}
+
+[ "$rflags" ] || {
+    if rflags="$(getarg rootflags)"; then
+	rflags="${rflags#rootflags=}"
+	getarg rw >/dev/null && rflags="${rflags},rw" || rflags="${rflags},ro"
+    else
+	getarg rw >/dev/null && rflags=rw || rflags=ro
+    fi
+}
+
+[ "$fstype" ] || {
+    fstype="$(getarg rootfstype)" && fstype="-t ${fstype#rootfstype=}"
+}
+
+[ -e "$root" ] && {
+    ln -sf "$root" /dev/root
+    mount $fstype -o $rflags /dev/root $NEWROOT && ROOTFS_MOUNTED=yes
+}
diff --git a/init b/init
index 581c2b9..3652216 100755
--- a/init
+++ b/init
@@ -50,45 +50,31 @@ mknod /dev/tty0 c 4 0
 mknod /dev/tty1 c 4 1
 mknod /dev/null c 1 3
 
+# pre-udev scripts run before udev starts, and are run only once.
 source_all pre-udev
 
 # start up udev and trigger cold plugs
 udevd --daemon
 udevadm trigger >/dev/null 2>&1
+udevadm settle --timeout=30
 
-# mount the rootfs
 NEWROOT="/sysroot"
-
-# FIXME: there's got to be a better way ...
-# it'd be nice if we had a udev rule that just did all of the bits for
-# figuring out what the specified root is and linking it /dev/root
-root=$(getarg root); root=${root#root=}
-case $root in
-    LABEL=*) root=${root#LABEL=}
-             root="$(echo $root |sed 's,/,\\x2f,g')"
-	     root="/dev/disk/by-label/${root}" ;;
-    UUID=*) root="/dev/disk/by-uuid/${root#UUID=}" ;;
-    '') echo "Warning: no root specified"
-	root="/dev/sda1" ;;
-esac
-
-# should we have a timeout?
-tries=0
-echo "Waiting up to 30 seconds for $root to become available"
-udevadm settle --timeout=30
+# pre-mount happens before we try to mount the root filesystem,
+# and happens once.
 source_all pre-mount
 
-echo "Trying to mount rootfs $root"
-if rflags="$(getarg rootflags)"; then
-    rflags="${rflags#rootflags=}"
-    getarg rw >/dev/null && rflags="${rflags},rw" || rflags="${rflags},ro"
-else
-     getarg rw >/dev/null && rflags=rw || rflags=ro
-fi
-[ -e "$root" ] || emergency_shell
-ln -s "$root" /dev/root 
-fstype="$(getarg rootfstype)" && fstype="-t ${fstype#rootfstype=}" 
-mount $fstype -o $rflags /dev/root $NEWROOT || emergency_shell
+# mount scripts actually try to mount the root filesystem, and may
+# be sourced any number of times. As soon as one suceeds, no more are sourced.
+while :; do
+    for f in /mount/*.sh; do
+	[ -x "$f" ] && . "$f";
+	[ "$ROOTFS_MOUNTED" ] && break;
+    done
+    [ "$ROOTFS_MOUNTED" ] && break;
+    sleep 1
+done
+
+# by the time we get here, the root filesystem should be mounted.
 
 INIT=$(getarg init)
 [ "$INIT" ] || {
@@ -101,7 +87,8 @@ INIT=$(getarg init)
 	emergency_shell
     }
 }
-	    
+
+# pre pivot scripts are sourced just before we switch over to the new root.
 source_all pre-pivot
 echo "Switching to real root filesystem $root"
 exec switch_root "$NEWROOT" "$INIT"  $CMDLINE || {
diff --git a/modules/90crypt.sh b/modules/90crypt.sh
index 9793a4f..5e8f4cb 100755
--- a/modules/90crypt.sh
+++ b/modules/90crypt.sh
@@ -1,4 +1,4 @@
 #!/bin/bash
 inst cryptsetup
 inst_rules "$dsrc/rules.d/63-luks.rules"
-inst_hook pre-mount 50 "$dsrc/hooks/cryptroot.sh"
\ No newline at end of file
+inst_hook mount 10 "$dsrc/hooks/cryptroot.sh"
\ No newline at end of file
diff --git a/modules/99base.sh b/modules/99base.sh
index 1d9f86e..580fb03 100755
--- a/modules/99base.sh
+++ b/modules/99base.sh
@@ -4,5 +4,5 @@ dracut_install mount mknod mkdir modprobe pidof sleep chroot echo sed sh ls
 inst "$initfile" "/init"
 inst "$switchroot" "/sbin/switch_root"
 inst_hook pre-pivot 50 "$dsrc/hooks/selinux-loadpolicy.sh"
-inst_hook pre-mount 99 "$dsrc/hooks/resume.sh"
-
+inst_hook mount 90 "$dsrc/hooks/resume.sh"
+inst_hook mount 99 "$dsrc/hooks/mount-partition.sh"
-- 
1.6.0.6

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Warren Togami]

Hi Victor,

I didn't test this patch yet, but I need this kind of structure in order 
to implement different kinds of netboot.

root=dhcp is a kernel cmdline given by the bootloader (syslinux, grub, 
pxelinux, etc.) which directs the initrd during runtime to bring up eth0 
and do DHCP.  It then mounts the rootfs depending on options given by 
the DHCP server.  Fedora 10 mkinitrd implements the following two types 
of mounts with root=dhcp.

         option root-path "172.31.100.254:/path/to/target_root";
         option root-path "nbd:172.31.100.254:2000:squashfs:ro";

An existing RFC specifies syntax for iscsi that could be implemented as 
well.  (Although iscsi is problematic because some types require 
authentication.)  Arbitrary types of root=dhcp rootfs mounts can be 
implemented with hooks made possible with your patch.

Generation
==========
∘ read mode from dracut.conf i.e. MODE=network
∘ if network
	‣ install network modules
	‣ install tools (mount.nfs, nbd, etc.)
	‣ install squashfs.ko
	‣ install custom udev rules to handle network

Boot (contents of udev rule)
============================
∘ if root=dhcp (or later hard coded network)
	‣ ifup eth0
	‣ dhclient
	‣ parse root-path
	‣ if nbd
		• modprobe nbd
		• nbd-client with parameters
		• (mount rootfs)
	‣ if nfs
		• (mount rootfs)

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Mon, 2009-02-23 at 15:07 -0500, Warren Togami wrote:
> Hi Victor,
> 
> I didn't test this patch yet, but I need this kind of structure in order 
> to implement different kinds of netboot.

I fugured it would be needed, and I certainly don't want to bloat up the
main init script with code that will not be needed on most systems. :) 

> root=dhcp is a kernel cmdline given by the bootloader (syslinux, grub, 
> pxelinux, etc.) which directs the initrd during runtime to bring up eth0 
> and do DHCP.  It then mounts the rootfs depending on options given by 
> the DHCP server.  Fedora 10 mkinitrd implements the following two types 
> of mounts with root=dhcp.
> 
>          option root-path "172.31.100.254:/path/to/target_root";
>          option root-path "nbd:172.31.100.254:2000:squashfs:ro";

Interesting -- I have been working on implementing code to detect and
configure network interfaces according to the netboot.txt kernel
document. The code I have written so far is browseable at
http://git.fnordovax.org/dracut/log/?h=network-configurability
(and it even works some of the time), and I would appreciate input from
someone who actually uses that functionality on a daily basis.
  
> An existing RFC specifies syntax for iscsi that could be implemented as 
> well.  (Although iscsi is problematic because some types require 
> authentication.)  

Yeah, I was thinking of what sort of structure would be needed to let
someone else write code to handle multipath iscsi over teamed nics
without having to patch the main init script.

> Arbitrary types of root=dhcp rootfs mounts can be 
> implemented with hooks made possible with your patch.
> 
> Generation
> ==========
> ∘ read mode from dracut.conf i.e. MODE=network
> ∘ if network
> 	‣ install network modules
> 	‣ install tools (mount.nfs, nbd, etc.)
> 	‣ install squashfs.ko
> 	‣ install custom udev rules to handle network

Not a problem -- I have not gotten to the nfs stuff yet, but the above
branch already works well enough let udev bring network interfaces up
according to what is passed on the kernel command line (assuming I did
not break it again, and assuming you are using dhcp or statically
configuring your interfaces -- I have no plans for adding bootp or rarp
support, but patches to do so are happily accepted).

> Boot (contents of udev rule)
> ============================
> ∘ if root=dhcp (or later hard coded network)
> 	‣ ifup eth0
> 	‣ dhclient

The above branch already knows how to do this stuff. 

> 	‣ parse root-path

Probably cannot do this in udev, but easily doable from a mount hook.

> 	‣ if nbd
> 		• modprobe nbd
> 		• nbd-client with parameters
> 		• (mount rootfs)
> 	‣ if nfs
> 		• (mount rootfs)


I was planning to handle nfsroot in a mount hook as well, extending it
to handle nbd should not be a problem.


> Warren Togami
> wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Warren Togami]

Victor Lowther wrote:
>> root=dhcp is a kernel cmdline given by the bootloader (syslinux, grub, 
>> pxelinux, etc.) which directs the initrd during runtime to bring up eth0 
>> and do DHCP.  It then mounts the rootfs depending on options given by 
>> the DHCP server.  Fedora 10 mkinitrd implements the following two types 
>> of mounts with root=dhcp.
>>
>>          option root-path "172.31.100.254:/path/to/target_root";
>>          option root-path "nbd:172.31.100.254:2000:squashfs:ro";
> 
> Interesting -- I have been working on implementing code to detect and
> configure network interfaces according to the netboot.txt kernel
> document. The code I have written so far is browseable at
> http://git.fnordovax.org/dracut/log/?h=network-configurability
> (and it even works some of the time), and I would appreciate input from
> someone who actually uses that functionality on a daily basis.

What is "netboot.txt document"?  Where is it from?

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Mon, 2009-02-23 at 19:24 -0500, Warren Togami wrote:
> Victor Lowther wrote:
> >> root=dhcp is a kernel cmdline given by the bootloader (syslinux, grub, 
> >> pxelinux, etc.) which directs the initrd during runtime to bring up eth0 
> >> and do DHCP.  It then mounts the rootfs depending on options given by 
> >> the DHCP server.  Fedora 10 mkinitrd implements the following two types 
> >> of mounts with root=dhcp.
> >>
> >>          option root-path "172.31.100.254:/path/to/target_root";
> >>          option root-path "nbd:172.31.100.254:2000:squashfs:ro";
> > 
> > Interesting -- I have been working on implementing code to detect and
> > configure network interfaces according to the netboot.txt kernel
> > document. The code I have written so far is browseable at
> > http://git.fnordovax.org/dracut/log/?h=network-configurability
> > (and it even works some of the time), and I would appreciate input from
> > someone who actually uses that functionality on a daily basis.
> 
> What is "netboot.txt document"?  Where is it from?

bleah -- I meant the kernel nfsroot.txt file -- located at
Documentation/filesystems/nfsroot.txt in the kernel tree.

> Warren Togami
> wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Hi Victor

[snip]
> Interesting -- I have been working on implementing code to detect and
> configure network interfaces according to the netboot.txt kernel
> document. The code I have written so far is browseable at
> http://git.fnordovax.org/dracut/log/?h=network-configurability
> (and it even works some of the time), and I would appreciate input from
> someone who actually uses that functionality on a daily basis.
Looks good. I'm actually considering replacing our own initrd with this 
one when we upgrade our netboots to 2.6.29.

Though I see a small problem: Ever thought about what happens if there 
are multiple interfaces on different networks? Only one is valid to 
mount the root-fs... Currently I've solved that by upping each interface 
and then ping-testing the nfs-server... Any better ideas?

Thanks,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Tue, 2009-02-24 at 09:10 +0100, Seewer Philippe wrote:
> Hi Victor
> 
> [snip]
> > Interesting -- I have been working on implementing code to detect and
> > configure network interfaces according to the netboot.txt kernel
> > document. The code I have written so far is browseable at
> > http://git.fnordovax.org/dracut/log/?h=network-configurability
> > (and it even works some of the time), and I would appreciate input from
> > someone who actually uses that functionality on a daily basis.
> Looks good. I'm actually considering replacing our own initrd with this 
> one when we upgrade our netboots to 2.6.29.

awesome!

> Though I see a small problem: Ever thought about what happens if there 
> are multiple interfaces on different networks? Only one is valid to 
> mount the root-fs... Currently I've solved that by upping each interface 
> and then ping-testing the nfs-server... Any better ideas?

My current plan was to try and mount the NFS share forever, and maybe
panic and die if a timeout option was passed as a kernel parameter.

Yes, I have thought about it, and have come to the conclusion that it is
one of those problems that someone who actually uses it is better
equipped to solve.  Writing the code to bring interfaces up and mount
filesystems is generic, writing code to see if servers are responding
depends on the environment -- the best way for me to handle it is to
make it dead simple for site admins to handle it.

> Thanks,
> Philippe
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Victor Lowther wrote:
[snip]
>> Though I see a small problem: Ever thought about what happens if there 
>> are multiple interfaces on different networks? Only one is valid to 
>> mount the root-fs... Currently I've solved that by upping each interface 
>> and then ping-testing the nfs-server... Any better ideas?
> 
> My current plan was to try and mount the NFS share forever, and maybe
> panic and die if a timeout option was passed as a kernel parameter.
> 
> Yes, I have thought about it, and have come to the conclusion that it is
> one of those problems that someone who actually uses it is better
> equipped to solve.  Writing the code to bring interfaces up and mount
> filesystems is generic, writing code to see if servers are responding
> depends on the environment -- the best way for me to handle it is to
> make it dead simple for site admins to handle it.

I agree, the ifup and mount should be pretty generic.

Browsing through the code a bit more thorougly throws up a few questions:

- 'dhclient -nw': Why are you starting the dhclient in daemon mode? 
Couldn't that pose problems when dhcp takes ages to acquire an adress? I 
mean like, we've ifup'ed all interfaces and are allready in the mount 
hooks without an ip. I guess we'd have to have a blocking mount-script 
waiting for at least one interface to be really brought up or spew an 
error message after a specific time out.

- default gw handling in dhclient-script: 'ip route add default' will 
fail if there's already another default route (Again the case of 
multiple interfaces). Would it be an idea not set a default route at all 
and let a mount-script handle this?

- I'd suggest adding something like if-pre-up.d, etc. Would make it easy 
to integrate wireless and/or wpa support.

- Why are you killing dhclient at the end?

Thanks for the great work!
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Bogdan Costescu]

On Tue, 24 Feb 2009, Seewer Philippe wrote:

> - Why are you killing dhclient at the end?

I can see at least 2 reasons:
- dhclient coming from the initramfs is started on that FS and should
   not be running across the switch_root
- to give the possibility to the actual system being booted to use its
   own network configuration mechanism, be it also DHCP or something
   else

-- 
Bogdan Costescu

IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8240, Fax: +49 6221 54 8850
E-mail: bogdan.costescu-hEciA7+sKtudPOQpRHQ53DeJuz7u0hKX@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Feb 24, 2009, at 7:21 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>  
wrote:

>
>
> Victor Lowther wrote:
> [snip]
>>> Though I see a small problem: Ever thought about what happens if  
>>> there are multiple interfaces on different networks? Only one is  
>>> valid to mount the root-fs... Currently I've solved that by upping  
>>> each interface and then ping-testing the nfs-server... Any better  
>>> ideas?
>> My current plan was to try and mount the NFS share forever, and maybe
>> panic and die if a timeout option was passed as a kernel parameter.
>> Yes, I have thought about it, and have come to the conclusion that  
>> it is
>> one of those problems that someone who actually uses it is better
>> equipped to solve.  Writing the code to bring interfaces up and mount
>> filesystems is generic, writing code to see if servers are responding
>> depends on the environment -- the best way for me to handle it is to
>> make it dead simple for site admins to handle it.
>
> I agree, the ifup and mount should be pretty generic.
>
> Browsing through the code a bit more thorougly throws up a few  
> questions:
>
> - 'dhclient -nw': Why are you starting the dhclient in daemon mode?  
> Couldn't that pose problems when dhcp takes ages to acquire an  
> adress? I mean like, we've ifup'ed all interfaces and are allready  
> in the mount hooks without an ip. I guess we'd have to have a  
> blocking mount-script waiting for at least one interface to be  
> really brought up or spew an error message after a specific time out.

I run it in daemon mode so that udev does not have to wait on it. The  
dhclient-script creates a file when the interface is up, and any  
mounts that depend on the network can wait for those files to appear.  
ifup does the same thing with static interfaces.

> - default gw handling in dhclient-script: 'ip route add default'  
> will fail if there's already another default route (Again the case  
> of multiple interfaces). Would it be an idea not set a default route  
> at all and let a mount-script handle this?

How would the mount script know how to handle this?

> - I'd suggest adding something like if-pre-up.d, etc. Would make it  
> easy to integrate wireless and/or wpa support.

I have no particular plans to add this type of support, but patches  
are welcome.

> - Why are you killing dhclient at the end?

Because I have no idea how well of handles its root filesystem  
vanishing, and all I care about it doing is getting the interface  
configured. I do not care about long-term link management.

> Thanks for the great work!
> Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Kay Sievers]

On Tue, Feb 24, 2009 at 15:19, Victor Lowther <victor.lowther-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Feb 24, 2009, at 7:21 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:

>> - Why are you killing dhclient at the end?
>
> Because I have no idea how well of handles its root filesystem vanishing,
> and all I care about it doing is getting the interface configured. I do not
> care about long-term link management.

Which makes a lot of sense. We usually do not want to leave any
process/service from initramfs staying around, but kill and delete all
of them behind us, if we enter the real root, and start all
processes/services from the real rootfs instead.

Everything else would create a real hard to debug setup if something
goes wrong. We may have different setups/configs/versions/environments
in the real rootfs and the initramfs image.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Victor Lowther wrote:
[snip]
>> - 'dhclient -nw': Why are you starting the dhclient in daemon mode? 
>> Couldn't that pose problems when dhcp takes ages to acquire an adress? 
>> I mean like, we've ifup'ed all interfaces and are allready in the 
>> mount hooks without an ip. I guess we'd have to have a blocking 
>> mount-script waiting for at least one interface to be really brought 
>> up or spew an error message after a specific time out.
> 
> I run it in daemon mode so that udev does not have to wait on it. The 
> dhclient-script creates a file when the interface is up, and any mounts 
> that depend on the network can wait for those files to appear. ifup does 
> the same thing with static interfaces.

I don't like the asynchronousnes of this. This means we have to wait in 
pre-mount or mount until we have at least one interface up without any 
knowledge if another might come up later as well.

>> - default gw handling in dhclient-script: 'ip route add default' will 
>> fail if there's already another default route (Again the case of 
>> multiple interfaces). Would it be an idea not set a default route at 
>> all and let a mount-script handle this?
> 
> How would the mount script know how to handle this?

DHCP lease data is stored in a lease file. if a default-route is sent, 
then there's an entry for that in the lease file.

>> - I'd suggest adding something like if-pre-up.d, etc. Would make it 
>> easy to integrate wireless and/or wpa support.
> 
> I have no particular plans to add this type of support, but patches are 
> welcome.

Will do.

> 
>> - Why are you killing dhclient at the end?
> 
> Because I have no idea how well of handles its root filesystem 
> vanishing, and all I care about it doing is getting the interface 
> configured. I do not care about long-term link management.

Ah, ok! thanks!
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Feb 24, 2009, at 9:39 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>  
wrote:

>
>
> Victor Lowther wrote:
> [snip]
>>> - 'dhclient -nw': Why are you starting the dhclient in daemon  
>>> mode? Couldn't that pose problems when dhcp takes ages to acquire  
>>> an adress? I mean like, we've ifup'ed all interfaces and are  
>>> allready in the mount hooks without an ip. I guess we'd have to  
>>> have a blocking mount-script waiting for at least one interface to  
>>> be really brought up or spew an error message after a specific  
>>> time out.
>> I run it in daemon mode so that udev does not have to wait on it.  
>> The dhclient-script creates a file when the interface is up, and  
>> any mounts that depend on the network can wait for those files to  
>> appear. ifup does the same thing with static interfaces.
>
> I don't like the asynchronousnes of this. This means we have to wait  
> in pre-mount or mount until we have at least one interface up  
> without any knowledge if another might come up later as well.

Good point. I will move ifupping the interfaces to a pre mount hook.

It also sounds like I should get around to writing some real module  
and hook docs.

>
>>> - default gw handling in dhclient-script: 'ip route add default'  
>>> will fail if there's already another default route (Again the case  
>>> of multiple interfaces). Would it be an idea not set a default  
>>> route at all and let a mount-script handle this?
>> How would the mount script know how to handle this?
>
> DHCP lease data is stored in a lease file. if a default-route is  
> sent, then there's an entry for that in the lease file.

I had not thought of a lease file. My current plan was to write out  
the options dhclient recieved in a form that could be sourced by a  
script on a per-interface basis.
>>>

>>> - I'd suggest adding something like if-pre-up.d, etc. Would make  
>>> it easy to integrate wireless and/or wpa support.
>> I have no particular plans to add this type of support, but patches  
>> are welcome.
>
> Will do.
>
>>> - Why are you killing dhclient at the end?
>> Because I have no idea how well of handles its root filesystem  
>> vanishing, and all I care about it doing is getting the interface  
>> configured. I do not care about long-term link management.
>
> Ah, ok! thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs"  
> in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Jeremy Katz]

On Tuesday, February 24 2009, Seewer Philippe said:
> Victor Lowther wrote:
> [snip]
>>> - 'dhclient -nw': Why are you starting the dhclient in daemon mode?  
>>> Couldn't that pose problems when dhcp takes ages to acquire an 
>>> adress? I mean like, we've ifup'ed all interfaces and are allready in 
>>> the mount hooks without an ip. I guess we'd have to have a blocking  
>>> mount-script waiting for at least one interface to be really brought  
>>> up or spew an error message after a specific time out.
>>
>> I run it in daemon mode so that udev does not have to wait on it. The  
>> dhclient-script creates a file when the interface is up, and any mounts 
>> that depend on the network can wait for those files to appear. ifup 
>> does the same thing with static interfaces.
>
> I don't like the asynchronousnes of this. This means we have to wait in  
> pre-mount or mount until we have at least one interface up without any  
> knowledge if another might come up later as well.

The problem is that the appearance of devices *is* asynchronous and you
have to keep things as event driven.  That's why originally everything
was being driven off of udev rules rather than hooks.  If you start
trying to do things in hooks and assume synchronous behavior, boot will
be slower and you also can't have, eg, usb devices being used (usb plug
events are always async; anything else is an illusion)

Jeremy
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Jeremy Katz wrote:
> On Tuesday, February 24 2009, Seewer Philippe said:
>> Victor Lowther wrote:
>> [snip]
>>>> - 'dhclient -nw': Why are you starting the dhclient in daemon mode?  
>>>> Couldn't that pose problems when dhcp takes ages to acquire an 
>>>> adress? I mean like, we've ifup'ed all interfaces and are allready in 
>>>> the mount hooks without an ip. I guess we'd have to have a blocking  
>>>> mount-script waiting for at least one interface to be really brought  
>>>> up or spew an error message after a specific time out.
>>> I run it in daemon mode so that udev does not have to wait on it. The  
>>> dhclient-script creates a file when the interface is up, and any mounts 
>>> that depend on the network can wait for those files to appear. ifup 
>>> does the same thing with static interfaces.
>> I don't like the asynchronousnes of this. This means we have to wait in  
>> pre-mount or mount until we have at least one interface up without any  
>> knowledge if another might come up later as well.
> 
> The problem is that the appearance of devices *is* asynchronous and you
> have to keep things as event driven.  That's why originally everything
> was being driven off of udev rules rather than hooks.  If you start
> trying to do things in hooks and assume synchronous behavior, boot will
> be slower and you also can't have, eg, usb devices being used (usb plug
> events are always async; anything else is an illusion)

That is of course correct. Though in the case of a netboot I'd like to 
argue that we absolutely need to make sure that networking is correctly 
set up before trying to mount anything. So making it synchronous makes 
the whole a lot easier to control.

And to be honest, with netboot I don't think boot time matters all that 
much. The bottleneck will always be dhcp and the net itself.

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Tue, 2009-02-24 at 16:39 +0100, Seewer Philippe wrote:
> 
> Victor Lowther wrote:
> > I run it in daemon mode so that udev does not have to wait on it. The 
> > dhclient-script creates a file when the interface is up, and any mounts 
> > that depend on the network can wait for those files to appear. ifup does 
> > the same thing with static interfaces.
> 
> I don't like the asynchronousnes of this. This means we have to wait in 
> pre-mount or mount until we have at least one interface up without any 
> knowledge if another might come up later as well.

OK, the latest change moves handling interfaces that we requested DHCP
on into a pre-mount hook, and the dhclient-script now saves all the
options it got from the server into a file that should be sourceable
(although I have not tested that yet).  Interfaces with static
assignments are still handled on the fly as we find them.  Is this
something that is more easily customizable to your requirements?

-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Bogdan Costescu]

On Tue, 24 Feb 2009, Victor Lowther wrote:

> My current plan was to try and mount the NFS share forever

Generally speaking, with any network based share, if you try to mount 
it forever you might generate a DoS on the server exporting it, 
especially if several computers boot at the same time.

-- 
Bogdan Costescu

IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8240, Fax: +49 6221 54 8850
E-mail: bogdan.costescu-hEciA7+sKtudPOQpRHQ53DeJuz7u0hKX@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Bogdan Costescu wrote:
> On Tue, 24 Feb 2009, Victor Lowther wrote:
> 
>> My current plan was to try and mount the NFS share forever
> 
> Generally speaking, with any network based share, if you try to mount it 
> forever you might generate a DoS on the server exporting it, especially 
> if several computers boot at the same time.

That is correct. Although in a nfsroot environment mounting the share 
"forever" (read: lifetime until shutdown) is a necessity.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Bogdan Costescu]

On Tue, 24 Feb 2009, Seewer Philippe wrote:

> Though I see a small problem: Ever thought about what happens if 
> there are multiple interfaces on different networks? Only one is 
> valid to mount the root-fs...

The Debian initramfs-tools documents as following here the rule from 
the kernel's nfsroot.txt which allows an ip=... kernel command line 
parameter which can contain the name of the device. Is this an option 
that would fit your purpose ?

From what I know, there is no automated way to get that information 
automatically in the format described, so you'd have to maintain it, 
possibly in a PXE config file; it's possible to find out what 
interface was used for PXE booting when using PXELINUX with the 
'IPAPPEND 2' option which will add a BOOTIF=mac_address to the kernel 
command line.

This might however not be enough: there could be a case where the 
booting (via PXE) is done on a different network (and interface) than 
the one where the root NFS is exported. I know that this sounds 
complicated, but it has been implemented in real life ;-)

-- 
Bogdan Costescu

IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8240, Fax: +49 6221 54 8850
E-mail: bogdan.costescu-hEciA7+sKtudPOQpRHQ53DeJuz7u0hKX@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Bogdan Costescu wrote:
> On Tue, 24 Feb 2009, Seewer Philippe wrote:
> 
>> Though I see a small problem: Ever thought about what happens if there 
>> are multiple interfaces on different networks? Only one is valid to 
>> mount the root-fs...
> 
> The Debian initramfs-tools documents as following here the rule from the 
> kernel's nfsroot.txt which allows an ip=... kernel command line 
> parameter which can contain the name of the device. Is this an option 
> that would fit your purpose ?

In my case: no. I need a general purpose netboot init where I don't know which or how many interfaces there are.


>  From what I know, there is no automated way to get that information 
> automatically in the format described, so you'd have to maintain it, 
> possibly in a PXE config file; it's possible to find out what interface 
> was used for PXE booting when using PXELINUX with the 'IPAPPEND 2' 
> option which will add a BOOTIF=mac_address to the kernel command line.

That is correct. Sadly this only works in a PXE environment.


> This might however not be enough: there could be a case where the 
> booting (via PXE) is done on a different network (and interface) than 
> the one where the root NFS is exported. I know that this sounds 
> complicated, but it has been implemented in real life ;-)

Aye. Or similar: Consider a system with an interface into the standardnetwork and one into a lab net. Both yield correct dhcp results but only one is correct for a specific root-server.

To solve this, I'm currently just doing the network stuff sequentially, aborting when I've found the correct interface. The script looks more or less like this (yes, I know its ugly):

...
NETDEVICE=""
for i in $(sed -nr 's/^ *(\w+[0-9]+):.*$/\1/p' /proc/net/dev) ; do
	NETDEVICE=""
	for j in 1 2 3 4; do
	        if (udhcpc --interface=$i -n >/dev/null 2>&1) ; then
			NETDEVICE=$i
			break;
		fi
	        sleep $j
        done

	if [ "$NETDEVICE" = "" ] ; then
                continue
        fi

	NETDEVICE=""
	if (ping -c 2 $NFSSERVER >/dev/null 2>&1) ; then
		NETDEVICE=$i
	fi

	if [ "$NETDEVICE" = "" ] ; then
		ifconfig $i down
		continue
	fi

	NETDEVICE=""
	if (mount -r $NFSOPTS $NFSSERVER:$NFSPATH /newroot >/dev/null 2>&1) ; then
		NETDEVICE=$i
	fi

	if [ "$NETDEVICE" = "" ] ; then
		ifconfig $i down
		continue
	fi
done
if [ "$NETDEVICE" = "" ] ; then
	echo "Error: " #lots of text here
	sh -i
fi
...

Hmm... looking at this, we can do this with Dracut really simple: 

1. Don't start dhclient inside udev. Might even be a good idea, since IMHO udev is "only" there to load modules and set up devicefiles, not necessarily configure the devices. 
2. Use a pre-mount script to up interfaces. dracut could provide a simple script for simple cases which can be overridden with site specific craziness. 
3. A simple mount.nfs would be enough in /mount/

What do you think?

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Hi all

Warren Togami wrote:
[snip]
> root=dhcp is a kernel cmdline given by the bootloader (syslinux, grub, 
> pxelinux, etc.) which directs the initrd during runtime to bring up eth0 
> and do DHCP.  It then mounts the rootfs depending on options given by 
> the DHCP server.  Fedora 10 mkinitrd implements the following two types 
> of mounts with root=dhcp.
> 
>         option root-path "172.31.100.254:/path/to/target_root";
>         option root-path "nbd:172.31.100.254:2000:squashfs:ro";
> 
> An existing RFC specifies syntax for iscsi that could be implemented as 
> well.  (Although iscsi is problematic because some types require 
> authentication.)  Arbitrary types of root=dhcp rootfs mounts can be 
> implemented with hooks made possible with your patch.

A question: Why not use root=/dev/nfs and the other options according to 
kernel doc, like nfsroot=... and ip=autoconf? For me that is much more 
readable.

Maybe even leave nfsroot-mounting to the kernel as long as that features 
remains in the tree.

I guess nbd and iscsi could go the same way like root=/dev/iscsi ...

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Victor Lowther]

On Tue, 2009-02-24 at 09:00 +0100, Seewer Philippe wrote:
> Hi all
> 
> Warren Togami wrote:
> [snip]
> > root=dhcp is a kernel cmdline given by the bootloader (syslinux, grub, 
> > pxelinux, etc.) which directs the initrd during runtime to bring up eth0 
> > and do DHCP.  It then mounts the rootfs depending on options given by 
> > the DHCP server.  Fedora 10 mkinitrd implements the following two types 
> > of mounts with root=dhcp.
> > 
> >         option root-path "172.31.100.254:/path/to/target_root";
> >         option root-path "nbd:172.31.100.254:2000:squashfs:ro";
> > 
> > An existing RFC specifies syntax for iscsi that could be implemented as 
> > well.  (Although iscsi is problematic because some types require 
> > authentication.)  Arbitrary types of root=dhcp rootfs mounts can be 
> > implemented with hooks made possible with your patch.
> 
> A question: Why not use root=/dev/nfs and the other options according to 
> kernel doc, like nfsroot=... and ip=autoconf? For me that is much more 
> readable.

It is a matter of taste and historical contingency, I suppose.  The
current nfsroot mounting stuff was added way before initramfs/initrd was
an option, and it was probably easier to not mess up the in-kernel root=
handling code (which expected a device to mount).  Since initramfs
handles all that stuff now (assuming you are using it, of course), the
kernel neither knows nor cares about the contents of the root=
parameter, and we do not have to be bound by its restrictions. We can
make (for example) root=192.168.10.2:/my/root/path do The Right Thing
and mount that as an nfs filesystem.  We would still handle the other
case, of course.

> Maybe even leave nfsroot-mounting to the kernel as long as that features 
> remains in the tree.

That is impossible when using an initramfs.  Once the kernel notices an
initramfs, finds /init on it and execs it, it is up to the initramfs to
handle everything else.

> I guess nbd and iscsi could go the same way like root=/dev/iscsi ...

It is as easy to handle it one way or the other in userspace.  I happen
to think that overloading root= is easier to read, and prevents having
to remember yet another *root parameter when someone invents an even
more convoluted and crazy way to store a filesystem. :) 

> Regards,
> Philippe
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Victor Lowther wrote:
[snip]
>> Maybe even leave nfsroot-mounting to the kernel as long as that features 
>> remains in the tree.
> 
> That is impossible when using an initramfs.  Once the kernel notices an
> initramfs, finds /init on it and execs it, it is up to the initramfs to
> handle everything else.
Ah well, stupid me forgot that. sorry.

> 
>> I guess nbd and iscsi could go the same way like root=/dev/iscsi ...
> 
> It is as easy to handle it one way or the other in userspace.  I happen
> to think that overloading root= is easier to read, and prevents having
> to remember yet another *root parameter when someone invents an even
> more convoluted and crazy way to store a filesystem. :) 

hmmm... 'convoluted and crazy' ok you got me.

Question: Do you we want to agree on a specific scheme for setting root 
options? I'm thinking (for example) about having one initramfs for both 
nfsroot and nbdroot.

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Warren Togami]

Seewer Philippe wrote:
> 
> Question: Do you we want to agree on a specific scheme for setting root 
> options? I'm thinking (for example) about having one initramfs for both 
> nfsroot and nbdroot.
> 

This is exactly what I proposed.  If root=dhcp is given as a kernel 
cmdline from the bootloader, the initrd brings up the ethernet 
interface, dhclient, parses the output, and mounts whatever is defined 
in DHCP root-path parameter.  Fedora 10+ mkinitrd does this today.

Alternatively, root= can explicitly define a root-path in exactly the 
same syntax that it would get from DHCP root-path.

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Thiago Galesi]

>> Warren Togami wrote:
>> >
>>
>> A question: Why not use root=/dev/nfs and the other options according to
>> kernel doc, like nfsroot=... and ip=autoconf? For me that is much more
>> readable.
>
> It is a matter of taste and historical contingency, I suppose.  The
> current nfsroot mounting stuff was added way before initramfs/initrd was
> an option, and it was probably easier to not mess up the in-kernel root=
> handling code (which expected a device to mount).


I think it is important to keep backwards compatibility in this
specific case, and handle "root=/dev/nfs" kind of stuff. Really, think
about keeping 2, 3 different cmdlines depending if the system is newer
or older. It may look like a small hassle, but getting this right
sometimes takes some time

Since initramfs
> handles all that stuff now (assuming you are using it, of course), the
> kernel neither knows nor cares about the contents of the root=
> parameter, and we do not have to be bound by its restrictions. We can
> make (for example) root=192.168.10.2:/my/root/path do The Right Thing
> and mount that as an nfs filesystem.  We would still handle the other
> case, of course.

Sometimes it does care. Even thougheverybody uses initrds today,
theoretically we should be able to use only the kernel (think really
tiny system, embedded systems, etc)



-- 
-
Thiago Galesi
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Thiago Galesi wrote:
>>> Warren Togami wrote:
>>> A question: Why not use root=/dev/nfs and the other options according to
>>> kernel doc, like nfsroot=... and ip=autoconf? For me that is much more
>>> readable.
>> It is a matter of taste and historical contingency, I suppose.  The
>> current nfsroot mounting stuff was added way before initramfs/initrd was
>> an option, and it was probably easier to not mess up the in-kernel root=
>> handling code (which expected a device to mount).
> 
> 
> I think it is important to keep backwards compatibility in this
> specific case, and handle "root=/dev/nfs" kind of stuff. Really, think
> about keeping 2, 3 different cmdlines depending if the system is newer
> or older. It may look like a small hassle, but getting this right
> sometimes takes some time

Suggestion: Since all hook scripts are sourced, why not put the option 
parsing stuff inside pre-mount, setting global variables the mount 
scripts can depend on? That way we can handle any option passing we 
want, even through dhcp options.

Regards,
Philippe

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Warren Togami]

Thiago Galesi wrote:
>>> Warren Togami wrote:
>>> A question: Why not use root=/dev/nfs and the other options according to
>>> kernel doc, like nfsroot=... and ip=autoconf? For me that is much more
>>> readable.
>> It is a matter of taste and historical contingency, I suppose.  The
>> current nfsroot mounting stuff was added way before initramfs/initrd was
>> an option, and it was probably easier to not mess up the in-kernel root=
>> handling code (which expected a device to mount).
> 
> 
> I think it is important to keep backwards compatibility in this
> specific case, and handle "root=/dev/nfs" kind of stuff. Really, think
> about keeping 2, 3 different cmdlines depending if the system is newer
> or older. It may look like a small hassle, but getting this right
> sometimes takes some time


Who's tools handled "root=/dev/nfs"?  /dev/nfs cannot be a valid dev node?

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Seewer Philippe]

Warren Togami wrote:
> Thiago Galesi wrote:
>>>> Warren Togami wrote:
>>>> A question: Why not use root=/dev/nfs and the other options 
>>>> according to
>>>> kernel doc, like nfsroot=... and ip=autoconf? For me that is much more
>>>> readable.
>>> It is a matter of taste and historical contingency, I suppose.  The
>>> current nfsroot mounting stuff was added way before initramfs/initrd was
>>> an option, and it was probably easier to not mess up the in-kernel root=
>>> handling code (which expected a device to mount).
>>
>>
>> I think it is important to keep backwards compatibility in this
>> specific case, and handle "root=/dev/nfs" kind of stuff. Really, think
>> about keeping 2, 3 different cmdlines depending if the system is newer
>> or older. It may look like a small hassle, but getting this right
>> sometimes takes some time
> 
> 
> Who's tools handled "root=/dev/nfs"?  /dev/nfs cannot be a valid dev node?

That's an in-kernel implementation, or for user-space a hint that there 
should be a nfsroot cmdline optione.

> 
> Warren Togami
> wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> -- 
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Move actually mounting the root filesystem into its own series of hooks.

[Thiago Galesi]

>> I think it is important to keep backwards compatibility in this
>> specific case, and handle "root=/dev/nfs" kind of stuff. Really, think
>> about keeping 2, 3 different cmdlines depending if the system is newer
>> or older. It may look like a small hassle, but getting this right
>> sometimes takes some time
>
>
> Who's tools handled "root=/dev/nfs"?  /dev/nfs cannot be a valid dev node?

Take a look at /Documentation/filesystems/nfsroot.txt

-- 
-
Thiago Galesi
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html