Bug 52299
Summary: | root ext3 file system is mounted as ext2 but mount reports ext3 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Nick Simicich <njs> |
Component: | mount | Assignee: | Bernhard Rosenkraenzer <bero> |
Status: | CLOSED DEFERRED | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | aja |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-06-03 19:25:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Nick Simicich
2001-08-22 16:31:15 UTC
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.
|