Your message dated Wed, 12 May 2010 12:33:32 -0400
with message-id <[email protected]>
and subject line Re: Bug#580726: e2fsprogs: fsck ignores -t fstype argument
has caused the Debian Bug report #580726,
regarding e2fsprogs: fsck ignores -t fstype argument
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
580726: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580726
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: e2fsprogs
Version: 1.41.3-1
Severity: important
Under unclear circumstances fsck ignores the -t fstype argument, and
instead runs the fsck for a filesystem type of its own choosing. It
looks from strace as if it's examining the superblock and assuming it
understands what it sees.
First, create an ext2fs image:
# mkdir /tmp/test
# cd /tmp/test
# dd if=/dev/zero of=image bs=4096 count=1024
# mke2fs image
Now run fsck on it:
# fsck -V -text2 /tmp/test/image
fsck 1.41.3 (12-Oct-2008)
[/sbin/fsck.ext2 (1) -- /tmp/test/image] fsck.ext2 /tmp/test/image
e2fsck 1.41.3 (12-Oct-2008)
ext2fs_check_if_mount: No such file or directory while determining whether
/tmp/test/image is mounted.
/tmp/test/image: clean, 11/1024 files, 162/4096 blocks
Now try to run fsck.myfs on it:
# fsck -V -tmyfs /tmp/test/image
fsck 1.41.3 (12-Oct-2008)
[/sbin/fsck.ext2 (1) -- /tmp/test/image] fsck.ext2 /tmp/test/image
e2fsck 1.41.3 (12-Oct-2008)
ext2fs_check_if_mount: No such file or directory while determining whether
/tmp/test/image is mounted.
/tmp/test/image: clean, 11/1024 files, 162/4096 blocks
Note that it ignores what you say and runs fsck.ext2.
For an unknown image it will cheerfully run fsck.myfs:
# fsck -V -tmyfs /nonexistent
fsck 1.41.3 (12-Oct-2008)
[/usr/local/sbin/fsck.myfs (1) -- /nonexistent] fsck.myfs /nonexistent
/usr/local/sbin/fsck.myfs: /nonexistent
where I've created /usr/local/sbin/fsck.myfs containing the following:
#!/bin/sh
echo "$0: $@"
exit 0
but for an image it can get its hands on it feels it ought to override
what the sysadmin says.
This behavior is at variance with the behavior documented in the man
page, too.
(Note however that it does appear to honor the type in fstab, if any,
over whatever it decides on its own, as well as over what appears on
the command line.)
A type passed on the commandline should certainly override whatever
internal logic or knowledge fsck should have. Furthermore, if a type
is both passed on the commandline and found in fstab, it should
preferably be an error for them not to match. And ideally, knowledge
of superblock magic numbers and whatnot should be taken out of fsck
entirely, or if there must be a probe it should be done in some more
extensible fashion.
The case I've hit, in which fsck's private opinion of the fs type is
catastrophically wrong, is a layered fs on top of ext3 that needs its
own fsck.mumble. This fsck.mumble first runs fsck.ext3 and then does
its own (nontrivial) stuff on top. Currently, the master fsck silently
fails to run it if the volume isn't in fstab, which is often the case
for research/test fses. This results in system crashes and data loss
if the user doesn't notice.
It's also not *that* hard to imagine that it might accidentally
interpret some other random fs type as an ext3 or ext2 volume,
depending on how robust the probe really is, and that would make a
huge mess too.
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages e2fsprogs depends on:
ii e2fslibs 1.41.3-1 ext2 filesystem libraries
ii libblkid1 1.41.3-1 block device id library
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii libcomerr2 1.41.3-1 common error description library
ii libss2 1.41.3-1 command-line interface parsing lib
ii libuuid1 1.41.3-1 universally unique id library
e2fsprogs recommends no packages.
Versions of packages e2fsprogs suggests:
pn e2fsck-static <none> (no description available)
pn gpart <none> (no description available)
pn parted <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
On Fri, May 07, 2010 at 10:49:21PM -0400, David Holland wrote:
>
> Under unclear circumstances fsck ignores the -t fstype argument, and
> instead runs the fsck for a filesystem type of its own choosing. It
> looks from strace as if it's examining the superblock and assuming it
> understands what it sees.
This is NOTABUG. Read the man page for fsck; it very clearly
describes what -t does, and it doesn't do what you think it does.
If you explicitly what to use a specific fsck, such as fsck.myfs, then
call it explicitly:
/sbin/fsck.myfs /tmp/test/image
There's no reason to use the fsck front-end if you want to hardcode a
certain fs-specific fsck. There's no value add to use fsck the way
you want to use it.
- Ted
--- End Message ---
