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 79D2E158042 for ; Tue, 5 Nov 2024 16:28:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE2C5E07E6; Tue, 5 Nov 2024 16:28:04 +0000 (UTC) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4BF05E07A5 for ; Tue, 5 Nov 2024 16:28:02 +0000 (UTC) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 4A5GRvbo000782 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 5 Nov 2024 10:27:58 -0600 Message-ID: Date: Tue, 5 Nov 2024 10:27:57 -0600 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [gentoo-user] Getting tar to keep going Content-Language: en-US To: gentoo-user@lists.gentoo.org References: <2962590.e9J7NaK4W3@cube> From: Grant Taylor In-Reply-To: <2962590.e9J7NaK4W3@cube> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: e94a0b72-937e-4f27-a877-7b7d1e1fbfa3 X-Archives-Hash: 057b159bc2b15f7fe12cd1c3ac58462c On 11/5/24 9:38 AM, Peter Humphrey wrote: > The Network Manager man page says to 'chattr +i /etc/resolv.conf', > so I did, and that one move enabled the wireless network to work as > it should. What?!?!?! Network Manager can't be made to keep it's hands off of /etc/resolv.conf so the workaround is to leverage file system features to break Network Manager's hands when it tries to touch the file? That's a hell of a bad design in my opinion. The tar error will be related to the restore / write to disk, not reading from ""tape or command error. You might explore an option to cause tar to exclude /etc/resolv.conf from the restore job. I'm not sure what that would look like as I'm usually only messing with exclude during backups. You might be able to mess with some even more esoteric (bind) mount options, but that will be quite similar to the chattr dance. I'd go smack Network Manager with a bigger bat. -- Grant. . . .