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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
