Re: user problems when upgrading to v15

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.
>