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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
