svn commit: r365643 - head/bin/cp

[Warner Losh]

On Sat, Sep 26, 2020, 1:50 PM Benjamin Kaduk <bjkfbsd at gmail.com> wrote:

> 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"?
>

Yes. The file is presented, but no scenario has been given to create it.
So, if there is a common way to get this file, that would be good to know..
Even if the answer is something like bsdinstall has a bug, or something
like that...

Warner

-Ben
>