NetBSD Problem Report #55355

From root@starwolf.com  Sun Jun  7 04:50:48 2020
Return-Path: <root@starwolf.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 9CFEF1A9219
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  7 Jun 2020 04:50:48 +0000 (UTC)
Message-Id: <20200607020419.85757B@eddie.starwolf.com>
Date: Sat,  6 Jun 2020 19:04:14 -0700 (PDT)
From: greywolf@starwolf.com
Reply-To: greywolf@starwolf.com
To: gnats-bugs@NetBSD.org
Subject: mount on symlinked device spits undesired warning
X-Send-Pr-Version: 3.95

>Number:         55355
>Category:       bin
>Synopsis:       implement a way to turn off the warning from mount(8) & co.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 07 04:55:00 +0000 2020
>Last-Modified:  Sun Jun 07 09:45:01 +0000 2020
>Originator:     The Grey Wolf
>Release:        NetBSD 9.99.63
>Organization:
Star Wolf Innovations
>Environment:
System: NetBSD eddie.starwolf.com 9.99.63 NetBSD 9.99.63 (GENERIC) #1: Thu May 28 01:02:22 PDT 2020 greywolf@eddie.starwolf.com:/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	Hi, I know this seems silly, and will probably get rejected, but...

	When mounting an LVM, I usually prefer to use /dev/VGname/LVname vs.
	the (usually longer) /dev/mapper/VGname-LVname.  Mounting on that 
	device, because it is a symlink, produces the warning:

	"/dev/VGname/LVname" is a relative/non-resolved path; using
	"/dev/mapper/VGname-LVname" instead.

	Whilst I understand the intent, it is bothersome, and I would like
	some way to turn it off (as it is, I am currently "#if
	0/#endif"ing around the warnx() statement in sbin/mount/pathadj.c.
	I don't like this, though, for the same reason that I don't want
	to bitbucket the output from mount in case something goes wrong

	The only way I see to handle this, because pathadj() performs both
	the adjustment and the warning, is to add a 'nowarn' variable to
	pathadj(), corresponding code inside of pathadj(), plus options
	and associated variables to everything that uses pathadj(), so
	a fix based on this seems highly unlikely.  Having a warning message
	on a mount referencing a valid symlink feels absurd on its face,
	though.  I can see complaining, of course, should the end target
	not resolve.

	I could point to lvm itself and say it's a problem, but NetBSD
	(I am guessing) doesn't actually maintain the code except insomuch
	as to get it to build and operate under NetBSD.

	In any case, the warning is silly, in my opinion, for a path that
	resolves.  It's not something I feel the need to know.

>How-To-Repeat:
	lvcreate -L size -n LVname VGname
	newfs /dev/VGname/LVname (which references, properly, rLVname)
	mount /dev/VGname/LVname /mnt

>Fix:
	If a dowarn or silent parameter added to 
		/sbin/mount/pathadj.c/pathadj()
	would be acceptable, I will gladly submit the requisite patches.

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/55355: mount on symlinked device spits undesired warning
Date: Sun, 7 Jun 2020 09:41:58 -0000 (UTC)

 greywolf@starwolf.com writes:

 >	"/dev/VGname/LVname" is a relative/non-resolved path; using
 >	"/dev/mapper/VGname-LVname" instead.

 >	Whilst I understand the intent, it is bothersome, and I would like
 >	some way to turn it off (as it is, I am currently "#if
 >	0/#endif"ing around the warnx() statement in sbin/mount/pathadj.c.

 The mount commands did resolve paths so that you could umount again with
 the same path. With a relative path that would depend on the current
 directory of the mount and umount operations respectively. So that paths
 were canonicalized.

 When refactoring that code into pathadj (for some but not all utilities),
 the warning was extended for non-resolved paths because that's what was
 checked for.

 Using the resolved path is a good thing to avoid confusion (even when
 umount -R exists and is a different solution to the problem). Warning
 about relative paths might make some sense because the current directory
 is somewhat volatile. Warning about symlinked paths on the other hand
 doesn't help anyone. If someone is going to change the symlinks after
 mounting, it's hopefully the same who wants to unmount later.

 So I suggest to
 - complete the refactoring so that pathadj() is used in all tools.
 - only warn about relative paths.

 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

Home	PR Database Search