On Sat, Sep 26, 2020 at 12:35 PM Warner Losh <i...@bsdimp.com> wrote:
> > > On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk <bjkf...@gmail.com> wrote: > >> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh <i...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
