NOTE:
This requires a minimum of selinux-policy-3.0.8-66.

* Thu Dec 06 2007 Dan Walsh <dwalsh> 3.0.8-66
- Allow depmod to read tmp files from rpm

Jeremy said that he would review these changes.

A number of them are merged.  The bits that aren't (the nbd stuff), I sent you
mail about trying to figure out why it was as convoluted as it is.  But, you
didn't respond to the questions and there's no way I'm going to be able to look
at anything again until the end of the month.

Ah, I see the point of confusion.

emit "mkrootdev -t $rootfs -o $rootopts $rootdev"

In normal cases $rootfs is the actual filesystem type name like ext3 or nfs. 
But in this case nbd itself is not a filesystem, but instead only the block
device where an any arbitrary filesystem could be accessed.

I reused the $rootfs variable to denote that it is a nbd device, and that is
where it becomes more complicated.  The intent is to be able to support *any*
filesystem mounted over that nbd device, because different types of netboot have
different needs.  For example, thin clients or diskless workstations might be
using squashfs (ro), or ext3 within squashfs with dm-snap, or a future
non-crappy unionfs implementation.

mkrootdev alone is not sufficient for this purpose.  I was very limited in the
complexity of scripting possible in the non-bash-branch of mkinitrd, thus I
initial support was only for the most basic nbdtype (squashfs).

I intended on talking to you after returning from vacation and FUDCon about how
to proceed on the other nbdtypes since this is a VERY similar problem to LiveCD
in non-bash-branch.

Do you have time to talk about how to proceed?  I'm willing to implement it in
any way you suggest.

Status Update
This is currently blocking on mayflower-like functionality to be implemented in
mkinitrd proper.  Full NBD support will require the same type of logic necessary
for LiveCD.

Created attachment 295756 [details]
NBD patch from earlier

Hi Jeremy,

The most common case that I need to support is NBD serving only a squashfs
image, with the client mounting that read-only.  It seems that the equivalent
of this functionality belongs in mkinitrd itself and not mkliveinitrd.	Any
recommendation how better to implement this mounting?

Another question for Jeremy or Peter... I need your opinions.

So the current code seems to handle bootproto "dhcp" where it gets the dhcp's
supplied root-path to get the NFS server's IP address and path.

dhcpd.conf:
    option root-path "IPADDR:PATH";
    option root-path "192.168.0.254:/opt/ltsp/i386";

I need to extend mkinitrd to support NBD as well.  The goal is for a single
initrd file to choose NFS or NBD at boot-time depending on what the DHCP server
tells it to do.

Should we overload the root-path option or rely on a completely different custom
defined dhcpd.conf option for NBD?

Scenario 1: Overloading root-path
=================================
NBD syntax:
    option root-path "NBD:IPADDR:PORT";
    option root-path "NBD:192.168.0.254:2000";

Should we overload the meaning of the long established root-path option and
possibly break other software in unpredictable ways?

Scenario 2: New custom defined dhcpd.conf option
================================================
    option nbd-root-path "IPADDR:PORT";
    option nbd-root-path "192.168.0.254:2000";

Or should we define a custom DHCP option and just support it with our client
(mkinitrd)?  The latter might not be such a problem, as there seems to be many
arbitrary options defined in "man dhcp-options" already.

What are your opinions?  

In any case whatever we do in Fedora might be an easy sell for Debian/Ubuntu to
adopt because this is clearly better than what they rely upon currently.

NOTE: The previous comment assumes root of a simple filesystem like squashfs or
ext3, not more complicated scenarios like squashfs in ext3 with dm-snap.

Kindof meh on the patch.

This chunk:
@@ -1206,6 +1235,11 @@ if [ -n "${loopfs}" ] || [[ "$rootopts" =~ "loop" ]]; then
         fi
 fi
 
+if [ "$rootfs" == "nbd" ]; then
+        findmodule nbd
+        findmodule squashfs
+fi
+
 # If we use LVM or dm-based raid, include dm-mod
 # XXX: dm not really supported yet.
 testdm=""

seems like it should be part of handlenbd()

And this chunk:

@@ -1654,10 +1688,17 @@ if [ -n "$loopfs" ]; then
     emit "losetup /dev/loop0 /tmpmount/$looppath"
 fi
 
-emit "echo Creating root device."
-# mkrootdev does "echo /dev/root /sysroot ext3 defaults,ro 0 0 >/etc/fstab"
-emit "mkrootdev -t $rootfs -o $rootopts $rootdev"
-rootdev=/dev/root
+if [ "$rootfs" == "nbd" ]; then
+    [ -z "$remoteip" ] && handlenbd $rootdev
+    emit "/sbin/nbd-client $remoteip $nbdport /dev/nbd0"
+    emit "echo Creating root device."
+    emit "echo /dev/nbd0 /sysroot squashfs ro 0 0 > /etc/fstab"
+else
+    emit "echo Creating root device."
+    # mkrootdev does "echo /dev/root /sysroot ext3 defaults,ro 0 0 >/etc/fstab"
+    emit "mkrootdev -t $rootfs -o $rootopts $rootdev"
+    rootdev=/dev/root
+fi

Is just weird -- why duplicate the "creating root device" line at all?  Also,
the right thing here is to make mkrootdev do the right thing, not to stub it out.

By Jeremy's suggestion I will be implementing a new fstab syntax:
-o nbd will setup the block device in a similar fashion to loop.

mount -t squashfs -o nbd,ro 192.168.0.254:2000 /path/to/mountpoint

Warren, Peter, do you guys feel that this will get done for Fedora 9, especially
now that we're past the feature freeze?  Should this move to the Fedora 10
Tracker/Blocker ?

http://www.ietf.org/mail-archive/web/ips/current/msg02406.html
Apparently iscsi already specifies using the root-path option, and other
documentation does not limit it to be NFS-only.  By pjones recommendation,
agreed upon by dcantrell and Debian, we will use root-path for NBD as well.

Changing to assigned,

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This obviously isn't going to be done, we're well past the feature freeze.  PUNT!

Actually, it was done a while ago.  Closing now.