Solved No previous tree to compare against, a sane comparison is not possible OR no output from etcupdate.

Hello.

Sometimes,when I attempt to upgrade FreeBSD from source,I see that the differences aren't merged and I get the error "No previous tree to compare against, a sane comparison is not possible" OR I get no output from etcupdate -p and -B. I never understood the reason. But I think that's not a good sign. This is the procedure that I follow if I want to upgrade 14.0-RELEASE to 14.1-RELEASE :

Code:
# zfs rename zroot3/usr/src zroot3/usr/src-old
# zfs create zroot3/usr/src
# zfs set mountpoint=/usr/src zroot3/usr/src
# git clone --depth 1 https://git.FreeBSD.org/src.git /usr/src
# cd /usr/src
# git checkout releng/14.1
# make -j8 buildworld
# make -j8 kernel
# shutdown -r now
# cd /usr/src
# etcupdate -p
nothing

# make installworld
.....
--------------------------------------------------------------
>>> Installing everything completed on Fri Jul 19 03:35:58 CEST 2024
--------------------------------------------------------------
       67,27 real        34,87 user        18,78 sys
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Skipping untrusted certificate /usr/share/certs/trusted/Cybertrust_Global_Root.pem (/etc/ssl/untrusted/76cb8f92.0)
Skipping untrusted certificate /usr/share/certs/trusted/DST_Root_CA_X3.pem (/etc/ssl/untrusted/2e5ac55d.0)
Skipping untrusted certificate /usr/share/certs/trusted/E-Tugra_Certification_Authority.pem (/etc/ssl/untrusted/5273a94c.0)
Skipping untrusted certificate /usr/share/certs/trusted/E-Tugra_Global_Root_CA_ECC_v3.pem (/etc/ssl/untrusted/5a7722fb.0)
Skipping untrusted certificate /usr/share/certs/trusted/E-Tugra_Global_Root_CA_RSA_v3.pem (/etc/ssl/untrusted/66445960.0)
Skipping untrusted certificate /usr/share/certs/trusted/GlobalSign_Root_CA_-_R2.pem (/etc/ssl/untrusted/4a6481c9.0)
Skipping untrusted certificate /usr/share/certs/trusted/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem (/etc/ssl/untrusted/1636090b.0)
Skipping untrusted certificate /usr/share/certs/trusted/Hongkong_Post_Root_CA_1.pem (/etc/ssl/untrusted/3e45d192.0)
Skipping untrusted certificate /usr/share/certs/trusted/Network_Solutions_Certificate_Authority.pem (/etc/ssl/untrusted/4304c5e5.0)
Skipping untrusted certificate /usr/share/certs/trusted/Security_Communication_Root_CA.pem (/etc/ssl/untrusted/f3377b1b.0)
Skipping untrusted certificate /usr/share/certs/trusted/Staat_der_Nederlanden_EV_Root_CA.pem (/etc/ssl/untrusted/03179a64.0)
Skipping untrusted certificate /usr/share/certs/trusted/TrustCor_ECA-1.pem (/etc/ssl/untrusted/7aaf71c0.0)
Skipping untrusted certificate /usr/share/certs/trusted/TrustCor_RootCert_CA-1.pem (/etc/ssl/untrusted/5d3033c5.0)
Skipping untrusted certificate /usr/share/certs/trusted/TrustCor_RootCert_CA-2.pem (/etc/ssl/untrusted/3e44d2f7.0)
Scanning /usr/local/share/certs for certificates...

[root@marietto /usr/src]==> etcupdate -B
nothing

# shutdown -r now
# cd /usr/src
# etcupdate resolve
nothing

In any case,I've been able to upgrade to 14.1 :

Code:
[root@marietto /usr/src]==> uname -a
FreeBSD marietto 14.1-RELEASE-p2 FreeBSD 14.1-RELEASE-p2 releng/14.1-n267685-dcdea9e8623e GENERIC amd64

But I suspect that the system hasn't been upgraded properly and it could have problems in the future. I read that the command :

Code:
# etcupdate extract

could help,but I don't understand how. I made a backup of the old 14.0-p6 system,so I have the content of /usr/src saved in a separate directory. Maybe to have the sources of 14.0 and 14.1 can help,in some way,to extract and to merge the differences ?

I don't want to restore the backup of the 14.0 and try again to upgrade it because in the meantime I've personalized the 14.1.
 
Not all minor version upgrades have changes in /etc/ too. So it's entirely possible nothing needs updating. Or a previous invocation of etcupdate(8) already fixed things, so additional runs won't change anything.
 
Point is that I know there are differences,because I have upgraded another (UFS) system from 14 to 14.1 and it produced some files (that I have attached in a previous post). So,Im sure that if something is broken,etcupdate will produce nothing. It's not the first time that I don't see differences,but there were.
 
Istantanea_2024-07-19_17-20-45.png
 
Moral of the story backup /etc , /usr/local/etc. Do your stuff. And put it back or fix it.
A few command lines and you are ready to go.
What's in my /etc :
- rc.conf
- rc.local
- sysctl.conf
- passwd
 
Since I didn't see it mentioned, I thought the error means steps to bootstrap etcupdate weren't performed or its not working correctly if those steps had been performed. etcupdate needs to see a tree representing the current system install before being given a an updated tree for the upcoming install as it does a 3 way merge.
 
Since I didn't see it mentioned, I thought the error means steps to bootstrap etcupdate weren't performed or its not working correctly if those steps had been performed. etcupdate needs to see a tree representing the current system install before being given a an updated tree for the upcoming install as it does a 3 way merge.

Mirror176 ,my Reddit friend...you are welcome here. The point of the thread was if is possible to extract the "etc" differences having the old and the new srcs. It is mentioned the command "etcupdate extract",but its hard for me to understand how it works. The handbook is not clear on this point and I don't understand how to do it. As you can see,the system admins here don't care so much about this problem or they found some handy tecniques,but not reccomended or explained officially.
 
My previous post was just to try to answer why the error is seen which I didn't see anywhere in this thread.

The official documentation only talks of doing the bootstrap as the first run step and doing it with code for the current install being available and before an upgrade gets installed. The John Baldwin response sounds logical though tedious. etcupdate's bootstrapping manpage section reiterates that but implies it is only for the case of having the current source tree before installing from a new tree is done. They shoudl expand to include explanation other than "The easiest way to ensure this..." If the only way to bootstrap it after updates were installed without the bootstrap is a tedious way then I'd accept that, but I really wish it was documented clearly too.

The more I think about it, the more I think the bootstrapping manpage steps are right, though generically stated. With a source tree representing the current install run `etcupdate extract&&etcupdate diff` and review its output; change things until it only contains output for changes you know you want on the system. You can run `etcupdate diff` more than once to confirm your changes are bringing the current machine to be more aligned with what the source tree would have provided instead of having typos that still make it different. Once it contains only differences you intended (or maybe packages you installed intended) then you should be in a cleaned up and good to go state.

If still unsure about some file changes, you could extract and compare relevant files from the appropriate source trees, read their git logs, setup comparable installs in a virtual machine and test their changes as updates are applied using any known good update technique or just ask in public places such as this. Blowing away a change just because it isn't understood could be bad if it was changed for you by the installer or another program (ex. master.passwd and group files are often edited through other tools so not knowing they are intentionally changed for you could be annoying to devastating).
 
is only for the case of having the current source tree before installing from a new tree is done.

Usually when I upgrade the system using the source code I rename the old src in src-old. And I get the new src using git and it will go in src. So,how can the script knows that the old src is in src-old ?
 
In the link below :


you see what are the differences that have been extracted when I have upgraded 14.0-RELEASE to 14.1-RELEASE on a new /UFS/ system. 14.1 files have a different structure than 14.0. So,what should I do ? Should I overwrite the latter with the first ones ?
 
Usually when I upgrade the system using the source code I rename the old src in src-old. And I get the new src using git and it will go in src. So,how can the script knows that the old src is in src-old ?
My understanding is you only point etcupdate at the one "current" tree. It makes copies of what it needs. You then update the tree and it doesn't need to see the old tree still because it has copies of what it could care about from it so that upgrading the tree now has 3 points of reference for files: old tree, new tree, currently installed.

If you need to change that "one" path where it looks for source code, `etcupdate -s /usr/src.old <insert other options as needed>` would work, but etcupdate doesn't need to see the old src folder unless you are building+installing that old version or if you are bootstrapping etcupdate and that is the version your system has currently installed.

If you have a complete git checkout of the source tree, you can save disk space if you know what the hash of your older checkouts are. `git -C /usr/src revparse @` and `git -C /usr/src.old revparse @` should show those current hashes. You could then use git checkout to change to your older or newer commit and can create a branch at the old hash if you need to do more than just read an old state. I admit I've carried around more than one tree, builddirectory, etc. on numerous occasions.
In the link below :


you see what are the differences that have been extracted when I have upgraded 14.0-RELEASE to 14.1-RELEASE on a new /UFS/ system. 14.1 files have a different structure than 14.0. So,what should I do ? Should I overwrite the latter with the first ones ?
I'm not sure which 'different structure' you are referring to. I'm not used to google drive but what would help is seeing something like a diff of the old to the new, or the etcupdate diff (censored for sensitive things like passwords, users, addresses, etc. if its a public facing machine). diff output tells you what lines/files/folders to edit/add/remove to go from the first to the second. Files you modified need to be reviewed so that you have your changes applied to the new file (unless no longer relevant/corrent). Files you, and another tool, didn't modify, should normally be changed to the new files locations/contents. If you disagree with a change that FreeBSD has made as an update, then keep the old bits as desired; any changes you make do change how the system works and changes what may need merge conflicts reviewed/resolved in furture merges but that is no different than 'any' edits to the configurations.
 
For example,let's get one random file. One of them comes from 14.0 and the other one from the 14.1. Their content is different. And I'm not talking about my sensible informations,but about the code :

a) termcap.small : https://pastebin.ubuntu.com/p/f4RBcgymWf/
b) termcap.small : https://pastebin.ubuntu.com/p/NthBtkKDfj/

When I've upgraded 14.0 to 14.1 it extracted 20 or more new files that I think I should use on 14.1 because their code is different from the code of the same files used on the 14.0...
 
Back
Top