The point of bug 52299 is that mount output is inconsistent.  I have submitted 
52303 which is substantially identical but is against the kernel component 
about the risk of data loss when an ext3 filesystem is downgraded to ext2 on 
boot because of the lack of an initrd.

mount just displays the content of /etc/mtab...
What does that have?
By any chance, did you mount the filesystem as ext2, then remount the 
filesystem as ext3 while / (and thereby /etc) was mounted read-only?

Everything was done exactly as specified in /etc/rc.d/rc.sysinit, the
unmodified supplied one. As I understand it, the order of happenstance (you can 
probably read /etc/rc.d/rc.sysinit yourself to get more detail) was:

Root was mounted ro.  It was an ext3 filesystem, but there was no initrd set up
by the install.  So it was mounted ext2.

Then an fsck was done.

Then the filesystem was noted to be clean.

Then rc.sysinit does a mount -n -o remount,rw /

I don't *think* that this will allow the file system type to change.  However, 
I have no idea how mount later determines the file system type.  But this will 
not update mtab.  That is OK because the next significant step is to clear 
mtab, now that the root filesystem is mountable.

>/etc/mtab

Then it "removes stale backups"

rm -f /etc/mtab~ /etc/mtab~~

Then it does a 

mount -f /

To update /etc/mtab with root's information.  It also does some more mount -f's.

So if all mount does is to display /etc/mtab, then the "mount -f /" command is 
claiming that / is using ext3, when /proc/mounts is noting that it is ext2. 

Now mount -f says it "fakes a mount" doing everything but actually mounting, 
including updating mtab. I presume that this goes through and maybe it actually 
determines that this is an ext3 filesystem, and that the ext3 module is now 
available.  If so, this is probably the wrong thing to do.  

So "Did you remount..."?  In a way, but I just used the supplied redhat script.

I guess you can argue as to whether mount is operating more correctly than the 
sysinit script.  The -f being used to rebuild the /etc/mtab file is 
traditionally an important part of what mount does.  Is it more correct for it 
to put a ext3 mount type in mtab in this case since that is what it would do?  
Or should it put an ext2 type in if it is not, in fact, actually going to do 
the mount, since the main use for this function is to rebuild mtab?

If mount is correct, than rc.sysinit needs to do something else to build mtab.  

cat /proc/mounts > /etc/mtab

instead of doing all that other initialization at that point?  How does it 
fix /dev/root to be /dev/hda2 or whatever?

If you think it is an rc.sysinit problem, please change the component and 
reassign it to them.  If you think it should be a mount problem, I guess you 
need to fix it.

Here is a suggestion for fixing this in /etc/rc.sysinit as part of 
rebuilding /etc/mtab, if it is decided that the mount command is actually 
broken-as-designed.  My presumption is that you could cp /proc/mounts 
to /etc/mtab except that /proc/mounts identifies the root device as /dev/root, 
and that refers to a non-existent file.  So you need mount to give you the 
correct root device name, and everything else should come out /proc/mounts.

1.  proceed with the current reconstruction of mtab up to mount -f /
    You have to do this to get the real mount device.  If there is another
    way to get that device in /etc/rc.sysinit, you could do that instead, 
    but I don't think it is already around.
    You can't just grep it out of /etc/fstab anymore, since it may be 
    specified by label.  I think that mount has to be used to extract the 
    real root device since it may be by label or device and mount will sort
    that out.

2.  Use awk to construct the /etc/mtab from the /etc/mtab and /proc/mounts
    making the changes as required:

awk 'BEGIN { getline <"/etc/mtab";close("/etc/mtab");  BB = $1};  /\/dev\/root/ 
{sub(/\/dev\/root/,BB,$0)}; {print $0 > "/etc/mtab"};
END {close("/etc/mtab")}' /proc/mounts

The only other difference is that /proc/mounts identifies the device of 
the /proc pseudo filesystem as /proc and /etc/mtab identifies it as none. You 
could fix that as well, if that is important:

awk 'BEGIN { getline <"/etc/mtab";close("/etc/mtab"); BB = $1};  
/^\/dev\/root/ {sub(/\/dev\/root/,BB,$0)}; /^\/proc/ {sub(/\/proc/,"none")} 
{print $0 > "/etc/mtab"}; END {close("/etc/mtab")}' /proc/mounts

Note that the awk commands are all on one virtual line because they are in a 
single '' delimited string.  At this point, I think you can leave out the other 
mount -f's and skip the rest of the mtab reconstruction.  It should all be in a 
format that is completely useful by the mount command.

I did this manually on a running system, to construct a new /etc/mtab and 
compared it against the original (stored as /etc/mtab.save).  It seemed to be 
fine.  It was missing extended options as shown below.  Automount is not an 
issue since it is not started until after the mtab is reconstructed, 
and /dev/pts is also mounted later, so I think that this will be transparent, 
and get everything right.

[root@parrot root]# diff -u /etc/mtab /etc/mtab.save
--- /etc/mtab   Fri Aug 24 13:24:39 2001
+++ /etc/mtab.save      Wed Aug 22 11:59:35 2001
@@ -7,7 +7,7 @@
 /dev/hda9 /tmp ext3 rw 0 0
 /dev/hda7 /usr/local ext3 rw 0 0
 none /dev/shm tmpfs rw 0 0
-none /dev/pts devpts rw 0 0
+none /dev/pts devpts rw,gid=5,mode=620 0 0
 /dev/hda8 /mnt/temp ext3 rw 0 0
-automount(pid905) /misc autofs rw 0 0
+automount(pid905) /misc autofs rw,fd=5,pgrp=905,minproto=2,maxproto=3 0 0
 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
[root@parrot root]#

*** Bug 52634 has been marked as a duplicate of this bug. ***

Ran into a problem that was similar enough to this that I think it's the same
bug, but is different enough that it might give you more info.
I replaced (not upgraded) a 7.1 install on a Thinkpad T22, and reformatted (not
migrated) my two partitions as ext3 (they were ext2).  Upon booting, the
partitions were mounted as ext2.  I umounted the non-root partition and
remounted it, and it came up ext3.  I then made and installed a new initrd, and
when I rebooted the partitions came up ext3.  The initrd turned out to be a red
herring, though, because the contents of the two ramdisks were identical (except
for timestamps), and when I switched back to the old one, the partitions still
came up ext3.  In /var/log/messages I can see that the order in which things
happened was different for the first boot than for others; I can post a log if
necessary.  This problem may also be related to the one reported in bug 52127,
because I would sometimes get that error instead (again, when using an ext3
filesystem, so it shouldn't have to run e2fsck in the first place).

Basically, there's no easy way for the kernel to tell mount that the mount succeeded with a 
different fstype, and it may not be worth fixing since it's arguably cosmetic. Patches 
anyone?

I strongly disagree that this is cosmetic - it can cause data loss if someone 
thinks that they are using ext3, say with full data journaling, and they are 
actually using ext2. 

If this is a cosmetic bug, then it would be a cosmetic bug if bc said that 1+1 
was 3, because we know that 1+1 is 2.

This also has nothing to do with mount succeeding with a different filesystem 
type.  The remounts that are done change flags, but I strongly believe that a 
specified filesystem type is ignored on such a mount.  Example:

[root@parrot root]# mount  -o rw   -t ext3   /dev/hda5 /mnt/hda5
[root@parrot root]# mount  -o ro,remount   -t whoops   /dev/hda5 /mnt/hda5
[root@parrot root]# mount | grep hda5
/dev/hda5 on /mnt/hda5 type ext3 (ro)
[root@parrot root]#  umount /mnt/hda5
[root@parrot root]# umount /mnt/hda5
umount: /dev/hda5: not mounted
[root@parrot root]# mount  -o rw -n  -t ext3   /dev/hda5 /mnt/hda5
[root@parrot root]# mount | grep hda5
[root@parrot root]# mount  -o ro,remount -n -t whoops   /dev/hda5 /mnt/hda5
[root@parrot root]# mount | grep hda5
[root@parrot root]#

Running strace on the last command leads to this significant line:

mount("/dev/hda5", "/mnt/hda5", "whoops", MS_RDONLY|MS_REMOUNT|0xc0ed0000, 
0x805a0
80) = 0

Yes - it makes the mount(2) call and uses "whoops" as the filesystem type, with 
no complaints from the kernel, since it is just resetting a flag.

The problem is actually that "mount -f /" uses the type that is specified on 
the line from /etc/fstab, without checking it.  If it checked it, then this 
would not be a problem.

Is that a bug?  I think so, when there is a better source of information.

The other point is that this keeps being rediscovered.  It has been 
rediscovered by members of the local user's group in South Florida.  At least 
one bug has been closed that was a duplicate of this one.  Other people have 
added to this bug because they believe that they have similar problems.

It doesn't work well the way it is.  Given that there are people who have NEVER 
discovered this bug (I'm willing to bet, although there is no way to prove it) 
who have done the conversion and who have the problem that the filesystem is 
not being mounted correctly, and who probably think that they have a journal 
protected root and figuring that it is just a bug because they get fsck run 
on / when they don't expect it, and they don't know about /proc/mounts so they 
have no way of checking it, I believe that it is more serious than we might 
think.

There are a couple of issues here:

1.  It has been asserted that the mount command can be fed one filesystem type, 
but it will mount another filesystem type, and post the wrong type 
in /etc/mtab.  It should look in /proc/mounts, if available, to see what the 
actual status of mount is.  That is one general bug, but not the actual problem 
here.  Furthermore, I am not sure that this is a possibility - once mount 
commands are being issued, root is mounted, and the modules library is 
somewhere. Finally, I do not believe that this can happen, except during boot:

[For this example, I made /dev/hda5 without a journal.]

[root@parrot root]# mount  -o rw   -t ext3   /dev/hda5 /mnt/hda5
mount: wrong fs type, bad option, bad superblock on /dev/hda5,
       or too many mounted file systems
[root@parrot root]# mount  -o rw   -t ext2   /dev/hda5 /mnt/hda5
[root@parrot root]#

mount("/dev/hda5", "/mnt/hda5", "ext3", 0xc0ed0000, 0x805a080) = -1 EINVAL 
(Invalid argument) -- this is the critical line - you can't specify ext3 to the 
kernel, unless you have a journal.  There is no chance of getting this wrong.

2.  That the -f option uses the information from /etc/fstab to determine how 
the filesystem might be mounted, but that is indeterminate and wrong, 
specifically in the case where the type can be changed by the kernel, but 
perhaps in any case where one type is used to mount the / filesystem, but 
another type is used for the mount.  It should use /proc/mounts instead.  (If 
the filesystem type was ext2, but /etc/fstab said msdos, it would probably mark 
the root filesystem as msdos.)

If you read through the description, I have already made a suggestion about a 
patch, but that is to the initialization scripts.  It is arguably broken that 
you can ask the kernel for an ext3 mount and get an ext2 mount. It is arguably 
broken that the Redhat initialization scripts allow this - if the default 
filesystem type is ext3, why is that not in the kernel, as opposed to being in 
a module (that would fix it as well). The right place to do compatibility would 
have been in the mount command -- if you ask for an ext3 mount, the mount(2) 
call fails, and you then do the ext2 mount in mount(8).

There is a typo in my "steps to reproduce", it should be "convert the 
filesystem to ext3".

Arguably:

The error in the sysinit scripts was caused because "mount -f /" used the 
information out of /etc/fstab to determine how the / filesystem was mounted 
during the rebuild of /etc/fstab, RATHER than consulting /proc/mounts.

-f says that it fakes the mount by doing everything but the actual mount, and 
it updates mtab (if -v is not used).  The only point of doing this is to 
rebuild mtab on boot.  Arguably, this is a misuse of the mount command by the 
boot scripts.  They could fix this by extracting the filesystem type of / 
from /proc/mounts (this is actually already done)....this might be as simple as 
changing 

mount -f /

to

mount -f -t $ROOTFSTYPE /dev/root /

in /etc/rc.sysinit.  Note, this might also require that the setting line be 
changed to:
ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ type=$3 };END {print type}'`

This is because there is now a line that reads:

ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ print $3 }'`

But at least on my system, with the latest kernels, 

[root@parrot root]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
/proc /proc proc rw 0 0
[.....]

It would be possible, I guess, to get the actual device, although I am not sure 
how, it would require that you parse /etc/fstab.  You would have to determine 
whether a label was being used to indirectly refer to root, or whether an 
absolute device was being used.  Then you could pass that (and the actual 
arguments) to the mount command so that it could build the command correctly.

I have no idea why I have two lines for / with "rootfs" as the type for the 
first one...and neither one having the correct device name for /.  I have 
no /dev/root in any case.

This makes my earlier suggestion look better...although I might also want to 
remove the rootfs line from the built /etc/mtab.

Anyway, the code that uses awk to (incorrectly) extract the type of the root 
filesystem is executed unconditionally earlier in the initialization, before 
root is fscked.  I do not believe that it is possible to remount root and 
change the mount type, (this may be part of what we are discovering) so it 
should be safe to use this to override whatever is in /etc/fstab when it runs.

By the way:

[/dev/hda5 now has a journal]

mount  -o rw -f  -t whoops   /dev/hda5 /mnt/hda5
/dev/hda5 on /mnt/hda5 type whoops (rw)

I could specify anything on the mount command, or in /etc/fstab.  That has no 
relationship to what the kernel filesystem has done...in fact, (I have not 
tested this, as I have no victim system currently), but I see no reason why I 
could not specify some totally different filesystem.  The rules for the first 
mount of / are somewhat different, no?  

Also, the filesystem type is ignored when one is using -o remount to change 
flags.  I just tested it, and that is the case.  I can shift an ext3 filesystem 
to rw or ro with -t whoops or no -t clause.  

My point is that either the -t clause specified to a -f should be ignored -- 
the filesystem type should be determined from /proc if possible, or there 
should be a big warning in the mount man page that -f does not edit the type 
specified in the -t clause or fstab for validity and that using "mount -f /" to 
rebuild mtab without determining the actual mounted filesystem type is a 
mistake. Another alternative is to write "unknown" if you do not know it, 
rather than looking up and trusting what you get from /etc/fstab.

I can develop a patch for the mount command, tell me what level to patch 
against.  But I am not going to bother unless I have a reasonable belief that 
the patch will be accepted.  And before that, someone needs to determine 
whether the mount command is "working as designed" and being misused by the 
initialization scripts, or whether it is incorrect output for the mount command 
to report the wrong filesystem type.  My request has been for someone to make 
that determination and to either fix mount or to reassign this to 
initialization scripts so that they can make one or another of the simple fixes 
that they might make, as a bypass.

/proc is available very early in initialization.  If anyone runs a mount 
and /proc is not mounted, and they have not specified -n, then you can print a 
warning message.

This bug has sat open for a very good time.  While I am happy that there is 
something happening, I am bothered that it has sat there for this long.  I wish 
someone would address 52303 (which is the problem where ext3 is not in the 
kernel, with this same symptom).

The final point I would make is that, since you can't mount an ext2 filesystem 
as type ext3 other than at boot, it might be right to change it 
in /etc/rc.d/rc.sysinit.  This may well be a Linux unique issue, caused by a 
configuration decision Redhat made (put the ext3 in a module, even though it is 
the default) and thus fixing it in Redhat configuration might be the right 
decision.

But if that is the case, this bug needs to be sent to the right component.

A new version of a suggested change to rc.sysinit:

Change ROOTFSTYPE setting to:

ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ type=$3 };END {print type}'`

Change setting of mtab to:

if [ .$ROOTFSTYPE = . ]; then
echo Please verify that "mount" shows the correct filesystem type by comparing 
it to what is shown for /dev/root in /proc/mounts.
mount -f /
else
mount -f /
ROOTDEV=`awk '{print $1; exit}' < /etc/mtab`
# Clear mtab again so that a complete mount command can be specified.
>/etc/mtab
mount -f -t "$ROOTFSTYPE" "$ROOTDEV" /
fi

This allows mount to determine the device for root using the current scheme, 
which could be label, fixed device, or some yet unspecified scheme.  That 
device is then extracted from mtab, and used with the file system type from the 
earlier extraction.  This seems to fix the issue.  Preserving the flags 
in /etc/fstab seems to be meaningless.