Date: Sat, 9 Sep 2023 12:20:25 -0700 From: brian whalen <brian@sonicboom.org> To: freebsd-current@freebsd.org Subject: Re: user problems when upgrading to v15 Message-ID: <a75976b3-3bfb-68d7-d179-426f4508c84d@sonicboom.org> In-Reply-To: <865dc0ef-a19d-876c-b0a5-03b888b531f5@FreeBSD.org> References: <5c5c3ea5-5b14-d969-f55f-b894e4983359@sonicboom.org> <e96bef2d-5b16-f97d-4da2-6e78a3e8f0d7@sonicboom.org> <46ee9e3b-adeb-4cd1-5fcc-43547c5c7231@gmail.com> <222e96ba-70b6-e976-8e32-d3726dde18b1@sonicboom.org> <f2f3942e-7e66-1c5b-5702-ec83f0c71cb9@gmail.com> <fa5fdd87-9b32-6036-98f7-40a56ee65d33@sonicboom.org> <7CDB341A-F9E1-4816-8443-E4C349A86C84@FreeBSD.org> <865dc0ef-a19d-876c-b0a5-03b888b531f5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <brian@sonicboom.org> 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a75976b3-3bfb-68d7-d179-426f4508c84d>