Re: mount weirdness
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.
Reply to: