Sorry to cause the thread to "wander", but some of us are trying to replicate aspects of the OP's problem, which necessitates explaining any differences in the results being obtained.
On Thu 08 Aug 2019 at 14:14:25 (-0400), Michael Stone wrote: > 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. Well I wasn't aware that dmesg specifically added anything to what I see as a matter of course: I have an xconsole at the foot of the page and an xterm running tail -F /var/log/kern.log in my diagnostics viewport. But your incidental choice of example has nudged me in the right direction; seeing the string "read-only", I tried: # mkdir /somethingelse # mount /dev/sda7 /somethingelse mount: /dev/sda7 is already mounted or /somethingelse busy /dev/sda7 is already mounted on /wrenbk # mount -o ro /dev/sda7 /somethingelse # and bingo. /wrenbk is the backup installation on this laptop. I normally mount them readonly so that I can't accidentally interfere with them. So it appears that any subsequent mount commands have to agree explicitly with the earlier choice. Are there other, similar factors involved in the OP's case… Looking at the OP's fstab, regardless of what worked in the past, I would reorganise it into a more systematic order. I got caught out when systemd came out, because my fstab had two entries for the same mountpoint. SystemV just churns through fstab carrying out its mount, whereas systemd reads the whole file (and regurgitates it?) before it mounts anything. So what's the explanation for entries such as these: /wa3/Swap4 none swap sw,pri=100,nofail,x-systemd.device-timeout=60 /wa1/Swap5 none swap sw,pri=100,nofail,x-systemd.device-timeout=60 /wa2/Swap6 none swap sw,pri=100,nofail,x-systemd.device-timeout=60 /pvt04/Swap7 none swap sw,pri=100,nofail,x-systemd.device-timeout=60 UUID=20173008-… /wa11 xfs defaults,nofail,x-systemd.device-timeout=20 ¹ UUID=9092610b-… /wa2 xfs defaults,nofail,x-systemd.device-timeout=60 LABEL=Work-Area-3 /wa3 xfs defaults,nofail,x-systemd.device-timeout=60 UUID=fdbb6809-… /pvt04 xfs defaults,nofail,x-systemd.device-timeout=60 ¹ was /wa1 originally. Is it intended that the "General work areas" hide these swap files, or is this just the way the OP's fstab grew? It's not clear to me what the semantics for systemd.mount are, but a first reading suggests that it contradicts fstab. And rereading the first OP, what is Debian 10 bullseye? Is all this just an ephemeral bug that will disappear next week? > > 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: Sorry, badly expressed: by "voting", I just meant OP & Greg (2) report successful mounts, and I (1) an error message. Whether I like the ability to mount in this manner, I'm with Greg at the moment. Obviously I missed any discussion on the topic ~15 years ago, so I haven't seen any benefits spelled out. In any case, perhaps a warning in kern.log rather than total silence? After all, mount already warns about things like: "utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!" "Volume was not properly unmounted. Some data may be corrupt. Please run fsck." Cheers, David.