When mount is invoked without the -t option, it attempts to identify the filesystem type of the device by querying the superblock. If this fails, it parses the /etc/filesystems config and then (if configured) the /proc/filesystems file. I have a subtly broken filesystem which mounts correctly using 'mount -t reiserfs' but fails with 'mount: you must specify the filesystem type' if the -t option is not specified. (util-linux version) sxen2 lv_backup # mount -V mount from util-linux-ng 2.16.1 (with libblkid support) (mount without -t specified) sxen2 lv_backup # mount -vvvv -t auto /dev/mapper/vgxen-cocsp2_backup /mnt/lv_backup/ mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/mapper/vgxen-cocsp2_backup" mount: node: "/mnt/lv_backup/" mount: types: "auto" mount: opts: "(null)" mount: you didn't specify a filesystem type for /dev/mapper/vgxen-cocsp2_backup I will try all types mentioned in /etc/filesystems or /proc/filesystems Trying # mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "#", mountflags: -1058209792, data: (null) Trying #vfat mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "#vfat", mountflags: -1058209792, data: (null) mount: you must specify the filesystem type (mount with -t option specified) sxen2 mnt # mount -vvvv -t reiserfs /dev/mapper/vgxen-cocsp2_backup /mnt/lv_backup/ mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/mapper/vgxen-cocsp2_backup" mount: node: "/mnt/lv_backup/" mount: types: "reiserfs" mount: opts: "(null)" mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "reiserfs", mountflags: -1058209792, data: (null) /dev/mapper/vgxen-cocsp2_backup on /mnt/lv_backup type reiserfs (rw) On closer examination, the mount command seems to be incorrectly parsing the /etc/filesystems file, acting only on lines beginning with # and ignoring lines that are not commented out. This behavior can be seen in this example; (/etc/filesystems) # /etc/filesystems # reiserfs ext3 ext2 # * (mount without the -t option) sxen2 mnt # mount -vvvv /dev/mapper/vgxen-cocsp2_backup /mnt/lv_backup/ mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/mapper/vgxen-cocsp2_backup" mount: node: "/mnt/lv_backup/" mount: types: "(null)" mount: opts: "(null)" mount: you didn't specify a filesystem type for /dev/mapper/vgxen-cocsp2_backup I will try all types mentioned in /etc/filesystems or /proc/filesystems Trying # mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "#", mountflags: -1058209792, data: (null) mount: you must specify the filesystem type NOTE: the '*' at the end of the file is present to cause mount to then parse the /proc/filesystems file to find other possible filesystem types to attempt. This issue is 100% repeatable, but has only been tested on an AMD64 platform and with the stated version of util-linux-ng (2.16.1). This behavior will seemingly only occur when a filesystem is broken in such a way as to make identification of the filesystem type impossible via standard methods.
the issue is that the fs was probed (detected) and so mount didnt bother trying to mount it again based on the filesystem list. since your fs is corrupted enough that the probe logic detected that it was reiserfs, that entry was skipped in /proc/filesystems. ive sent an e-mail upstream about it.
can you run `BLKID_DEBUG=0xffff mount ...` and post the output please
(In reply to comment #2) > can you run `BLKID_DEBUG=0xffff mount ...` and post the output please > sxen2 ~ # BLKID_DEBUG=0xffff mount -vvvv /dev/vgxen/cocsp2_backup /mnt/lv_backup/ mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/mapper/vgxen-cocsp2_backup" mount: node: "/mnt/lv_backup/" mount: types: "(null)" mount: opts: "(null)" libblkid: debug mask set to 0xffff. reseting blkid_probe ready for low-probing, offset=0, size=42949672960 --> starting probing loop [idx=-1] linux_raid_member: call probefunc() ddf_raid_member: call probefunc() isw_raid_member: call probefunc() lsi_mega_raid_member: call probefunc() via_raid_member: call probefunc() silicon_medley_raid_member: call probefunc() nvidia_raid_member: call probefunc() promise_fasttrack_raid_member: call probefunc() highpoint_raid_member: call probefunc() adaptec_raid_member: call probefunc() jmicron_raid_member: call probefunc() swap: magic sboff=4086, kboff=0 swap: call probefunc() assigning UUID assigning TYPE <-- leaving probing loop (type=swap) [idx=18] --> starting probing loop [idx=18] reiserfs: magic sboff=52, kboff=64 reiserfs: call probefunc() assigning UUID assigning TYPE <-- leaving probing loop (type=reiserfs) [idx=25] --> starting probing loop [idx=25] ufs: call probefunc() sysv: call probefunc() <-- leaving probing loop (failed) [idx=49] ERROR: ambivalent result detected (2 filesystems)! mount: you didn't specify a filesystem type for /dev/mapper/vgxen-cocsp2_backup I will try all types mentioned in /etc/filesystems or /proc/filesystems Trying # mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "#", mountflags: -1058209792, data: (null) mount: you must specify the filesystem type
Just to try to keep the bug somewhat on track, the original problem is the behavior of `mount` when it's unable to determine the FS type for whatever reason. I think this might show what I mean slightly better; ----- mount: you didn't specify a filesystem type for /dev/mapper/vgxen-cocsp2_backup I will try all types mentioned in /etc/filesystems or /proc/filesystems Trying # mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "#", mountflags: -1058209792, data: (null) Trying #cheesefs mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: "/mnt/lv_backup/", filesystemtype: "#cheesefs", mountflags: -1058209792, data: (null) mount: you must specify the filesystem type sxen2 ~ # cat /etc/filesystems # /etc/filesystems # reiserfs ext3 ext2 #cheesefs # * ----- `mount` is only attempted to mount filesystems using entries from the /etc/filesystems file that begin with a '#' character (ie comments). It's ignoring the wanted lines from the file.
(In reply to comment #4) > Just to try to keep the bug somewhat on track, the original problem is the > behavior of `mount` when it's unable to determine the FS type for whatever > reason. I think this might show what I mean slightly better; > > ----- > mount: you didn't specify a filesystem type for /dev/mapper/vgxen-cocsp2_backup > I will try all types mentioned in /etc/filesystems or /proc/filesystems > Trying # > mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: > "/mnt/lv_backup/", filesystemtype: "#", mountflags: -1058209792, data: (null) > Trying #cheesefs > mount: mount(2) syscall: source: "/dev/mapper/vgxen-cocsp2_backup", target: > "/mnt/lv_backup/", filesystemtype: "#cheesefs", mountflags: -1058209792, data: > (null) > mount: you must specify the filesystem type > sxen2 ~ # cat /etc/filesystems > # /etc/filesystems > # > reiserfs > ext3 > ext2 > #cheesefs > # > * > ----- > > `mount` is only attempted to mount filesystems using entries from the > /etc/filesystems file that begin with a '#' character (ie comments). It's > ignoring the wanted lines from the file. > Re-read (and understood!) this time Comment #1. Please ignore my last comment. It's clearly ignoring the "wanted lines" from that file because it's already probed for those fs types and decided it isn't any of them (although it's actually two of them, somehow!)
pretty sure this should be fixed in at least util-linux-2.19+ now
