From owner-svn-src-all@freebsd.org Sat Sep 26 19:35:02 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 B7B6E427020 for ; Sat, 26 Sep 2020 19:35:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 4BzJs15Fwrz40ll for ; Sat, 26 Sep 2020 19:35:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf31.google.com with SMTP id cv8so3290804qvb.12 for ; Sat, 26 Sep 2020 12:35:01 -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=l7KvjvXECNc7nKOV/otTP5co+bAwHJwaU4Hbs1b+NmI=; b=lxFk/TdHkQHmyn4QaLmfDbyNpr7gRdPCaZ3wUzlqaJldAv0wMfRNxP2L9k7hd4qDEG 9Xt8i7yzOfiTIedrWL4wo4WqyX2T5/u1ay97wxvSvnL12m53qGmwlll3bJiP5kWX9kvL lPKfHpqtK4aE8RniYieTCZ54vrPF2leQoCudaeCNuavuVJ74mQjhfEzKIuzQG469psAJ s2ImB8bSS+0KcTDBbmGaHiNlYCYRnjZkMwYmLmJPLg6+2DkigoUfo6anEdwlvkMfA8p9 nfe5ZYCTWAxvXTU9o9g47NmadQCEcMgcthiAG1OzFsELVdmrRLvDB0Mh9T/WPDmlIygf qFWg== 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=l7KvjvXECNc7nKOV/otTP5co+bAwHJwaU4Hbs1b+NmI=; b=aB9oO1H33DX9clss6uJQ6p3LDZrRXKZWosLSdgUqe4CUApOjxDnBYMHNXAjYgBLkXh bx9+0/Lq1RDkioOozbi+AvBJ8ho+xEu7F8+DdEy9dOTF9JnHjiNTqwrZRSw5xQcBpcux rcDErhl9o2gOOT8IJEXaN4exArWp2jlCBtl74h4+D+SY95/RL6kbI0+nKvxVO7Acm/8r E33WbLE72aatth0GxlIe5kNpnIoVTdIW2s3XhaZbf0SJL1PpNJhFVqNb1nfjgYHjts/b upO+4hM6Nci/+WdApkCcRFVctUiJpBDcJlugXqC4sONqi+Y3MGc9tPwYJO+vs4nKN2f0 ZhFA== X-Gm-Message-State: AOAM530TBSGO4LpfFPmjgAdKKEM1erOl2fp96k8tC1IceoTe11oLp9Df 6Zjd8tIVQNpRSEZujmNYODdM7cnyudNO3Kjw9LfJGg== X-Google-Smtp-Source: ABdhPJxlLQwWxy62GBKbcLmyCNBbIYTKpyZkVHS1r7mBLjiEsgxrkNpqLs6GXG1KsaHJrbGoBI/nmXSUEMTdMdCKs4I= X-Received: by 2002:a0c:a162:: with SMTP id d89mr5041064qva.28.1601148900755; Sat, 26 Sep 2020 12:35:00 -0700 (PDT) MIME-Version: 1.0 References: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Sat, 26 Sep 2020 13:34:49 -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: 4BzJs15Fwrz40ll X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=lxFk/TdH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.10 / 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.756]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@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.40)[-0.403]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31: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]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[svn-src-all]; RCVD_COUNT_TWO(0.00)[2] 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:35:02 -0000 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. 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. Warner