Newbie upgrade problem (13.2-RELEASE->14.0-RELEASE) merge conflict

S

szelmi

Hi, I am quite fresh FreeBSD user, trying to get to know its ways.

I know, that it is probably an issue of me not knowing git enough, or having any serious experience with it. But I will really appreciate help with following merge conflict during my attempt to upgrade from 13.2 to 14.0.

I've started with:

freebsd-update fetch install

And it all went ok, but after executing the following:

freebsd-update -r 14.0-RELEASE upgrade

I have encountered this merge conflict, and a request to resolve it manually:

Code: 
<<<<<<< current version
# $FreeBSD$
#
wheel:*:0:root,szelmi
=======
wheel:*:0:root
>>>>>>> 14.0-RELEASE
daemon:*:1:
kmem:*:2:
sys:*:3:
tty:*:4:
operator:*:5:root
mail:*:6:
bin:*:7:
news:*:8:
man:*:9:
games:*:13:
ftp:*:14:
staff:*:20:
sshd:*:22:
smmsp:*:25:
mailnull:*:26:
guest:*:31:
video:*:44:
realtime:*:47:
idletime:*:48:
bind:*:53:
unbound:*:59:
proxy:*:62:
authpf:*:63:
_pflogd:*:64:
_dhcp:*:65:
uucp:*:66:
dialer:*:68:
network:*:69:
audit:*:77:
www:*:80:
u2f:*:116:
ntpd:*:123:
_ypldap:*:160:
hast:*:845:
tests:*:977:
nogroup:*:65533:
nobody:*:65534:
szelmi:*:1001:
messagebus:*:556:
polkitd:*:565:
avahi:*:558:
cups:*:193:
colord:*:970:
cyrus:*:60:
pulse:*:563:
pulse-access:*:564:
pulse-rt:*:557:
slurm:*:468:
syncthing:*:983:

Can anyone give me some instructions, or advice what I am supposed to do to to make this right?
 
Thanks! Based on this explanation i resolved also another conflicts that occurred. Guess next thing on the list to learn is git.:)
 
The one that caught me off guard were the pam changes. Luckily I kept ssh open in a few places to fix it. Next time I need to pay more attention to the release notes. :)
 
szelmi said:
Thanks! Based on this explanation i resolved also another conflicts that occurred. Guess next thing on the list to learn is git.:)
Click to expand...
3-way merges are not a GIT thing, specifically. 3-way merges existed in RCS, CVS, SVN, and exist in HG.

The 3-way update in freebsd-update(8) may call etcupdate(8).

3-way merges have been around since forever. The diff3(1) program, in FreeBSD base, performs 3-way diff and merges, and can be used in scripts or from the command line.
 
macer said:
The one that caught me off guard were the pam changes. Luckily I kept ssh open in a few places to fix it. Next time I need to pay more attention to the release notes. :)
Click to expand...

I have a couple of jails upgraded to 14 with bastille that:

a) now I cannot console in using "bastille console" (it works with "jexec -u").
b) MySQL cannot start anymore and error "su: pam_start: System error" shows up.

Do you have these PAM changes/fixes in hand by any chances?
 
Dnz said:
I have a couple of jails upgraded to 14 with bastille that:

a) now I cannot console in using "bastille console" (it works with "jexec -u").
b) MySQL cannot start anymore and error "su: pam_start: System error" shows up.

Do you have these PAM changes/fixes in hand by any chances?
Click to expand...
I believe the issue is that pamopie was removed. The only reason I noticed that it may be an issue was when the merge showed that it was trying to remove those lines. I guess there were upgrading notes about this. Here is what my pam.d/sshd looks like that works (I use winbind / samba for auth so you can probably disregard that part.
Code: 
#
#
# PAM configuration for the "sshd" service
#

# auth
#auth           sufficient      pam_opie.so             no_warn no_fake_prompts
#auth           requisite       pam_opieaccess.so       no_warn allow_local
auth            sufficient      /usr/local/lib/pam_winbind.so
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            required        pam_unix.so             no_warn try_first_pass

# account
account         sufficient      /usr/local/lib/pam_winbind.so
account         required        pam_nologin.so
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so              want_agent
session         required        pam_permit.so

# password
password        sufficient      /usr/local/lib/pam_winbind.so
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass
 
Reinstalling security/opie fixed the issue with MySQL and access into the 14.0 jails with BastilleBSD! Thank you for the details!

I did see the notes about opie but didn't do anything as I got confused by the fact that certain jails were fine and others I was not able to access them.
 
I had the same problem with my jails `bastille console` not working anymore after updating to 14.0
A solution for this problem was the following:

1. first make sure the `/usr/local/Bastille/releases/14.0-RELEASE/usr/src` contains the freebsd sources (I've copied them from my base system)
2. go into jail via `jexec jailname`
3. run `etcupdate` in this jail to fix ALL configuration files (not just the pam_opie-related one)
 
Last edited:
Gamecreature said:
I had the same problem with my jails `bastille console` didn't work anymore after updating to 14.0
A solution for this problems was the following:

1. first make sure the `/usr/local/Bastille/releases/14.0-RELEASE/usr/src` contains the freebsd sources (I've copied them from my base system)
2. go into jail via `jexec jailname`
3. run `etcupdate` in this jail to fix ALL configuration files (not just the opie-related one)
Click to expand...
This is why I wrote my own jails framework. Upgrades aren't well designed in thin jails if not designed at all, depending on the software. And yes, this is the solution: to have the sources in the base release and use etcupdate in each jail.
 
cy@ said:
… 3-way merges have been around since forever. The diff3(1) program, in FreeBSD base, performs 3-way diff and merges, and can be used in scripts or from the command line.
Click to expand...

Learning that pkg has 3-way merge code {link removed} was a pleasant surprise.

Vive la pkgbase révolution, mes amis.
 
Last edited:
I had the same problem while upgrading from 13.2 to 13.3.

It was something related to the /etc/group file and, out of frustration, I deleted it, thinking that it will be recreated by the upgrade process.

It did not happen but what was interesting is that the system still somehow allowed me to su to root, even after a restart. I thought that this file is required for your user to be able to switch to root.

Eventually, I installed FreeBSD 14 from scratch and all is good.
 
FWIW, I tried to upgrade 13.2 to 14 and ran into these "merge" issues for the first time.
As far as I can tell, I followed the guides and dealt with the questions posed, but I did notice that some files seemed to contain conflicts, but I wasn't given the opportunity to deal with them. Other files (seemed to me) to have conflicts described in a contradictory or at least ambiguous way.
I wound up not trusting this process - but then I am just a novice.
Anyway, the end result was just a command prompt when I was expecting to see a KDE screen.
What do you think my best options are now?
Forgive my ignorance, but if I install a new KDE windows session to this 14 instance, will the system allow me to roll back to my working 13.2 (via beadm) or will the new KDE overwrite the old one.
Please forgive my ignorance, I seldom venture into this geography of the FreeBSD system.
Maybe like many others, I should start a new session and copy the files over.
Advice please.
Many thanks,
 
Zagzigger said:
Forgive my ignorance, but if I install a new KDE windows session to this 14 instance, will the system allow me to roll back to my working 13.2 (via beadm) or will the new KDE overwrite the old one.
Click to expand...
/usr/local/ is part of the BE by default. Unless you changed this switching to an older BE would also revert your installed packages. The BE is a snapshot (both in the technical sense as a conceptual one), it's a specific point in time. Booting an older BE is like stepping back in time. You could create a new BE just before you do your package upgrade. If something's amiss you could then revert it by selecting the BE you created.

Zagzigger said:
Please forgive my ignorance, I seldom venture into this geography of the FreeBSD system.
Click to expand...
It's complicated, even if you have a good understanding. Don't be afraid to ask for clarification if something is unclear.
 
I think it is good if the handbook or other related documentation either gives explanations and examples, or points to a document that does so, when talking about running a command with topics like a 3 way merge as not knowing how to do it properly will lead to mistakes. A 3 way merge tries to avoid prompting a user to think about edits to the file unless there are customizations done to a line that is also being updated in the default file; having a tool add all varieties to its output, and add additional markers (not even as comments) means its output is not valid without editing. Edits to these files can happen from the user or base tools, from installing and using ports, and from the changes to base when upgrading; there are times when changes should be kept, should be deleted, and should be 'manually' merged.

The initial post's example was explained correctly by sirdice for what to do this time, but knowing what is being done and why is necessary to not cause mistakes in the future. the '#...' lines were deleted as they are comments from older CVS/SVN days and removed since the project migrated to git. The lines filled with '<', '>', and '=' characters are indicators to where the differences are coming from and are not intended to ever be in the final file. The first 'wheel' line is kept and the second got removed as it would remove a user from that group to go with the new line in the default configuration file. What to keep and delete will at times be different form this example.

If a line the user is not familiar with was modified by a port, it will look just like a user edit to the diff tool and should be one the user (likely) accepts. If it was just a change done to the base file and the line was not modified by the user or a port, the change should also (likely) be accepted. Once the user/port modifies a line, and base modifies it too, then the user needs to decide how a new line should look (their copy, the new copy, or something completely new which likely merges both concepts).
 
You must log in or register to reply here.
Back
Top