initrd-netboot-tools bad interaction with e2fsprogs possible fix affecting initrd-tools

[Alex Owen <rao3@leicester.ac.uk>]

severity 298787 important
merge 298787 284526
thanks

These bugs #298787 and #284526 are both symptoms of the same issue.

e2fsprogs contains a script /usr/share/e2fsprogs/initrd.ext3-add-journal
which /usr/share/initrd-tools/scripts/e2fsprogs copied into the initrd
when mkinitrd is invoked.

/usr/share/e2fsprogs/initrd.ext3-add-journal (or /scripts/ext3-add-journal.sh
as it is called in the initrd) containos the following code:

if [ $rootdev != 256 ]; then
#...SNIP...
    get_device
    mount_device
#...SNIP...
    umount -n /mnt > /dev/null 2>&1
#...SNIP...
fi

As you can see this script undoes initrd-netboot-tools hardwork of
mounting the nfs root directory!

Now for the interaction with devfs. The default initrd-netboot-tools
forcably mounts devfs at /mnt/dev after mounting the nfsroot at /mnt .
This will casue the "umount -n /mnt" command in ext3-add-journal.sh
to fail as you cannot unmount a filesystem upon which other
fliesystems are mounted! Therefore most people most of the time do not
notice this "BUG".

There are several potential solutions to this problem...
[1]
The hack is to mount something other than devfs at dev.. this has the
potential to grow into a sysfs solution too. somthing along the lines of:

#instead ot mounting devfs
mkdir /tmp/.nfs.dev
mount --bind /mnt/dev/ /tmp/.nfs.dev
chroot /mnt mount -nt tmpfs tmpfs dev
cp -a /tmp/.nfs.dev/* /mnt/dev/
umount /tmp/.nfs.dev

Somthing like this may be needed but is STILL A HACK as it just masks the
problem of the interaction with the ext3-add-journal.sh code.

[2]
The  ext3-add-journal.sh code is in many ways modeled on the initrd
/sbin/init code in that  both use the construct:
	rootdev=$(cat proc/sys/kernel/real-root-dev)
	if [ $rootdev != 256 ]; then
	#stuff
	fi
to protect "#stuff" from running in some circumstances.

ext3-add-journal.sh protects:
    get_device
    mount_device
this way and init protects:
    mount_root
which in turn calls get_device and mount_device this way.

My understanding of the function mount_root is to mount the device who's
major/minor numbers are stored in proc/sys/kernel/real-root-dev

I think initrd-netboot-tools should somehow be telling init and
ext3-add-journal.sh not to bother with some of their efforts notably
running any of:
    get_device
    mount_device
    mount_root

The only IPC route provided is use of proc/sys/kernel/real-root-dev.

Why could initrd-netboot-tools not:
 "echo 256 >proc/sys/kernel/real-root-dev"
and perform the:
        cd mnt
        [ $DEVFS ] && mount -nt devfs devfs dev
        pivot_root . initrd
inthe 90_mount_nfs_root script?

This may not work as this may be excecuted in a subshell... I'll need to
test this... However assuming it will work...

This would stop ext3-add-journal.sh from unmounting the nfsroot should
ext3-add-journal.sh run after 90_mount_nfs_root script (which it will).
Should ext3-add-journal.sh be renamed so that it runs earlier
90_mount_nfs_root will still correctly mount /mnt .

If this will not work we could get ext3-add-journal.sh renamed to
00_ext3-add-journal.sh by cooperation with e2fsprogs mantiner.

Also we could think about cooperation with both the e2fsprogs mantiner and
initrd-tools maintainer to define another "magic" number to go into
proc/sys/kernel/real-root-dev to protect other blocks of code. By looking
on google at nfsroot howto's I think that if one was to rdev a kernel to
use nfsroot the device would have major=0 minor=255 so I  think the "magic
number" should therefor be "255".

This would mean a small patch towards the end of /sbin/init to chage the
code to:

if [ $rootdev != 256 ]; then
    if [ $rootdev != 255 ]; then
        mount_root
    fi
        cd mnt
        [ $DEVFS ] && mount -nt devfs devfs dev
        pivot_root . initrd
fi

And the ext3-add-journal.sh code could be changed to:

if [ $rootdev != 256 ]; then
    if [ $rootdev != 255 ]; then
	#main body of code unchanged
    fi
fi

Please provide some feedback on these ideas... I need to fix this problem
for work so it would be nice to provide patches back to Debian at the same
time!

Particularly any comments on the major/minor device codes for nfs root
would be great!

Thanks
Alex Owen