svn commit: r365643 - head/bin/cp

[Benjamin Kaduk]

On Sat, Sep 26, 2020 at 12:35 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> 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.
>>>
>>>
>> 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!).
>>
>
> I think there's two different things that are being talked about here.
> Let's not confuse the two.
>
>
I agree there are two different things going on here.  My apologies for
using buildworld as an example of "something that writes to /dev/null" when
any other example would have done just as well.


> 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
> 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.
>
>
I was reading the thread differently than that.  In particular, I saw
observations that some people had a file /dev/null on their root
filesystem, and speculation that it appeared during early boot or
shutdown.  In particular, I did not see specific reports that it was
created during early shutdown, just speculation.  Such speculation has
since been thoroughly debunked, but the observations of a /dev/null file
remain.  It is easy to get such a /dev/null file on your root filesystem,
you just have to arrange for that filesystem to not actually *be* the root
filesystem when the file is created.  So ... "nothing to see here"?

-Ben