Hmm, I don't think this is true. While I'm not an initrd user, people
have been doing this with RH for quite some time. Note that it is not
necessarily true that they get it _correct_ all the time, but eventually
it works. Apparently you need to explicitly specify the root filesystem
type for the initrd mount.
Note that I haven't seen the patch in question yet (mirrors don't have
it), but somehow I don't think that changing the order of the
registration is going to help. If they have both ext2 and ext3 as
modules, and insmod ext3 first and ext2 second, you've just broken
their setup. Similarly, (depending on how it is done) I imagine this
would break kernels that have both ext3 and ext2 compiled in.
The only reasonable solution is to not guess at the root filesystem type
and mount it with the correct type explicitly. I think the RH mkinitrd
will check /etc/filesystems for the root fs and use the type there. If
the user forgets to run mkinitrd after changing their kernel, there is
not much you can do about that.
What _may_ be helpful is if ext2 printed a small warning that it is
mounting a filesystem with a journal as ext2 and no journaling will
be done, if the user really wanted to do that (normally they will not).
This will at least alert some users that their root filesystem is not
being mounted as ext3 and eliminate a number of support requests on
ext2-devel when initrd users are wondering why e2fsck is being run on
their supposedly journaled filesystem. The fact that "mount" output
shows ext3 as the filesystem type (while 'cat /proc/mounts' shows ext2)
does nothing to help the user figure out what is wrong.
Cheers, Andreas
-- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/