On 1 Sep 2023, at 03:42, brian whalen <br...@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! 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. > > 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. -Dimitry
signature.asc
Description: Message signed with OpenPGP
