On Sat, Sep 26, 2020, 1:50 PM Benjamin Kaduk <bjkf...@gmail.com> wrote:
> 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"? > 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 > _______________________________________________ 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"
