From nobody Wed Dec 8 17:11:05 2021 X-Original-To: freebsd-current@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 2A2A518D45DF for ; Wed, 8 Dec 2021 17:11:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8Nwp6KLDz4kts; Wed, 8 Dec 2021 17:11:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4E112356A9; Wed, 8 Dec 2021 17:11:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> Date: Wed, 8 Dec 2021 09:11:05 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Content-Language: en-US To: Tomoaki AOKI , freebsd-current@freebsd.org Cc: jbtakk@iherebuywisely.com References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> From: John Baldwin In-Reply-To: <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638983466; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ePy6/FJqGb+pByS2AZLAiR3onRZCN8fc9onVy4kipyE=; b=pW4mYATTLddG5cIVQ2HzTq6i7kgVhTX7YiXD1oYFER3kPWx/tZ7+IqWS6hOnxW72hMjWas 4BYU8wnnVyxyDQjeurQX92FdKHk4b+1WRMWsdWzY6xwBwkGAfSJkmKnGE68Kk+DrPgOEjx zJ1swj42LCPxptKZ3E5D+saOjeFP+ZWZgDVckaCx5RhJgl4EkOSvIjN1p5NjBu/E70WRIU iwBOpvKSJOn6dfHC4toAk3kLhANYZzeqlbwxG8tarvos2/LI268cecl9JaLMMvXC1gNEyl 0rOiWaZuOWQLNU90VszTmBqmzZZsQqJ1i7ZLASk5rgxQXLyssdAgVptcgLuKMw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638983466; a=rsa-sha256; cv=none; b=c9tex3uzk949KpR+6/x2Z5lTw0wsXL0EUBjVJfSpzbharu+ohwm8uWskHlXGuFkL3NfDW+ dBI4W2FMIpKXo85gKlNBcGxGeRf0uG5zwpwYn5jnT8uT9lIW0QakJ+vpUjqZIPswamJ5d2 Q9QVpOrcl42ovPwFDwhSjDCj9yUkBJfI1TeTSUVd465XDyhNI759B++gTZaflTczSp/bkM dN1pVUw0QXn/ArcTrpBH3koRDchAA6o5D/osGHTABiql+w2ZkmQ1mOdG/GO47gDNGdVULq wo1FCUVIB/vqFb3g0JUDv5LxvxuuPROcthxI7ws/o5AhM9rA+tR9zW6e5jtyXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/3/21 6:09 PM, Tomoaki AOKI wrote: > On Fri, 03 Dec 2021 05:54:37 -0800 (PST) > "Jeffrey Bouquet" wrote: > >> >> >> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >>> On 03/12/2021 12:52, Yetoo Happy wrote: >>> >>> [...] >>> >>>> Quick Start* and follow the instructions and get to step >>>> 7 and may think that even though etcupdate is different from mergemaster >>>> from the last time they used the handbook they have faith that following >>>> the instructions won't brick their system. This user will instead find that >>>> faith in general is just a very complex facade for the pain and suffering >>>> of not following *24.5.6.1 Merging Configuration Files* because the user >>>> doesn't know that step exists or relevant to the current step and ends up >>>> unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top >>>> of the user's very important configuration files that they didn't expect >>>> the program to actually modify that way when they resolved differences nor >>>> could they predict easily because the diff format is so unintuitive and >>>> different from mergemaster. Now unable to login or boot into single user >>>> mode because redirections instead of the actual configuration is parsed the >>>> user goes to the handbook to find out what might have happened and scrolls >>>> down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. >>> >>> [...] >>> >>> That's why I think etcupdate is not so intuitive as tool like this >>> should be and etcupdate is extremely dangerous because it intentionally >>> breaks syntax of files vital to have system up and running. >>> If anything goes wrong with mergemaster automatic process then your have >>> configuration not updated which is almost always fine to boot the system >>> and fix it. But after etcupdate? Much worse... >>> >>> I maintain about 30 machines for 2 decades and had problems with >>> etcupdate many times. I had ti use mergemaster as fall back many times. >>> Mainly because of etcupdate said "Reference tree to diff against >>> unavailable" or "No previous tree to compare against, a sane comparison >>> is not possible.". And sometimes because etcupdate cannot automatically >>> update many files in /etc/rc.d and manual merging of a lot of files with >>> "<<<< ==== >>>>" is realy painful while with mergemaster only simple >>> keyboard shortcuts will solve it. >>> All of this must be very stressful for beginners. >>> >>> So beside the update of documentation I really would like to see some >>> changes to etcupdate workflow where files are modified in temporary >>> location and moved to destination only if they do not contain any syntax >>> breaking changes like <<<<, ====, >>>>. >>> >>> Kind regards >>> Miroslav Lachman >> >> >> Agree. I fell back to mergemaster this Nov on 13-stable when the /var files >> pertaining to etcupdate were all missing current /etc data, and no study of >> man etcupdate was clear enough to rectify such a scenario, and suspect my >> initial use of etcupdate will or may require a planned reinstall, not having >> had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and >> I am just hoping mergemaster stays in /usr/src and updated >> for system changes, even if moved to 'tools' or >> something, since its use seems intuitive and much less of a black box. >> Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. >> > > Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) > option of etcupdate is now quite harmful. Maybe by any commit done in > this april on main (MFC'ed to stable/13 in june). > > *I got busy manually checking and applying changes to /etc, and > forgot to file PR. > > Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does > NOT do anything, hence nothing is actually updated. > The only workaround I have is NOT to try dry-run. Humm. > It would be because the same trees are used for dry-run and actual run. > (Not looked into the code. Just a thought.) So the new changes always build a temporary tree (vs trying to build /var/db/etupdate/current in place). For -n it should be that it just doesn't change /var/db/etcupdate/current at the end, but if it did the move anyway that would explain the bug you are seeing. That does indeed look broken. Please file a PR as a reminder for me to fix it. -- John Baldwin