[Bug 250700] drm-kmod i915kms binary package not working on 12.2-RELEASE

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250700

--- Comment #17 from Bruce Lilly <bruce.lilly at gmail.com> ---
(In reply to Niclas Zeising from comment #16)
Known issues affecting a release ought to be documented clearly in the relevant
release notes and hardware notes, no?

Pointing out the failure in documenting supposedly-known issues isn't a rant;
it's pointing out bugs (in documentation and procedure) that ought to be
corrected; release notes is exactly where "known issues" are supposed to be
documented.

A statement in the release notes that freebsd-update is expected to work for
amd64[,i386] binary upgrades of kernel (presumably including kernel modules)
and unmodified userland utilities, if/when in fact it is known *not* to work is
at best misleading and just plain wrong.  Instead, the release notes should
clearly state (with at least as much emphasis as the final "Important" "This
change does not affect[...]" note) that binary updates in fact won't work, at
least for systems where kldstat lists "i915kms.ko" (note that I've given a hint
about how to identify such systems).  Additionally, the release notes could
provide some details about possible work-arounds.  Ideally, there wouldn't be a
release until it was known to work (either a point release that is truly binary
compatible, or a version bump with compatible binaries).

"Supporting development" is tied to advocacy, and undocumented or
poorly-documented major "gotchas" are an impediment to advocacy (among other
things). I'm not the first or only person to point this out in comments here.

The "Unsupported relocation type" resulted after attempting to rollback the
failed update.  Had the update worked, I would not have had to rollback. Major
incompatibilities (such that binary upgrades and rollbacks in fact do not work)
make what is supposedly a point release into what is effectively a major
version change; distributed binaries aren't compatible, and there's no path
back short of reinstallation.  Note that the release notes specifically
recommend freebsd-update, and freebsd-update(8) specifically addresses rolling
back binary updates.

ZFS boot environments aren't applicable to UFS/FFS installations, and ZFS isn't
typically used on laptops (or even most desktops); ZFS is targeted at large
server applications.  Moreover, it isn't a solution to the upgrade problem;
it's similar to having multiple installations of different versions, e.g. on
different disks or partitions [and in fact I have other installations of 12.1,
e.g. on a USB stick].  Abandoning an unusable ZFS boot environment is slightly
easier (in the moment, not taking into account amortized administrative
overhead of ZFS) than wiping a partition of a failed installation, but a
non-working installation remains non-working, whether it's on ZFS or UFS.

-- 
You are receiving this mail because:
You are the assignee for the bug.