From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2A9D9158042 for ; Tue, 22 Oct 2024 21:07:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 740CFE08FC; Tue, 22 Oct 2024 21:07:09 +0000 (UTC) Received: from smarthost01a.ixn.mail.zen.net.uk (smarthost01a.ixn.mail.zen.net.uk [212.23.1.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2CF62E08E2 for ; Tue, 22 Oct 2024 21:07:07 +0000 (UTC) Received: from [82.69.80.10] (helo=cube.localnet) by smarthost01a.ixn.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1t3M5o-000w6v-M6 for gentoo-user@lists.gentoo.org; Tue, 22 Oct 2024 21:07:06 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] NFS mounting Date: Tue, 22 Oct 2024 22:07:06 +0100 Message-ID: <3849893.kQq0lBPeGt@cube> In-Reply-To: <3325383.44csPzL39Z@rogueboard> References: <3325383.44csPzL39Z@rogueboard> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Originating-smarthost01a-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 07b63211-4009-4c31-bb21-62709bdd1b64 X-Archives-Hash: 4cb1d8d5de00d8783d9610655d8a4dac On Tuesday 22 October 2024 20:29:14 BST Michael wrote: > On Tuesday 22 October 2024 18:01:55 BST Matt Jolly wrote: > > It should not matter; the virtual root involves bind mounting directories > > into a single location - that could be 4 different partitions, a bunch of > > subvolumes, or some directories scattered across a single partition, or > > some combination of those options. > > All good and fair, but then why Peter's reported error of duplicate exports? I don't understand that either. Well, it's just one thing actually: it looks as though the remote mount still isn't right, so that some transfers just seem to vanish down a black hole. Now I have the NFS mounting working, apparently, with no reported errors, but I still can't get the combined system to behave. I mount the i5's portage tree and packages directory on a partition on the M9, chroot into it, 'env-update && . /etc/profile' and attempt to 'emerge --sync' (this is using the Git method). Everything starts to go well, and gkrellm on the i5 shows plausible network traffic on both machines - but no disk transfers. This goes on for a couple of minutes until I give up. Before starting any of that I recovered a backup of the i5 and untarred it into the chroot partition; not the whole thing, just the root FS and /var, which I've kept separate for many years. Oh, and /usr/local. The backup was just two days old. While bug-hunting, I created two new partitions on the i5: one each for the portage tree and the packages directory. That was to eliminate the possibility that the NFS mount was failing because it wasn't at a file-system root. Also while bug-hunting, I found an extra-long Ethernet cable and strung the i5 into the LAN that way. The M9 only ever sees the LAN, whereas I can now start and stop the LAN and WLAN at will on the i5. The Fritz!Box router sits at the junction. Eventually, of course, once I get this setup working, the cable will go back in the cupboard. -- Regards, Peter.