From owner-svn-src-head@freebsd.org Sun Oct 11 15:12:57 2020 Return-Path: Delivered-To: svn-src-head@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 3EBF13F6A2B for ; Sun, 11 Oct 2020 15:12:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8QKh2D5Rz4KCX for ; Sun, 11 Oct 2020 15:12:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf34.google.com with SMTP id 13so7185920qvc.9 for ; Sun, 11 Oct 2020 08:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UgzgxSjAXUSH4Acq/PieE8NXKuuGwuJRSEKrqy00EtE=; b=dfbMlqmyjQUZGhkuAR74msN15hQ1+Ds2Zum7QdTJbIhCTpnd/l+r2wRxU6llRT/1BP Va+5mVWzcThtsMBcO3hiIOX2Es2F6n+zqIPfImYvWvE1mDfF0QMMdC8WaBszDPAbV7Ys 2Ie4qzr1UWXjEOcGWZo2jflEv1EFsebg2LDWQCZ7lnmwltibW+DcaKV71S7YOvf2EXxg ZBzVT5lztYc9yp7Dcz0xhfWpaJQpb0b+j6Z6gv3EJ8lroVT1aild+rkEWdwLjtZTLPXR b4aF7s4NQXhoTtAD/T8nXg4hcbxvwEC+JnNmtbj7x9P9ByXp8MSKeRR2Jq9FD3ZJconm zTgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UgzgxSjAXUSH4Acq/PieE8NXKuuGwuJRSEKrqy00EtE=; b=OzPBh51zZi81dd3dZpjvpgVq9znvnqflI1YQOPUX0Ho7Z5THr6L+wsv7TCQQF01fLm BgBa8lzKVcl0qncATT4Xeo5nn26CC4wZVpzDN5u/pmds5lvq/02vfAvSKlIJjhRLAmve 46z3ycaFnV5jynV/K/pEOEy7fhU+mH2JI+dNtVAJx51pLxF+I4gHj/M1nJi3FGVNGHEV Heu6fH8hRHHI0nMR6QwXlDgEChE95D9SFSIA6W6NwjoKcq7Ab1Y3m5rTZe8A8joJa0kN 5ml/RjvGka3aUlVpVdw0SJxIawWx6qCZJaUmaY5cuXJymfL+63feEBzdUl8iDRsSxhUy LriQ== X-Gm-Message-State: AOAM531o+FnoIa8H7guM0kenIkvfvW1Z010KbGJeCivuyaD5FWQWXut/ TgBDFHxM3l/wAfMXI/wzaxrUNPYXFxXScy9zV7RWmw== X-Google-Smtp-Source: ABdhPJwaVe5OY0eIR6rVZtuCmYoCHsfw59AusrbkuoJ5kjqUS3EeypVlUxsRUyekiSZ9e35LAwb0RdueXggcN88e27Y= X-Received: by 2002:a05:6214:174f:: with SMTP id dc15mr20736890qvb.26.1602429174925; Sun, 11 Oct 2020 08:12:54 -0700 (PDT) MIME-Version: 1.0 References: <202010111040.09BAeCfg073782@repo.freebsd.org> <8601CC07-3A43-461A-915C-3CB68BADF41A@me.com> <20201011130151.GA32755@FreeBSD.org> <35355AD6-42C6-48A2-8FCF-A371A82D683A@me.com> <20201011133023.GA67893@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Sun, 11 Oct 2020 09:12:43 -0600 Message-ID: Subject: Re: svn commit: r366626 - head/sbin/reboot To: Kyle Evans Cc: Alexey Dokuchaev , Toomas Soome , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4C8QKh2D5Rz4KCX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=dfbMlqmy; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f34) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[svn-src-head]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.005]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.50)[-0.499]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f34:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[freebsd.org,me.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 15:12:57 -0000 On Sun, Oct 11, 2020, 8:00 AM Kyle Evans wrote: > On Sun, Oct 11, 2020 at 8:30 AM Alexey Dokuchaev > wrote: > > > > On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > > >> ... > > > >> 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? > > > > > > It is not really about being second-class citizen, it really is about > if > > > and how we can implement the feature. With UFS there is a limited write > > > (write to existing, allocated disk blocks), with ZFS there is no write > to > > > file system at all. > > > > I see; that would explain why loader(8) replaces the "YES" -> > "NO", > > but I guess I'd have to read the discussion on -rc@ which lead to > r177062, > > because I don't see the reason for it to be removed (twice) if it's being > > disabled by the loader(8) earlier anyway. > > > > IMO both steps are important. You have to (at least try to) disable it > in case it doesn't get you all the way to multi-user, but then you > don't want the old contents of nextboot.conf being inadvertently used > on another boot if someone's habitually `nextboot -a`ing. > There were cases that were discussed when the geature went in that required it to be removed in some failure modes for full functionality. I don't recall if they were in the rc thread or somewhere else. And honestly, nextboot.conf is special in so many ways. We have no unlink in the loader for UFS and no write for ZFS or MSDOS. In those cases, the rm from rc is what you want (though lately we use a different mechanism for ZFS). So the docs were right before, in the big picture. The implementation detail now enshrined there is unwise. I'm not likely to remove it, but if UFS grows unlink in the future, this man page will need to change. Then again, all the loser man pages need a complete rewrite, or close to it. Warner >