Re: user problems when upgrading to v15

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.

-- 
John Baldwin