Solved How to resume freebsd-update process after replying no to "does this look reasonable"?

Hello,

I am currently upgrading a server from FreeBSD 13.3 to FreeBSD 14.1, I followed the instructions mentioned on that page and have reached the stage where `freebsd-update upgrade -r 14.1-RELEASE` is being executed. It proceeded to download all patch files and apply them.

I've solved a couple of merge issues manually, then it presented me automatically merged files and asked me if it looked reasonable. I answered no for /etc/passwd since the shell of root had been changed from csh to sh and I wanted to keep consistent with master.passwd for fear of being unable to log as root. However after replying no, the freebsd-update process exited 😅

Code:
The following changes, which occurred between FreeBSD 13.3-RELEASE and
FreeBSD 14.1-RELEASE have been merged into /etc/passwd:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-root:*:0:0:Charlie &:/root:/bin/csh
+root:*:0:0:Charlie &:/root:/bin/sh
 toor:*:0:0:Bourne-again Superuser:/root:
 daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
 operator:*:2:5:System &:/:/usr/sbin/nologin
 bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
 tty:*:4:65533:Tty Sandbox:/:/usr/sbin/nologin
Does this look reasonable (y/n)? n

So I have two questions:
1. How can i merge the file manually? (since apparently /etc/passwd is still untouched)
2. And how can i resume the freebsd-update process where i left it without screwing everything up? I haven't run yet freebsd-install after running the `upgrade` command since the upgrade command wasn't completed yet.

Many thanks
 
Oh searched if a similar topic existed before posting but haven't used the right keyword I guess since someone asked a similar question here
Hopefully our threads can be merged, however my questions are not answered in the other thread
 
I been here and it hurts. I had to recreate root account. Backing up the files didn't do it. vipw is a must. It writes out to the db.

 
Mmh, I don't think I am in this situation since the update has not been installed yet as I haven't run `freebsd-update install`
 
It proceeded to download all patch files and apply them.
The freebsd-update -r <version> upgrade stage doesn't apply anything. It prepares everything, things only get applied with freebsd-update install.

If you want to re-do it, just run freebsd-update -r <version> upgrade again.
 
SirDice Thanks a lot this is reassuring, but then I'll be met with the same issue with the merge of the /etc/passwd file, how can i edit this file manually without interrupting the whole upgrade process?
 
Just fix the merge issue that comes up. It's really not that difficult. If you have problems with vi(1) (understandable), set the EDITOR environment variable to your favorite editor before running freebsd-update(8).
 
SirDice I have successfully fixed merge issues using vi as part of the upgrade process, my problem actually is that I am not offered to fix the merge manually. I was offered to fix two merges, which I have done, then for the /etc/passwd file, it tried to merge the file automatically.

When i replied that the file does not look reasonable, I expected to be offered to fix the merge manually but the freebsd-update process exited instead (I have copy-and-pasted the output of the console in my original message)
 
The /etc/passwd file isn't actually used, it's generated from master.passwd. The file just exists for some truly arcane backwards compatibility.
 
What I thought is that RE should have created a specially crafted tool just for this change before etcupdate(8) is called. Which does:
  1. Ask admin to change root shell from /bin/csh to /bin/sh or not.
  2. Forcibly fix "current" tree to be use /bin/sh for root.
  3. Only if yes, chsh -s /bin/sh as root.
The problem is because default shell for root was changed from /bin/csh to /bin/sh.
etcupdate(8) compares previous, current and installed files with 3-way diff, line per line. And if root sanely has password, it surely conflicts.
If a sluggish admin kept root password empty, this problem cannot happen.

And more, when etcupdate(8) runs for actual merge, it removes existing "previous" tree and moves "current" tree to "previous", and rebuilds "current" tree from src.
So if, before etcupdate(8) is invoked, /etc/master.passwd in "current" tree is modified to default to /bin/sh for root shell, /etc/master/passwd of rotated "previous" tree and created "current" tree matches, thus installed /etc/master.passwd should be considered as "user modified", not conflicting.
 
Thanks a lot to both of you, also as my adrenaline levels are lowering I am realizing that I can also edit /etc/passwd manually before rebooting after running `freebsd-update install`. Just out of curiosity, from i understand of SirDice 's comment, having a different default for root in /etc/master.passwd and /etc/passwd shouldn't be a big deal anyway, isn't it?
 
Yes, because /etc/passwd isn't used for anything anymore. So it really doesn't matter what's in it. You do have to be careful merging/editing master.passwd though. And you can simply recreate /etc/passwd by running /usr/sbin/pwd_mkdb -p /etc/master.passwd (assuming master.passwd is correct)

Code:
     The passwd file is generated from the master.passwd file by pwd_mkdb(8),
     has the class, change, and expire fields removed, and the password field
     replaced by a ‘*’ character.
passwd(5)

Code:
     -p    Create a Version 7 style password file and install it into
           /etc/passwd.
{...}
EXAMPLES
     Regenerate the password database after manually editing or replacing the
     password file:

            /usr/sbin/pwd_mkdb -p /etc/master.passwd
pwd_mkdb(8)
 
Yes, because /etc/passwd isn't used for anything anymore.
In base, would be correct.
Not sure for something in ports.
And old enough in-the-wild programs/scripts could depend on old style /etc/passwd. So keeping /etc/passwd in sync with /etc/master.passwd is the safe way if you're not 100% sure.
 
And old enough in-the-wild programs/scripts could depend on old style /etc/passwd.
Probably nothing, as this would go terribly wrong when using NIS, LDAP or some other form of user database. The only things I've seen that would try to read /etc/passwd directly are proof of concept exploits ;)

So keeping /etc/passwd in sync with /etc/master.passwd is the safe way if you're not 100% sure.
Certainly. But I wouldn't fret too much over the merge during a freebsd-update(8). Because you can simply re-generate a proper one.

Also worth noting here, there are backup master.passwd files in /var/backups/
 
I am glad to report that the upgrade has been successful, I have just ignored the changed default shell for root in /etc/passwd but was very careful with the manual merge of master.passwd. I will try running /usr/sbin/pwd_mkdb -p /etc/master.passwd some day when my adrenaline levels are back to normal, and probably only if the need arises 😅
Thank you all for your help with this!
 
Back
Top