Description of problem: The output from mount and df have multiple redundant entries, making the output hard to parse. Version-Release number of selected component (if applicable): systemd.x86_64 15-1.fc15 How reproducible: Always Steps to Reproduce: 1. Install Rawhide 2. run df -h Actual results: $ df -h Filsystem Storlek Anvnt Tillg Anv% Monterat på /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home /dev/mapper/vg_ferra-lv_root 50G 5,7G 44G 12% / /dev/sda3 464M 53M 388M 12% /boot /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home /dev/sda3 464M 53M 388M 12% /boot /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home Expected results: $ df -h Filsystem Storlek Anvnt Tillg Anv% Monterat på /dev/mapper/vg_ferra-lv_home 173G 17G 148G 11% /home /dev/mapper/vg_ferra-lv_root 50G 5,7G 44G 12% / /dev/sda3 464M 53M 388M 12% /boot Additional info: I hope I choosed the right component, as systemd seems to be the component handling mounting during boot and mtab. /proc/mounts has two identical entries for /dev/mapper/vg_ferra-lv_home but as you can see df -h (and mtab) has even more: $ cat /proc/mounts | grep home /dev/mapper/vg_ferra-lv_home /home ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 gvfs-fuse-daemon /home/xake/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0 $ cat /etc/mtab | grep home /dev/mapper/vg_ferra-lv_home /home ext4 rw 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw 0 0 /home /home none rw,commit=0 0 0 gvfs-fuse-daemon /home/xake/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user=xake 0 0
Yes, happens to me as well.
Yes, systemd does not clean up /etc/mtab anymore, we instead expect it to be a symlink to /proc/self/mounts. In fact, systemd actually warns to kmsg/syslog if this file is not a symlink. We did this to gently put some pressure on Karel to install this symlink by default. He promised this in the F15 timeframe, but this needs some more work. In the meantime please create this symlink manually: ln -sf /proc/self/mounts /etc/mtab Since this is an often reported issue I'll leave it open.
Does not remove all duplicate entries on my computer, still three root (granted, only one of them to /, but still), two identical home entries and two udev: [xake@ferra ~]$ ls -l /etc/mtab lrwxrwxrwx. 1 root root 17 5 jan 10.21 /etc/mtab -> /proc/self/mounts [xake@ferra ~]$ df -h Filsystem Storlek Anvnt Tillg Anv% Monterat på rootfs 50G 6,0G 43G 13% / udev 1,9G 364K 1,9G 1% /dev tmpfs 2,0G 420K 2,0G 1% /dev/shm /dev/mapper/vg_ferra-lv_root 50G 6,0G 43G 13% / udev 1,9G 364K 1,9G 1% /dev tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup tmpfs 2,0G 108K 2,0G 1% /var/run tmpfs 2,0G 0 2,0G 0% /var/lock /dev/sda3 464M 72M 368M 17% /boot /dev/mapper/vg_ferra-lv_home 173G 17G 147G 11% /home /dev/mapper/vg_ferra-lv_root 50G 6,0G 43G 13% /tmp /dev/mapper/vg_ferra-lv_root 50G 6,0G 43G 13% /var/tmp /dev/mapper/vg_ferra-lv_home 173G 17G 147G 11% /home none 2,0G 0 2,0G 0% /lib/bootchart/tmpfs
Can you dump /proc/self/mounts here, please?
$ cat /proc/self/mounts rootfs / rootfs rw 0 0 /proc /proc proc rw,relatime 0 0 /sys /sys sysfs rw,seclabel,relatime 0 0 udev /dev devtmpfs rw,seclabel,nosuid,relatime,size=1986304k,nr_inodes=496576,mode=755 0 0 devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0 /dev/mapper/vg_ferra-lv_root / ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 none /selinux selinuxfs rw,relatime 0 0 udev /dev devtmpfs rw,seclabel,nosuid,relatime,size=1986304k,nr_inodes=496576,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/ns cgroup rw,nosuid,nodev,noexec,relatime,ns 0 0 cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0 cgroup /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/debug autofs rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /dev/hugepages autofs rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/security autofs rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /dev/mqueue autofs rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 tmpfs /var/lock tmpfs rw,rootcontext=system_u:object_r:var_lock_t:s0,seclabel,nosuid,nodev,noexec,relatime,mode=775,gid=54 0 0 tmpfs /var/run tmpfs rw,rootcontext=system_u:object_r:var_run_t:s0,seclabel,nosuid,nodev,noexec,relatime,mode=755 0 0 /dev/sda3 /boot ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0 mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/mapper/vg_ferra-lv_root /tmp ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/mapper/vg_ferra-lv_root /var/tmp ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 none /lib/bootchart/tmpfs tmpfs rw,seclabel,nosuid,noexec,relatime 0 0 gvfs-fuse-daemon /home/xake/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
Hmm, the kernel found two mount points for /home. That is weird: rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/mapper/vg_ferra-lv_home /home ext4 I wonder how that can happen.
(In reply to comment #6) > I wonder how that can happen. I have no idea, I double checked my fstab, but: $ cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Nov 21 19:58:32 2010 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_ferra-lv_root / ext4 defaults 1 1 UUID=f5e8e82d-784e-4e13-819c-d4c7a4c80eb8 /boot ext4 defaults 1 2 /dev/mapper/vg_ferra-lv_home /home ext4 defaults 1 2 /dev/mapper/vg_ferra-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 Anything other that may interfere?
Hm, did you reboot or just create the symlink on a booted system? The double mounts might be caused by confusion at mount time or so.
Was unsure so I rebooted my system. /etc/mtab still a link, /home still duplicated in "df -h".
Hmm, your /proc/self/mounts shows /tmp and /var/tmp mounted from LVM. That is really weird, as it isn't listed in fstab. Do you have any idea where that might come from? Do you have any kind of 3rd party script or so installed that might mount that? I cannot really believe that systemd has anything to do with this.
Have no idea. I have no custom scripts doing any mounting. This system is a Fedora 15 system installed from a nightly LiveCD, with no customizations except in my userprofile, in what packages are installed and that mtab link.
(In reply to comment #10) > Hmm, your /proc/self/mounts shows /tmp and /var/tmp mounted from LVM. That is > really weird, as it isn't listed in fstab. Do you have any idea where that > might come from? Probably a result of: mount --bind /tmp /tmp mount --bind /var/tmp /var/tmp This prevents certain hardlink attacks. Though I don't know what script or component makes these mounts.
(In reply to comment #12) > Though I don't know what script or component makes these mounts. Found it. It's /etc/init.d/sandbox
It also does: for h in $HOMEDIRS; do mount --rbind $h $h || return $? mount --make-private $h || return $? done So this script is the culprit it seems... I have no idea why the script is launched on my system.
(In reply to comment #14) > I have no idea why the script is launched on my system. The package policycoreutils-sandbox enables it. It is installed by default with the base-x comps group.
If i create /etc/mtab as a symlink i found thie error message i my message log. Jan 9 18:06:33 mother kernel: [ 5.656326] systemd-readahead-replay[437]: open(/etc/mtab) failed: Too many levels of symbolic links Is that bad or negligible?
(In reply to comment #16) > If i create /etc/mtab as a symlink i found thie error message i my message log. > > Jan 9 18:06:33 mother kernel: [ 5.656326] systemd-readahead-replay[437]: > open(/etc/mtab) failed: Too many levels of symbolic links > > Is that bad or negligible? Please post here the output of the command ls -l /etc/mtab Thank you
Thx for quick reponse, but the error message is gone away since yesterday! :) I don't know really what's happend. The only thing i remember what i do is, that i have reenable the cgred-dameon. So i think it's no problem for my system to work with a symlink for /etc/mtab. Thank you
Fixed now with Karel's yesterdays util-linux upload.
(In reply to comment #19) > Fixed now with Karel's yesterdays util-linux upload. I guess the fix is the symlink (am having problem in postinst for util-linux), but the fact that "df -h" shows "mount -o bind" posts is a issue going to be ignored? Or is that something that should be filed against the package containing df (and the same for any other packages containing a program that assumes binds are filtered from /etc/mtab)?
Peter, hmm, I am not sure if bind mounts should be filtered from df, but if that should really happen, then yes, please file a bug against df (coreutils).