Description of problem: When /etc/mtab is a symbolic link to /proc/mounts, an umount of a gfs filesystem gives bogus error message: /sbin/umount.gfs: file system mounted on /mnt/test not found in mtab Version-Release number of selected component (if applicable): umount.gfs2 0.1.30 (built Jul 20 2007 14:19:37) How reproducible: Always Steps to Reproduce: 1. Create symlink of /proc/mounts to /etc/mtab 2. mount a gfs filesystem 3. umount the filesystem Actual results: mount -v /dev/vg_test/lv_test /mnt/test/ mount: you didn't specify a filesystem type for /dev/vg_test/lv_test I will try type gfs /sbin/mount.gfs: mount /dev/mapper/vg_test-lv_test /mnt/test /sbin/mount.gfs: parse_opts: opts = "rw" /sbin/mount.gfs: clear flag 1 for "rw", flags = 0 /sbin/mount.gfs: parse_opts: flags = 0 /sbin/mount.gfs: parse_opts: extra = "" /sbin/mount.gfs: parse_opts: hostdata = "" /sbin/mount.gfs: parse_opts: lockproto = "" /sbin/mount.gfs: parse_opts: locktable = "" /sbin/mount.gfs: message to gfs_controld: asking to join mountgroup: /sbin/mount.gfs: write "join /mnt/test gfs lock_dlm clurhel5:test rw /dev/mapper/vg_test-lv_test" /sbin/mount.gfs: message from gfs_controld: response to join request: /sbin/mount.gfs: lock_dlm_join: read "0" /sbin/mount.gfs: message from gfs_controld: mount options: /sbin/mount.gfs: lock_dlm_join: read "hostdata=jid=0:id=458754:first=1" /sbin/mount.gfs: lock_dlm_join: hostdata: "hostdata=jid=0:id=458754:first=1" /sbin/mount.gfs: lock_dlm_join: extra_plus: "hostdata=jid=0:id=458754:first=1" /sbin/mount.gfs: mount(2) ok /sbin/mount.gfs: lock_dlm_mount_result: write "mount_result /mnt/test gfs 0" /sbin/mount.gfs: read_proc_mounts: device = "/dev/mapper/vg_test-lv_test" /sbin/mount.gfs: read_proc_mounts: opts = "rw,hostdata=jid=0:id=458754:first=1" umount -v /mnt/test/ /sbin/umount.gfs: umount /mnt/test /sbin/umount.gfs: read_proc_mounts: device = "/dev/mapper/vg_test-lv_test" /sbin/umount.gfs: read_proc_mounts: opts = "rw,hostdata=jid=0:id=458754:first=1" /sbin/umount.gfs: parse_opts: opts = "rw,hostdata=jid=0:id=458754:first=1" /sbin/umount.gfs: clear flag 1 for "rw", flags = 0 /sbin/umount.gfs: parse_opts: flags = 0 /sbin/umount.gfs: parse_opts: extra = "" /sbin/umount.gfs: parse_opts: hostdata = "hostdata=jid=0:id=458754:first=1" /sbin/umount.gfs: parse_opts: lockproto = "" /sbin/umount.gfs: parse_opts: locktable = "" /sbin/umount.gfs: message to gfs_controld: asking to leave mountgroup: /sbin/umount.gfs: lock_dlm_leave: write "leave /mnt/test gfs 0" /sbin/umount.gfs: message from gfs_controld: response to leave request: /sbin/umount.gfs: lock_dlm_leave: read "0" /sbin/umount.gfs: file system mounted on /mnt/test not found in mtab Expected results: Ten umount command should not try to move around /etc/mtab.tmp to /etc/mtab when /etc/mtab is a symlink to /proc/mounts. No error should be given. Additional info: The link of /proc/mounts to /etc/mtab is needed to build a sharedroot cluster. For additional info see http://www.open-sharedroot.org
I did some analysis of the gfs2 mount tools and noticed, that /etc/mtab is recognized as a link to /proc/mounts (mtab.c:ignore_mtab). Nevertheless, this information is not fully respected in mtab:add_mtab_entry and mtab:del_mtab_entry. I attached a small patch as a proposal to solve this issue.
Created attachment 236131 [details] Patch to respect return code of ignore_mtab
Created attachment 294906 [details] patch to solve the issue patch that makes use of ignore_mtab().
commit in master db9e98c6e7f6cf7681a1e6b10d9029214027f8ea commit in RHEL5 e2862bea480908959ebc2bb8c381fc3ddcf721f7
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
rgmanager-2.03.04-1.fc9,gfs2-utils-2.03.04-1.fc9,cman-2.03.04-1.fc9 has been submitted as an update for Fedora 9
rgmanager-2.03.04-1.fc9, gfs2-utils-2.03.04-1.fc9, cman-2.03.04-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rgmanager gfs2-utils cman'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5243
rgmanager-2.03.04-1.fc9, gfs2-utils-2.03.04-1.fc9, cman-2.03.04-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0059.html