Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Sep 2020 22:14:14 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        rgrimes@freebsd.org
Cc:        Ian Lepore <ian@freebsd.org>, src-committers <src-committers@freebsd.org>,  svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r365643 - head/bin/cp
Message-ID:  <20200926191414.GA2643@kib.kiev.ua>
In-Reply-To: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net>
References:  <a1302355a272f5790562551dfe7631c280107b55.camel@freebsd.org> <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200926191414.GA2643>