From owner-svn-src-head@freebsd.org Sat Sep 26 19:14:28 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 7E5744264E3; Sat, 26 Sep 2020 19:14:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzJPJ0Gbpz3yCj; Sat, 26 Sep 2020 19:14:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08QJEEFr018497 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 26 Sep 2020 22:14:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08QJEEFr018497 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08QJEElD018496; Sat, 26 Sep 2020 22:14:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Sep 2020 22:14:14 +0300 From: Konstantin Belousov To: rgrimes@freebsd.org Cc: Ian Lepore , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r365643 - head/bin/cp Message-ID: <20200926191414.GA2643@kib.kiev.ua> References: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BzJPJ0Gbpz3yCj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; REPLY(-4.00)[] 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: Sat, 26 Sep 2020 19:14:28 -0000 On Sat, Sep 26, 2020 at 10:02:10AM -0700, Rodney W. Grimes wrote: > > > On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote: > > > > I was under the impression from previous reading and kib's response > > > > that this is a complete non-issue, there's no way you can go > > > > multi-user without a mounted /dev and we go to somewhat great > > > > lengths to make sure we're good. > > > > > > Though kib can assert that, it does not change the fact that I > > > frequently find /dev/null FILES on unmounted root file systems. > > > > > > But lets not mix the 2 separate things of boot time /dev dependency > > > and build time /dev dependency. > > > > If you look in sys/kern/vfs_mountroot.c you can see that the code to > > mount /dev is invoked unconditionally as the first step of mounting > > root, and that all the calls it makes to get devfs mounted have their > > results checked with KASSERTs. > > > > That's pretty strong evidence that devfs is mounted before rc scripts > > run. That creates a situation where you are making an extraordinary > > claim, so you need to provide extraordinary evidence to support it. A > > sequence of actions that allows others to recreate the situation would > > do the trick. > > I have provided ways one can look for this file in > other messages of the threads. A dump of a UFS root > can show it up, and iirc you can find it in a > zfs send of a boot dataset. > > > > > (A question that occurs to me: could it be that the files you've seen > > got created at shutdown after devfs was unmounted, rather than at > > startup? I don't know enough about the shutdown sequence to know > > whether that's possible.) > > Its not "the files" it is "a file, /dev/null". And yes, it could > be very possible that it is during shutdown. Sadly the files is > usually of 0 length so leave little clue as to what is creating them. Out of curiosity I checked it on 3 of my machines, oldest of them was installed in 2014 and had numerous issues with boot and shutdown meantime. Roots are on UFS, and everywhere I see solo% sudo dump -0 -f - / | (cd /tmp && restore -i -f -) ~ DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 0 dump: Sat Sep 26 22:07:39 2020 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/nda0p2 (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 785484 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] restore > cd /dev restore > ls ./dev: restore > quit DUMP: Broken pipe DUMP: The ENTIRE dump is aborted. So for me the question how do you get your /dev/null on root is open.