Bug 666152

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).