NetBSD Problem Report #56384

From www@netbsd.org  Wed Sep  1 10:27:09 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_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 E1AB21A9239
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  1 Sep 2021 10:27:08 +0000 (UTC)
Message-Id: <20210901102707.576B01A923A@mollari.NetBSD.org>
Date: Wed,  1 Sep 2021 10:27:07 +0000 (UTC)
From: logix@foobar.franken.de
Reply-To: logix@foobar.franken.de
To: gnats-bugs@NetBSD.org
Subject: Exiting and restarting sysinst during installation leaves /targetroot unmounted
X-Send-Pr-Version: www-1.0

>Number:         56384
>Category:       install
>Synopsis:       Exiting and restarting sysinst during installation leaves /targetroot unmounted
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    martin
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 01 10:30:00 +0000 2021
>Last-Modified:  Wed Sep 01 12:46:13 +0000 2021
>Originator:     Harold Gutch
>Release:        9.99.88
>Organization:
>Environment:
NetBSD  9.99.98 NetBSD 9.99.98 (GENERIC) #0: Thu Aug 19 12:13:37 UTC 2021  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
Selecting "x: Exit sysinstall" in sysinst unmounts /targeroot .  Running sysinst again then doesn't mount /targetroot and doing anything in the "Utility menu" or the "Config menu" that wants to write to a file (like network configuration, changing the root password, adding a user, ...) will fail.
>How-To-Repeat:
1) go through a normal installation (boot install medium etc.)
2) at the end, select "x: Exit sysinstall"
3) at the shell prompt, run "sysinst" again
4) go to "f: Config menu" and select (for example) "o: Add a user"
5) Observe "Command failed" as it tries to mkdir /home/$USERNAME
>Fix:
As /targetroot will be umounted properly anyway once the system reboots, can the umounting dance in cleanup() in sysinsts's main.c perhaps be removed?  Not sure if that has unwanted side effects...

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: install/56384: Exiting and restarting sysinst during
 installation leaves /targetroot unmounted
Date: Wed, 1 Sep 2021 12:36:02 +0200

 On Wed, Sep 01, 2021 at 10:30:01AM +0000, logix@foobar.franken.de wrote:
 > 3) at the shell prompt, run "sysinst" again
 > 4) go to "f: Config menu" and select (for example) "o: Add a user"
 > 5) Observe "Command failed" as it tries to mkdir /home/$USERNAME

 That is kindof intended behaviour. You can add users later (in the
 installed system) by running sysinst as you describe above.

 The problem is that in your invocation it does not know if you mean
 the currently running system or the new installed one.

 It could write a hints file to /tmp with settings from the previous
 installation run and ask whether to reuse those on next invocation.

 Martin

From: Harold Gutch <logix@foobar.franken.de>
To: gnats-bugs@netbsd.org
Cc: install-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: install/56384: Exiting and restarting sysinst during installation leaves /targetroot unmounted
Date: Wed, 1 Sep 2021 12:50:03 +0200

 On Wed, Sep 01, 2021 at 10:40:01AM +0000, Martin Husemann wrote:
 > The following reply was made to PR install/56384; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: install/56384: Exiting and restarting sysinst during
 >  installation leaves /targetroot unmounted
 > Date: Wed, 1 Sep 2021 12:36:02 +0200
 > 
 >  On Wed, Sep 01, 2021 at 10:30:01AM +0000, logix@foobar.franken.de wrote:
 >  > 3) at the shell prompt, run "sysinst" again
 >  > 4) go to "f: Config menu" and select (for example) "o: Add a user"
 >  > 5) Observe "Command failed" as it tries to mkdir /home/$USERNAME
 >  
 >  That is kindof intended behaviour. You can add users later (in the
 >  installed system) by running sysinst as you describe above.

 Well, intended if you run it later on the running installed system,
 yes.


 >  The problem is that in your invocation it does not know if you mean
 >  the currently running system or the new installed one.
 >  
 >  It could write a hints file to /tmp with settings from the previous
 >  installation run and ask whether to reuse those on next invocation.

 Yes, that was the other idea (in addition to not umounting) that
 crossed my mind.

 I guess at the least there could be some kind of warning ("/ is
 readonly and you don't have anything mounted at /targetroot,
 $OPERATIONS will fail"), perhaps also suggesting to mount the
 installed system at /targetroot if that's what the user wants to do.

 Basically right now sysinst will leave you in a (somewhat) broken
 state if you happen to *accidentally* select "x: Exit" (instead of,
 e.g., "f" which is directly above).


   Harold

From: Martin Husemann <martin@duskware.de>
To: Harold Gutch <logix@foobar.franken.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: install/56384: Exiting and restarting sysinst during
 installation leaves /targetroot unmounted
Date: Wed, 1 Sep 2021 12:56:28 +0200

 On Wed, Sep 01, 2021 at 12:50:03PM +0200, Harold Gutch wrote:
 > I guess at the least there could be some kind of warning ("/ is
 > readonly and you don't have anything mounted at /targetroot,
 > $OPERATIONS will fail"), perhaps also suggesting to mount the
 > installed system at /targetroot if that's what the user wants to do.

 Yes, but in many cases / will not be read-only (e.g. a ramdisk).
 But checking for read-only will avoid the immediate failure and is
 a usefull thing to do independantly of a more general solution.

 Martin

Responsible-Changed-From-To: install-manager->martin
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Wed, 01 Sep 2021 12:46:13 +0000
Responsible-Changed-Why:
take


>Unformatted:

Home	PR Database Search