search for: root_mount_data

...filesystem is going to want to use rootflags to have one of it's options passed in which will be unknown to ext3. We don't really want ext3 to fail to mount the filesystem in that case right? Or is there something about the option passing that I am missing? Also there is a bug in passing root_mount_data to read_super() directly. It seems that some filesystems (ext3 included!) such as isofs that want to modify that data by putting a null between option/value pairs (overwriting the '='). The problem of course is that if that option/value pair is for another filesystem type, to be evaluated...

...@@ +#!/bin/sh -e +export COL="" + +# These should be passed from the kernel via the environment +# (because eventually the kernel won't recognise them) For +# now, we hard code them here. +devfs= +#init=/bin/sh +load_ramdisk=1 +prompt_ramdisk=0 +root=/dev/mtdblock3 +rootfstype=ext2 +root_mount_data= + +# Make directory for root filesystem mount +mkdir -p /root + +if [ -n "$load_ramdisk" ]; then + export prompt_ramdisk + /scripts/load_ramdisk $root /dev/ram1 "root " && root=/dev/ram1 +fi + +if [ -n "$root" ]; then + # Mount the root filesystem + echo -...

...tk" statements in kernel's "init/do_mounts.c" and "init/do_mounts_initrd.c". I found out that in function "void __init mount_block_root(char *name, int flags)" of "init/do_mounts.c" there is the statement ... int err = do_mount_root(name, p, flags, root_mount_data); ... The value of "name" is "/dev/root" before this statement. After this "err" is -6 ("No such device or address"). The next lines are: ... /* * Allow the user to distinguish between failed sys_open *...