Is there a way to acceptably update a source-built system with freebsd-update?

[Chris236]

Hi,

some time ago i posted here about my trouble doing a simple version upgrade. And I got no suggestions beside well, do upgrade from source.
Investigating further I saw this had been done in the past as well.

So right now I'm building 11.2 on that box, with no modifications from standard source.
Question - will I then be able to painlessly upgrade from there with freebsd-update?

Stumbling block last time was that freebsd-update forced me to manually "merge" any single file under etc, something that would have cost me days to do and with many errors.

What is the proper way to get a system built from source work with freebsd-update?

Regards

Chris

 

[SirDice]

It's simple really, you can use freebsd-update(8) on -RELEASE versions only. You can use it to update a -RELEASE or to upgrade from one -RELEASE to another. It doesn't matter how the -RELEASE version was originally built, as long as it's a -RELEASE version.

So right now I'm building 11.2 on that box, with no modifications from standard source.

If it's a source from /base/releng/11.2, it will work. You might get a discrepancy with the kernel version though. If you build the kernel from source you will get the new patch version. The binary upgrade may have a different patch number for the kernel. If the last patch didn't update the the kernel the kernel would have a lower patch version. But this is just superficial, it's only the version string that's different. It's just something you need to be aware of, in case you're wondering why freebsd-update(8) replaced your kernel with a lower patch number version than the one you originally had installed.

At the moment this shouldn't be the case, both userland and kernel should have a p9 patch number.

 

[Terry_Kennedy]

What is the proper way to get a system built from source work with freebsd-update?

It really isn't meant to work that way. You can try to force it to, but there's no guarantee that something won't be missed and cause problems, either immediately or down the line.

I don't think the internals of freebsd-update(8) have been concisely described. Here's what I figured out when I decided not to use it.

For a given release "A" and a given release "B", freebsd-update creates a list of changed files. Whenever anyone on release "A" runs freebsd-update and wants to get to release "B", freebsd-update gives them all of the changed files (some of which, like in /etc, require user intervention).

This was one of the purposes of the "Reproducible Builds" project - to ensure that everyone running the same release had identical binary files.

If you build your own kernel, you likely did it for something more than an intellectual exercise, and have introduced intentional differences between the copy of "release A" on your system and the copy that freebsd-update is working with. How well it works depends on what those changes are. To complicate things, if you track -STABLE you may get a bunch of related changes (a common example is a driver and its manpage, but things like a kernel change and a library change also happen). If freebsd-update happens to include a security fix in the kernel, but not the library, the kernel change you have will be undone and you'll have a library looking for something in the kernel that either isn't there or works differently.

 

[xtaz]

I've done this before but it's a bit of a hassle. My method to move from -STABLE to -RELEASE and then use freebsd-update(8) was to check out the source for the -RELEASE and build/install that. In theory at that point most things should be the same but some things will still be different.

Run freebsd-update IDS and wait a while. This will show a list of files where the hash doesn't match what is expected. If you believe it safe to do so then cp -p the file from the src.txz over the top, change any permissions accordingly etc. and do what is needed so that when you next run freebsd-update IDS it shows no differences in files except for ones that you know you have changed on purpose like some of the files in /etc. At this point you can use freebsd-update(8) as normal.

Note the src.txz can be fetched from a directory such as http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.0-RELEASE/.

The other thing to be aware of is that downgrading isn't usually supported. So going from 12.0-STABLE to 12.0-RELEASE will count as a downgrade. Although as long as the difference isn't too large it should work fine.

 

[Chris236]

Well... upgrade is done. A question though - it seems i wasnt able to replace the boot loader.

in UPDATING it states you need to do make -C sys/boot install after installing the new kernel.

Unfortunately, in the 11.2 src tree I got there isn't anything in sys/boot (I had checked it out fresh via svnlite checkout https://svn.freebsd.org/base/releng/11.2)

I am not sure if that is a bug - I have a few strange messages during boot but everything works.

If you build your own kernel, you likely did it for something more than an intellectual exercise, and have introduced intentional differences between the copy of "release A" on your system and the copy that freebsd-update is working with.

Nah, you are overthinking that. If you read my first post, the source upgrade was simply the fallback because the binary upgrade would not work acceptably.

If freebsd-update happens to include a security fix in the kernel, but not the library, the kernel change you have will be undone

I'm aware of that. I've been doing source upgrades for decades (started with Freebsd in the early 90s), but less so once freebsd-upgrade became usable around 8.x or 9.x . Once you work with a changed kernel, you can not use freebsd-update. But these days GENERIC is just fine - it has been years since I actually needed or wanted a hand-configured kernel.