https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291344
--- Comment #13 from [email protected] --- (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. -- You are receiving this mail because: You are the assignee for the bug.
