From owner-svn-src-all@freebsd.org Sun Oct 11 13:01:51 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 903F43F3CB7; Sun, 11 Oct 2020 13:01:51 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8MQR2qYzz4CmX; Sun, 11 Oct 2020 13:01:51 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1602421311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fP2xC7obF9b2TBG5NvtV92VZVpj4aTYcY1jqLeGKzOw=; b=u6+ExhE8rBbOaYzbw4ss08lCIhMSbbgXut0R8pjkPkKNgjF+AkPwnr40A4eLYJErA+HxfF SqOgXDBY4VHVLWNpTD5LZ5ocCZE0poi+/Vc9YXhbgnqxKNP013fbMIWQVVrOAyk1mCWnt4 3YJ+jk5+LFlGtpcNAuze5WmhlneQI3CpqKzWwjng63IpItIfOCQJHkSaZTXwzPK7MYqrje zXdnGFnkovsfTeFXlws0mj6ZYjrtoZuUONMMrbwP5iiHMyWkbJVMTYNz09envgiK/infeD RYIL2Eddo5ycIGkkeqnY768SfqieRV3QEbbnFY/UNFfJFHo/kWwMaNwsM/DkHg== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 4E5171737B; Sun, 11 Oct 2020 13:01:51 +0000 (UTC) Date: Sun, 11 Oct 2020 13:01:51 +0000 From: Alexey Dokuchaev To: Toomas Soome Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r366626 - head/sbin/reboot Message-ID: <20201011130151.GA32755@FreeBSD.org> References: <202010111040.09BAeCfg073782@repo.freebsd.org> <8601CC07-3A43-461A-915C-3CB68BADF41A@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8601CC07-3A43-461A-915C-3CB68BADF41A@me.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1602421311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fP2xC7obF9b2TBG5NvtV92VZVpj4aTYcY1jqLeGKzOw=; b=ZkcFiJg+HxLXinO/hxCySorf7EDfXKqBMmITydXQhmss63mZ8T+lVCJYMmA2TVrm5HZHOG CGtKj1pLE/J6JK3iE/YR1xrPeZlpKnmvSZYL2eUf3lnBW/6GLneKujulx7NS2cUIeaLxBp UuwuTla2YlW/IniQAJJT8mn2t10kWTDUlABdPvNtsp5sRnz6ngthVDQKmu4AxrZvqzUBmA /c6v26TLv/2imVr+FaNQpJhNsDLn0iKDEt5wSTIuFoHK7F5BheLXFghPZ2QtvXNlcZ5uqh 3+uPT+sifSwaIlf4W1IDKMpFFtL2ThKeEdiTwiil0N4AcUJ0ND4N3HAvGEYIMQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1602421311; a=rsa-sha256; cv=none; b=gRbsBXCRd8fhYIrGjr01KprhmSOpIb+CqhHmYV639FI2KlhUFuLO29HMljh4wtKX/RTVZJ +BRoPZ8EKSvIf8Br1SnQ5RwO0/1Qm27wBkhz3uRFHp5Y75S3dAAY7qtoWLsGib63uzvfz5 Xb3DYpaOhD9PVMRmbYPJ0dwV9tNt7SO5tuWL0VIbaz5k5TgqX+lT0mo1uVpucQLr9NOVRc IF0xvTZYfnVsz6U48Y2mqRxa+637AtqXOWHc8gAX8iFKKD4r1zWbjWonvn8nDU7dV+8VST LcNkqO6QMDGZP5p7NOWtDoem3xKTNlDhtAPIFRq7IrHRcl1C0cdqQXDI/sfipQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 13:01:51 -0000 On Sun, Oct 11, 2020 at 03:20:16PM +0300, Toomas Soome wrote: > Please note, the remove is done by rc script during the boot. But not by the loader(8) as the page used to claim. It confused me how to avoid the remove, and only later I've discovered with some relief that it is in fact not being removed, but only disabled (which IMHO is a lot more graceful and thus correct behavior). > Also nextboot.conf not generic configuration file (such as loader.conf > or loader.conf.local), but the implementation specific file, part of > special feature. > > That is, one should not assume the presence of nextboot.conf file, make > assumptions about its content, or perform manual edits on it. Do we want it to be the second-class citizen like this? Would it make better sense by documenting it more completely instead? ./danfe