From nobody Sun Jun 30 18:56:16 2024 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WBz0t0Zc0z5QH19 for ; Sun, 30 Jun 2024 18:56:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WBz0s1k3xz4cjX for ; Sun, 30 Jun 2024 18:56:29 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=FnsAnQl7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1035 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2c84df0e2f4so1470168a91.1 for ; Sun, 30 Jun 2024 11:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719773787; x=1720378587; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fb5gdjz7iB6jJKGjb0x3QL3ZubvTM1ocxSbDQhYlAs8=; b=FnsAnQl7Fnh+3PLUNNoTR9wh+9bf1W5tPbrCa3h7/FF84pbxISPJ/XiT4cpsphR9D6 2Ake8FgGfWvHNcP26m/ZcPG3EXS5G0N7LdTTBipwfeare2hWuJhVb5/oeCV3dEa29oGu iVrQB7zFCD+TaEPamQRqLh/lhw8cyypy/DZkhBr94fMDX48UQ4zsAydAgtYfYi+80Haq aaSxSGsxc4mnzfYPIi/AEf5ZBtG2y+KC9QuoKilG10byAevnlGvgWG++TYyZKNsZuCJ2 GUiZ4iY8O8wlRmbrFOB3RWVctbWp8xCgs0XxKYB/1BidFsIaxkh2ZW2b/iZQjtbmo218 qFDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719773787; x=1720378587; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fb5gdjz7iB6jJKGjb0x3QL3ZubvTM1ocxSbDQhYlAs8=; b=IByYKnql7KmXXI4SdtMp6p/c+cLDFI9P8ADdcpoexel8GsQ7d+xGrBaMOGciahAwdD zghvP/oLQjaarzrcxvrGhBfKmafXB4hbp9Bz9QCylVorX7zJ/erVG4Ym/hOKHux1D52y bO0Qg+t//VomSR6BJ/mL2DE+DOKP2/fUXRsgEgiW2nMeS+2GfVHSIfNYx9QQQS35eLMf EiuzQV53r65rA3PeibpNQ72HW2vOSjIF+sOt1w2vIEBLj0sRurq/LLqf5LDe5q14Rz64 zBxC+8TKJk4OGRZZGNgYDdB3seaIdB9W6zkO+VZKp1dsC+2UK7bmidz6RB2iTSW+2mzq q+Kw== X-Gm-Message-State: AOJu0YykxYGrXhTSJqFoj1rRnYRgUFXn1mboFPf4cIy4mWE3iC7uA6Ew 3cxJX3uBAAbsOE8+2IHiWmgo/rFcp3LW/fMMRQ+MXuFhaVquxcIzdii+DacsvMcrAxrB0CDHbhC doD5CHDrPlYRtl7ghfHQelimjk54T X-Google-Smtp-Source: AGHT+IEBs1o7UUVPPXHxuYgzjahREeVF6+MN3rtMSSLDNv+MzS47yA/vCIyDFDxoAsmchDh7aexKdsXyqWX7x+zu0KQ= X-Received: by 2002:a17:90a:6fa2:b0:2c7:70ba:3f02 with SMTP id 98e67ed59e1d1-2c93d1b3ff3mr6038322a91.6.1719773786967; Sun, 30 Jun 2024 11:56:26 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Sun, 30 Jun 2024 11:56:16 -0700 Message-ID: Subject: Re: new error messages after upgrade 14.0-p5 to 14.1-p1 amd64 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.95)[-0.950]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1035:from] X-Rspamd-Queue-Id: 4WBz0s1k3xz4cjX On Fri, Jun 28, 2024 at 5:23=E2=80=AFAM void wrote: > > Hi Rick, > > On Thu, Jun 27, 2024 at 09:29:51AM -0700, Rick Macklem wrote: > > >rpcbind_enable=3D"YES" > >nfs_client_enable=3D"YES" > > > >If you have at least one of these in your /etc/rc.conf, then all I can t= hink > >of is some sort of network/routing issue that interferes with rpcbind wo= rking. > > I have nfs_client_enable=3DYES only. Should I have both? Should not be necessary. I played around a bit with a 14.1 vm and was not a= ble to reproduce your problem with/without rpcbind running on the system. > > >You can also look at the output of: > ># rpcinfo > >once it is booted, to see that rpcbind seems correctly configured. > >It should be attached to tcp, tcp6, udp, udp6 and /var/run/rpcbind.sock. > > % doas rpcinfo > rpcinfo: can't contact rpcbind: RPC: Port mapper failure - RPC: Success If you are not running rpcbind, this is normal and should not affect rpc.umntall. (It works for me without rpcbind running.) > > It's odd that beforehand, there was no error notification. > > The bootup of the client will stall with the aforementioned error, > i presume it's carrying on once the nfs server is contacted. So far, I've= not > had to ctl-C or ctl-D to get past it. Once booted up, the nfs shares are > available and writable. It doesn't affect the actual mount. An NFSv3 mount is "stateless", which me= ans the NFS server doesn't even know it exists and does not need to know. Sun came up with junk that tries to indicate what is NFS mounted using the Mount protocol (think mountd on the server). The rpc.umntall command is executed by /etc/rc.d/nfsclient and all it does is tell the server to clean= up this mount junk (only used by things like "showmount" and not NFS itself). Bottom line..it is just al little irritating and might slow down booting a = bit. Why is it happening? Don't really know, but it indicates that the client cannot talk to the NFS server at the point in booting when /etc/rc.d/nfscli= ent is executed. You can: # cd /etc; rcorder rc.conf rc.d/* and the output shows you what order the scripts in /etc/rc.d get executed. Since "nfsclient" is after NETWORKING, it should work? > > The nfs server is 14-stable and the exported dir is zfs with the sharenfs= property set. > The client (14.1-p1) is a VM on a different machine but the same network. > > I'll try putting rpcbind_enable=3DYES in /etc/rc.conf Probably won't make any difference. rick > -- >