From nobody Sat Sep 9 19:20:25 2023 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 4RjjVp0b4Nz4smYP for ; Sat, 9 Sep 2023 19:20:34 +0000 (UTC) (envelope-from brian@sonicboom.org) Received: from sheehan.sonicboom.org (sheehan.sonicboom.org [69.75.45.53]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RjjVn289Lz4fX9 for ; Sat, 9 Sep 2023 19:20:33 +0000 (UTC) (envelope-from brian@sonicboom.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of brian@sonicboom.org designates 69.75.45.53 as permitted sender) smtp.mailfrom=brian@sonicboom.org; dmarc=none Received: from [10.10.1.112] (rrcs-69-75-45-51.west.biz.rr.com [69.75.45.51]) by sheehan.sonicboom.org (Postfix) with ESMTPSA id BA9DA3A00129 for ; Sat, 9 Sep 2023 12:20:25 -0700 (PDT) Message-ID: Date: Sat, 9 Sep 2023 12:20:25 -0700 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 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: user problems when upgrading to v15 To: freebsd-current@freebsd.org References: <5c5c3ea5-5b14-d969-f55f-b894e4983359@sonicboom.org> <46ee9e3b-adeb-4cd1-5fcc-43547c5c7231@gmail.com> <222e96ba-70b6-e976-8e32-d3726dde18b1@sonicboom.org> <7CDB341A-F9E1-4816-8443-E4C349A86C84@FreeBSD.org> <865dc0ef-a19d-876c-b0a5-03b888b531f5@FreeBSD.org> Content-Language: en-US From: brian whalen In-Reply-To: <865dc0ef-a19d-876c-b0a5-03b888b531f5@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip4:69.75.45.53]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:20001, ipnet:69.75.0.0/16, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[sonicboom.org]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[brian]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4RjjVn289Lz4fX9 Over the last week or so, stable/13, stable/14 and current have improved. Finally, I can make it through a build and install with a password on the root account and a user in the wheel group without having it fail. Brian On 9/9/2023 9:02 AM, John Baldwin wrote: > On 9/2/23 7:11 AM, Dimitry Andric wrote: >> On 1 Sep 2023, at 03:42, brian whalen wrote: >>> >>> Repeating the entire process: >>> >>> I created a 13.2 vm with 6 cores and 8GB of ram. >>> >>> Ran freebsd-update fetch and install. >>> >>> Ran pkg install git bash ccache open-vm-tools-nox11 >>> >>> Used git clone to get current and ports source files. >>> >>> Edited /etc/make.conf to use ccache >>> >>> Ran make -j6 buildworld && make -j6 kernel >>> >>> I then rebooted in single user mode and did the next steps saving >>> output to a file with > filename. >>> >>> etcupdate -p was pretty uneventful. It did  show the below and did >>> not prompt to edit. >>> >>> root@f15:~ # less etcupdatep >>>    C /etc/group >>>    C /etc/master.passwd >> >> This is a problem: the "C" characters mean there were conflicts, and >> it's indeed very unfortunate that etcupdate does not immediately >> force you to resolve them. Because now you basically have mangled >> group and master.passwd files, with conflict markers in them! > > No, the conflicted files are in /var/db/etcupdate/conflicts, the files > in /etc are still > the old ones at this point and won't be updated until you run > 'etcupdate resolve' to > fix them. > > I suspect what happened here is that Brian chose the 'tf' > (theirs-full) option for > 'etcupdate resolve' when he really wanted to do 'e' to edit the > conflicted version. > >> Immediately after this, you should run "etcupdate resolve", and fix >> any conflicts that it has found. >> >> Note that recently there was a lot of churn due to the removal of >> $FreeBSD$ keywords, and this almost always creates conflicts in the >> group and passwd files. For lots of other files in /etc, the >> conflicts are resolved automatically, but unfortunately not for the >> files that are essential to log in! >> >> >>> make installworld seemed mostly error free though I did see a >>> nonzero status for a man page failed inn the man4 directory. >>> >>> etcupdate -B only showed the below. This was my first build after >>> install. >>> >>> root@f15:~ # less etcupdateB >>> Conflicts remain from previous update, aborting. >> >> Yes, that is indeed the problem. You must first resolve conflicts >> from any previous etcupdate run, before doing anything else. As to >> why it does not immediately forces you to do so, and delegates this >> to a separate step, which can easily be forgotten, I have no idea. > > So that if you are doing scripted upgrades, you don't hang forever in > a script. > The intention is that after doing a bunch of scripted installworld + > etcupdate's > on various hosts you can use 'etcupdate status' to see if there are > any remaining > steps requiring manual intervention. > > There could be an option to request batched vs interactivate updates > perhaps. > >>> If I type exit in single user mode to go multi user mode, the local >>> user still works. After a reboot the local user still works. This >>> local user can also sudo as expected. This wasn't the case for the >>> previous build when I first reported this. However, if I run >>> etcupdate resolve it is still presenting /etc/group and >>> /etc/master/passwd as problems. >>> >>> If this is is expected behavior for current then no big deal. I just >>> wasn't sure. >> >> The conflicts themselves are expected, alas. But you _must_ resolve >> them, otherwise you can end up with a mostly-bricked system. > > No, the conflict markers are not placed in the versions in /etc. > However, etucpdate > does refuse to do a "new" upgrade until you resolve all the conflicts > from your > previous upgrade to ensure that conflicted upgrades aren't missed. >