From owner-svn-src-head@freebsd.org Sat Sep 26 20:01:15 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD7CF4279CD for ; Sat, 26 Sep 2020 20:01:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzKRG5JW7z42Zx for ; Sat, 26 Sep 2020 20:01:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id g72so6549568qke.8 for ; Sat, 26 Sep 2020 13:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EN3Kti6OFXbaZoQGWmy58mWfxYl0SeXOr0nwO4hKfqU=; b=cw1J73UjWE+czdPCFQj+VH4xTnaDxduUmJjXHJ5EcXE7vb61CAMRQnlS81jDWEnE1t U4km8h+pC/HRbR7bhfmC0cgTSGtmSJa/UHwEWSMB7ajNSl6ThKOQeHi67HtqvdJhGXhh 3Nn+aQeUtHRFg+wKtbqwIp0lfCXO91uGoJYeeoPN8Z15k71okSAUflEz4I1+kaxoqdkZ 1av80lXT6HZ/ub8V8/KPrwndVVPA/QAXPcbCxBSNyOr7cjl3Sa/WUPtHK829CIZLV9Lf X6AqtcqLgu1kkvrMcAu+s6aQBYJldFRv+nD5I4rqKN9cdxoe6lMXYERwFOgcz9PZBE8Z tCpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EN3Kti6OFXbaZoQGWmy58mWfxYl0SeXOr0nwO4hKfqU=; b=hvid2x0d8y8J3BB7j0AFS5P3Rf2vcNNKDTRR4y174H/8SdUIZKJlfFf9fZa4+/OaqN thqYRsXsGk1sygdapRpjDLNOvfxD/iyTL2kDQAe4Grqux0e0aGZL3QsBZtUQBICITejv anBUFoSRsAPHCISYVS2oCHkZm4z1yAo5Mgu2qkKjDNU5/s8EtfJwJfkHFtbgOZ53rKKc 3LjI0ZWUg9zh/jvcXPWTtI+91rIQy970ictsrV0LvB4cb/idESADtbwO6Ci+0JWykuKD 9fdMf2WpnnCrwHVRdq5BXxPRd5HFdeYbmEZ525OfrE0mPYgVMXvoMhwD6AqHuYfuCDpA ou9A== X-Gm-Message-State: AOAM532GpugvoZxtRJKW/7FG0aYpRubETC+LVG8/j6wmNg45tsuTB2bl yMJe0ZkHw3i61JCeTzMixkZW9aFa0CibXkps0wKeGQ== X-Google-Smtp-Source: ABdhPJzza/ZDQ5AR2uzNE7uXlsWY/woC7hS0A0mrWcZycgzo3/88S65EgAndzMNFzOu3uJ6xKlshrNCb2fkzXWz80Gk= X-Received: by 2002:a05:620a:1583:: with SMTP id d3mr5643178qkk.495.1601150473810; Sat, 26 Sep 2020 13:01:13 -0700 (PDT) MIME-Version: 1.0 References: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Sat, 26 Sep 2020 14:01:01 -0600 Message-ID: Subject: Re: svn commit: r365643 - head/bin/cp To: Benjamin Kaduk Cc: "Rodney W. Grimes" , Ian Lepore , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4BzKRG5JW7z42Zx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=cw1J73Uj; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::731) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.11 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.94)[-0.942]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.76)[-0.759]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.41)[-0.409]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[svn-src-head] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 20:01:15 -0000 On Sat, Sep 26, 2020, 1:50 PM Benjamin Kaduk wrote: > On Sat, Sep 26, 2020 at 12:35 PM Warner Losh wrote: > >> >> >> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk >> wrote: >> >>> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh 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 >