From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Description of problem:
The root filesystem gets mounted as ext2 if you do not have a initrd,
given that the standard redhat kernel is built with ext3 as a module.
But running the "mount" command with no options reports that the
/ filesystem is mounted as ext3.
Doing "cat /proc/mounts" shows that the filesystem is mounted as
ext2.
I suspect that "cat /proc/mounts" is actually correct.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1. Use a kernel, such as the one built for the current red hat beta, which
does not have ext2 built in.
2. Convert / to ext2 manually with tune2fs.
3. Boot the system without an initrd.
4. run the mount command and look at the output
5. Run the command "cat /proc/mounts"
Actual Results: the output from mount showed that / was mounted with ext3.
The output from "cat /proc/mounts" showed that "/dev/root /" was mounted
rw ext2.
Expected Results: The mount command should show the same thing as
cat /proc/mounts
Additional info:
I guess that I find it odd that the new default filesystem is
built on the kernel as a module, such that either an initrd is
required or you lose the extra reliability of mounting the / filesystem as
ext3. But doing that would have concealed this bug.
I might categorize this as "easy workaround" except for the possibilty of
data loss in the case of someone who thinks that they
have an ext3 filesystem and so take actions that they would normally only
take with a journaled filesystem (hitting reset as opposed to doing
everything in their power to sync/umount), when actually they have an ext2
filesystem and they lose data. I guess that if I had converted any
filesystems that there might have been an initrd set up for me
automatically.
I've been working with Unix for so long that doing a "cat /proc/mounts" is
kind of foreign - I would not have done it except for a document posted to
the Roswell beta list. Heck, Linux didn't even have a proc flesystem when
I started playing with it. I think that most people will use the output
of "mount" to determine that they are successfully mounting their / as
ext3 and will not know to install the initrd unless mount reports
correctly. (or maybe the cat /proc/mounts command is reporting incorrectly
because the remount is not updating where it looks - in which case the
point of this bug changes to "why is ext3 not compiled in the kernel so
that my carefully kept journal is being ignored?")

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]#

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).

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.

Note

You need to
log in
before you can comment on or make changes to this bug.