From owner-svn-src-all@freebsd.org Sat Sep 26 19:50:14 2020 Return-Path: Delivered-To: svn-src-all@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 B6310427417; Sat, 26 Sep 2020 19:50:14 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (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 4BzKBZ1FMvz41Vn; Sat, 26 Sep 2020 19:50:13 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: by mail-oi1-x241.google.com with SMTP id i17so6717472oig.10; Sat, 26 Sep 2020 12:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jl3MBACx5GWXS1PYPvyRxneAi0ZoY+ltDy9NNo+YVTo=; b=X920Ii1pPwyAbIsFP0fLEE22i2Ym3uMdm+fMdjIbWd4xyWUhaul6v7WO/BMxiZ5WA0 wi1sQjw78GoAHoUjr5haF70/IoE+5BJWQT8l1Ulb86bR+4nuPBfdSLdF70UQqiZ04CXr EWCB2KEC/NgmmDC8lSLUUIMokjVG6cYaPDyvF+01vFuum3XnX35O2GUwAPBaFog/igX2 JdkKX6luDDVDt1+Nxdp9ARfaAH9Yz8NaqLWQQ9hp6ItnIHKcWD9JqtZ0/JEKD0cYCoW1 7Vj5BdGLv6SaL078MTbJOSMgffQPSMmtgKN2FQbX63d6/V2+ENAeOYaorPPsm2tuHR++ fIYg== 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=jl3MBACx5GWXS1PYPvyRxneAi0ZoY+ltDy9NNo+YVTo=; b=F21mHO6drKl8fHFY9sx+ETfddeFfSP1YYD6x7JZniXZrLnGS2kWBC6LnI7ZX7bJT7f f/+f0XvGC2hg9m5fYF+Zu/qRpLRDtvwOvyYwuesNkd8c80Yk9/LKsr0TUTSzS7egGgtR rQhza65I6JR7+4q6YfauiJIngELm1Sov0xWysntdNF5dnFLxUtwNoTDtQ8o68w/UGnEy crwB3Pd13jTyvSMCvBzO4YidA6xP4rjaS9d1eRqHaIHLnFA+8ZGsC5J+l3rgXOQ2YpE0 BH33a3jWSnITDGxiUs9IOPYb9asZW7Y58JU9c1MDzGe2N5DD66n2NnXeU0xzLlh24SkR gtNg== X-Gm-Message-State: AOAM532BUEOn/hQ76hFnbMAunnpPwW8CfbZIjGObvRMJHHsMgtCbc9V+ MN205VhJCWf2ZLcYiBtfZrjcqQim01yCVGiN/Npoerp+kvQ= X-Google-Smtp-Source: ABdhPJy71ubemaFXrVZRTJsYgHIN4xa1v/uTUfcPPo0ywW13QdM2QOgEsxX9pNZCk1kVnEO0dWTajGVCRbWsSrlY7wU= X-Received: by 2002:aca:220e:: with SMTP id b14mr1889075oic.97.1601149812251; Sat, 26 Sep 2020 12:50:12 -0700 (PDT) MIME-Version: 1.0 References: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> In-Reply-To: From: Benjamin Kaduk Date: Sat, 26 Sep 2020 12:50:01 -0700 Message-ID: Subject: Re: svn commit: r365643 - head/bin/cp To: Warner Losh Cc: "Rodney W. Grimes" , Ian Lepore , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4BzKBZ1FMvz41Vn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=X920Ii1p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bjkfbsd@gmail.com designates 2607:f8b0:4864:20::241 as permitted sender) smtp.mailfrom=bjkfbsd@gmail.com X-Spamd-Result: default: False [-2.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.09)[0.086]; NEURAL_HAM_LONG(-1.02)[-1.016]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::241:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 19:50:14 -0000 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"? -Ben