Created attachment 265771 [details] full log of frebsd-install Install on top of 14.3: # freebsd-update upgrade -r 15.0-RELEASE Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 14.3-RELEASE from update2.freebsd.org... done. Fetching metadata index... done. Fetching 2 metadata patches.. done. Applying metadata patches... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic kernel/generic-dbg src/src world/base world/lib32 The following components of FreeBSD do not seem to be installed: world/base-dbg world/lib32-dbg Does this look reasonable (y/n)? y Fetching metadata signature for 15.0-RELEASE from update2.freebsd.org... done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. Fetching files from 14.3-RELEASE for merging... done. Preparing to download files... done. Fetching 30696 patches.....10....20....30 ..... done. Applying patches... done. Fetching 10867 files... ... .10860... done. Attempting to automatically merge changes in files... done. The following changes, which occurred between FreeBSD 14.3-RELEASE and FreeBSD 15.0-RELEASE have been merged into /etc/ttys: --- current version +++ new version @@ -1,8 +1,5 @@ -# -# @(#)ttys 5.1 (Berkeley) 4/17/89 -# # This file specifies various information about terminals on the system. # It is used by several different programs. Common entries for the # various columns include: # # name The name of the terminal device. Does this look reasonable (y/n)? y The following files will be removed as part of updating to 15.0-RELEASE-p0: /.cshrc ... /var/db/etcupdate/current/etc/rc.d/virtual_oss /var/db/krb5kdc The following files will be updated as part of updating to 15.0-RELEASE-p0: /COPYRIGHT /bin/[ /bin/cat ... /var/db/etcupdate/current/root/.shrc To install the downloaded upgrades, run 'freebsd-update [options] install'. root@freebsd-14-3:/home/vova # freebsd-update install Creating snapshot of existing boot environment... done. Installing updates... Kernel updates have been installed. Please reboot and run 'freebsd-update [options] install' again to finish installing updates. root@freebsd-14-3:/home/vova # shutdown -r now Shutdown NOW! shutdown: [pid 55483] root@freebsd-14-3:/home/vova # *** FINAL System shutdown message from vova@freebsd-14-3 *** System going down IMMEDIATELY *** FINAL System shutdown message from vova@freebsd-14-3 *** System going down IMMEDIATELY System shutdown time has arrived # freebsd-update install Creating snapshot of existing boot environment... done. Installing updates...ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7" ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7"
that gives me second-hand cringe
did you apply the freebsd-update errata https://www.freebsd.org/security/advisories/FreeBSD-EN-25:18.freebsd-update.asc before upgrading?
(In reply to ivy from comment #2) I did not, But what was the point to allow freebsd-update to break the system? A bet a lot of ppl who doing binary updates will hit this wall!?
before updating: % uname -UK 1403000 1403000 % uname -a FreeBSD freebsd-14-3 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC arm64
for the truth, handbook ecourages to install security/errata first: https://docs.freebsd.org/en/books/handbook/cutting-edge/#freebsdupdate-upgrade ``` Before upgrading to a new version, ensure the existing FreeBSD installation is up to date with respect to security and errata patches: # freebsd-update fetch # freebsd-update install The following command, when run on a FreeBSD 13.1 system, will upgrade it to FreeBSD 13.2: # freebsd-update -r 13.2-RELEASE upgrade ... ```
Installing 15.0-RELEASE on top of 14.3 with all updates installed went fine. but newertheless, freebsd-update as minimum should warn about such breaking changes, better require enforcement with --currently-running
to be honest, i can't take this PR seriously when you put "kindergarten" in the title. what is your point there?
(In reply to ivy from comment #7) I would consider this installation scenario quite likely for FreeBSD users. Given that it can break the entire installation process and require recovery, it would be very helpful if freebsd-update included safeguards to prevent such issues. as for title, I've removed non-relevant "kindergarten", which just expressed my distress - I’ve always known FreeBSD as a very reliable OS, so discovering such an easy way to break upgrade was quite upsetting for me. I’m sorry if I unintentionally offended anyone.
Also, the issue mentioned on webpage: https://www.freebsd.org/releases/15.0R/installation/ but I can't find any mentions in /usr/src/UPDATING - what I usually read before rollout new version ...
<https://www.freebsd.org/releases/15.0R/installation/#upgrade-binary> mentions: FreeBSD-EN-25:18.freebsd-update – I was the reporter. Re: comment 9 > /usr/src/UPDATING More specifically: - <https://github.com/freebsd/freebsd-src/blob/releng/14.3/UPDATING> - <https://github.com/freebsd/freebsd-src/blob/releng/15.0/UPDATING> EN-25:18.freebsd-update is in the former. base 7f1785f09fb2 IMHO the simplest explanation of this bug report is that an outdated freebsd-update does not check for updates to itself. freebsd-update checks for updates to the base operating system of which it is a part, and there's a widely-communicated routine for major upgrades. Whilst freebsd-update(8) <https://man.freebsd.org/cgi/man.cgi?query=freebsd-update&sektion=8&manpath=freebsd-release> lacks a section for examples, it is quite commonly understood that release documentation should be a starting point. In this case: <https://www.freebsd.org/releases/15.0R/> The first link in the announcement is to release notes, where <https://www.freebsd.org/releases/15.0R/relnotes/#upgrade> leads to: <https://www.freebsd.org/releases/15.0R/installation/#upgrade-binary> HTH Graham
I would expect freebsd-update to be sufficiently aware of the current system state to at least refuse such an upgrade, or issue a clear warning, unless the user explicitly forces it. As I understand it, freebsd-update already inspects the local installation state and compares it with the repository metadata. Given that, it seems feasible to detect an unsupported or unsafe upgrade path and provide a warning or guidance about the correct upgrade procedure (e.g. via 14-STABLE first). Even within a relatively small user community, there have already been at least three independent reports of this issue with 15.0.
You're missing the point entirely. Your current copy of freebsd-update is what it is. The only way we can change it is by putting out an EN which you will then install by running `freebsd-update fetch install`, which you refuse to do. We've already done what we could (fix the bug and put out an EN). We've also clearly documented that you should update your existing system to the latest patch level before upgrading (this isn't new, because it's not the first time a bug in freebsd-update broke an upgrade). But you refuse to read that documentation, preferring instead to read /usr/src/UPDATING which is intended for people who update from source, i.e. not you. So the only problem here is your refusal to read the documentation and follow the procedure it recommends. There is no patch for that.
(In reply to Dag-Erling Smørgrav from comment #12) Thank you for the clarification. I understand that the locally installed freebsd-update binary may be old and therefore unaware of the specifics of newer releases. My point is not about retroactively changing its logic or expecting it to “know” future details. However, freebsd-update does not operate in isolation: it consumes repository metadata describing newer releases and update sets. Based on that information alone, it seems feasible to detect at least some unsafe situations and guide the user accordingly. For example, the tool could: 1. Detect that there are newer patch-level updates available for the currently installed major version and advise installing them first before attempting a major upgrade. 2. Indicate that upgrading directly from the currently installed release to the target major version is known to be unsafe and may result in a broken system. As an analogy, while it is generally advisable for administrators to read CVE advisories and track security issues manually, in practice we have 'pkg audit', which compares installed versions against vulnerability data and proactively warns the administrator. This does not replace documentation, but it provides a practical safety net. In a similar way, even a simple guard or warning in freebsd-update would help prevent this class of failures. The fact that multiple users independently encountered the same failure mode suggests that this is not solely a documentation issue, but a missing safety check in the upgrade workflow.