svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk <bjkfbsd at gmail.com> wrote:
> 
> > On Sat, Sep 26, 2020 at 11:55 AM Warner Losh <imp at bsdimp.com> wrote:
> >
> >> And there's the rub: how did this file come to exist? I'm certain it isn't
> >> booting or shutting down the system based on when devfs is mounted (before
> >> init) and unmounted (it's not done by the shutdown scripts). Now, it's
> >> always possible there's a hole in my understanding of the sequence of
> >> events. But given the examination of code, it's crazy to think this could
> >> be created by anything but some weird bug. That's why a step-by-step from
> >> scratch guide is needed. Im happy to look into it, but I need a bit more
> >> to
> >> go on.

Some others have run dumps, nfs exports, so far I see 4 file system report,
I see these infrequently, so I would not consider these 4 file systems to
be a very large data set.

> >>
> >>
> > I don't think it's terribly complicated; either set up a multi-boot system
> > or
> > pull the physical drive with / from one machine, and mount it while booted
> > into a different environment.  Then, chroot into it and do ... just about
> > anything.
> > If you didn't mount devfs before chrooting, then you get a file /dev/null
> > (and some
> > really confused errors from, e.g., buildworld!).

This is not the situation that I am reporting.

> 
> I think there's two different things that are being talked about here.
> Let's not confuse the two.
> 
> The first is making the build system not depend on /dev/null. You'll find
> that's hard to do if you and try to do it since /dev/null is used about 200
> times in the current build system in about a dozen different ways. Some are
> easy, most are a bit tricky since you can't just close stdout/stderr
> because then any files opened by the program will get those FDs and
> printf/fprint(stderr, will collide.  This dependency won't be fixed any
> time soon, though I could add a seatbelt to buildworld/buildkernel that
> ensures that /dev/null is a character device.
> 
> The second is a report that /dev/null is created all the time through

Correction, I never stated "all the time".  I stated I have seen this
on SOME analysis of disk pulled from running systems.  Let me add to
that these driver are only ever mounted Readonly, as what is going on
is a forensics state post mortem of the system.  These are not jails,
some may be VM images, but even in the VM cases these are raw disk
images that are never mounted read/write.

It is possible that a cdrom or nfs boot was done during the life
time of the node(s) with a chroot into a root file system mounted
some place else.

> normal means before devfs can be mounted.  However, several people have
> looked and found no evidence on their system. This means there's something
> special / unique to Rod's setup that's generating them (assuming it isn't a
> simple chroot without devfs). What that is, and how they come to be, hasn't
> been explained in enough detail to reproduce. That's what people are asking
> Rod about: how do we get there? How did it happen? Once we know those
> answers, we can fix it.

Problem is these are being found in after the fact analysis,
so "getting there" is going to be hard.  I'll try to collect
better data such as inode contents and dates and see if I 
can correlate that to system install time, or some time during
the systems life time.

Given what kib, and ian have said I am starting to suspect
that this may be occuring during the install process, the
dates on the null inode and a find of the oldest inode on
the disk should correlate that next time I see one of these.

If I could easily reroduce it we would not be having
this conversation, it would of been fixed.

> Warner
-- 
Rod Grimes                                                 rgrimes at freebsd.org