0

So, I'm stumped on this one. I have functionally two volume groups. vgold and vgnew, and I migrated the lvms from the old one to the new one (via rsync of the files to an external drive first, not that it matters). After installing the new disk, putting the files in place and (clearly) rebooting:

# mount /dev/vgnew/foo /foo
  [ no errors returned ]
# ls /foo
  [ empty directory still ]
# mount | grep foo
  [ nothing ]
# mount /dev/vgnew/foo /bar
  [ no errors returned ]
# ls /bar
  [ all the files ]

/foo is the previous point point under the old volume group, but it doesn't matter I use to attempt to mount on /foo... Nothing will mount there at all. strace shows that mount() is getting called and returns 0.

/etc/mtab of course doesn't contain anything (being a symlink to kernel's /proc/self/mounts).

This is on a fedora 21 box, FYI. And I have about 10 mount points that are all acting the same way, at different depths of the file system.

------- UPDATE -------

A coworker found a archlinux page where someone had the same problem. Unfortunately, they have no solution there other than to rename things. But they did provide one clue that turned out to be true:

mount /foo && df

shows the mount very very quickly showing up and then going away.

------- UPDATE 2 -------

This stackexchange problem actually comes closest. It shows that my fstab entries (with noauto as the option) is the culprit:

/dev/vgfoo/foo         /foo                   ext4    noauto          1 2

Aftering commenting that out and then doing a systemctl daemon-reload, it actually mounts. But... I still want that line in the fstab so I mount it when I need it (it's on a disk that isn't always online).

So, systemd strikes again...

Wes Hardaker
  • 774
  • 5
  • 6
  • 1
    To make sure I've got this straight: mounting the same block device in two separate locations on the same filesystem is resulting in one mountpoint showing the files and the other not. Is that a correct summary of your situation? – womble Sep 02 '15 at 23:40
  • Sadly, yes. That's exactly it. The failing mount points are all directories used as previous mount points. Any new directories work. – Wes Hardaker Sep 03 '15 at 17:46
  • And to ensure one other thing is understood: the filesystem isn't just showing no files, it's not actually getting mounted at all. It simply silently doesn't actually attach the block device at all. – Wes Hardaker Sep 03 '15 at 17:46
  • That is... surreal. The info you put in your first update, about the mount showing up and then going away, makes it all clear, though. As you say, "systemd strikes again". Glad I've kept it right the hell away from all my systems so far... – womble Sep 03 '15 at 21:21
  • Still don't have the "right" solution for fixing it. I suspect it was a forced touch of fstab and the daemon-reload that did it, causing systemd to re-read the fstab. – Wes Hardaker Sep 09 '15 at 17:21
  • Still don't have the "right" solution for fixing it. I suspect it was a forced touch of fstab and the daemon-reload that did it, causing systemd to re-read the fstab. – Wes Hardaker Sep 09 '15 at 17:21

0 Answers0