Re: mount weirdness
On Thu, Aug 08, 2019 at 12:09:11PM -0500, David Wright wrote:
On Thu 08 Aug 2019 at 10:56:46 (-0400), Michael Stone wrote:
On Thu, Aug 08, 2019 at 09:04:00AM -0500, David Wright wrote:
> wren 08:50:11 ~# lsblk -f | grep sda7
> ├─sda7 ext4 swan07 4a4e352f-2180-4083-92b4-f46e4e0104b4 /wrenbk
> wren 08:50:26 ~# mkdir /wa1 /somethingelse
> wren 08:50:49 ~# mount /dev/sda7 /somethingelse
> mount: /dev/sda7 is already mounted or /somethingelse busy
> /dev/sda7 is already mounted on /wrenbk
> 32 wren 08:51:16 ~# mount /dev/sda7 /wa1
> mount: /dev/sda7 is already mounted or /wa1 busy
> /dev/sda7 is already mounted on /wrenbk
> 32 wren 08:51:31 ~# rmdir /wa1 /somethingelse
> wren 08:51:53 ~#
It's already been said repeatedly that you should post the bottom of
dmesg output because kernel mount errors show up there but not in the
output of the mount command.
I've plenty of mount errors, which you've quoted, so I think you might
be addressing somebody else. Or have I missed something? But anyway,
dmesg's tail is attached, with a timecheck from earlier in the file so
that you can exercise forensic skills in tying the times above to
those in dmesg.
No, I'm addressing you. It's very common for mount to say something like
"can't do that" but you need a kernel error message to explain why
because the kernel mount API isn't verbose. (As I said in a previous
message.) Example:
# mount -o norecovery,loop test.img /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
# dmesg | tail -n 1
[268039.035599] XFS (loop0): no-recovery mounts must be read-only.
In this case the dmesg output doesn't add anything, but it's generally
good for completeness.
But the 2-1 vote wasn't whether error messages were emitted, but
whether the system should mount an already-mounted partition onto
another mount point. I get error messages and the mount fails.
Others get no error messages (though they haven't demonstrated
the lack) and a successful mount, so currently I'm in a minority
of one.
That's not a matter for voting, it's something that was implemented
years ago, in the 2.4 kernel:
potato:~# uname -a
Linux potato 2.2.19-idepci #1 Wed Mar 20 20:33:20 EST 2002 i686 unknown
potato:~# mount
/dev/hda1 on / type ext2 (rw,errors=remount-ro,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
potato:~# mount /dev/hda1 /mnt
mount: /dev/hda1 already mounted or /mnt busy
mount: according to mtab, /dev/hda1 is mounted on /
woody:~# uname -a
Linux woody 2.4.18-686-smp #1 SMP Sun Apr 14 12:07:19 EST 2002 i686 unknown
woody:~# mount
/dev/hda1 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
woody:~# mount /dev/hda1 /mnt
woody:~# ls /mnt
bin boot cdrom dev etc floppy home initrd initrd.img lib lost+found mnt opt proc root sbin tmp usr var vmlinuz vmlinuz.old
So you're confusing a completely different issue with something fairly
unique to your system. I'm not sure if you've somehow managed to turn
that off via a switch that I'm just not familiar with, or if there's
something else going on. There's a reference to dm in your dmesg, so
possibly a dm driver is grabbing your block device and preventing
multiple access. There are a few other possibilities, but suffice it to
say that they aren't typical.
Reply to: