Date: Sun, 13 Dec 2020 18:28:36 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 250700] drm-kmod i915kms binary package not working on 12.2-RELEASE Message-ID: <bug-250700-7141-VUavFj2eaT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-250700-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-250700-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250700 --- Comment #17 from Bruce Lilly <bruce.lilly@gmail.com> --- (In reply to Niclas Zeising from comment #16) Known issues affecting a release ought to be documented clearly in the rele= vant release notes and hardware notes, no? Pointing out the failure in documenting supposedly-known issues isn't a ran= t; 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 wor= k 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 bi= nary 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 her= e. The "Unsupported relocation type" resulted after attempting to rollback the failed update. Had the update worked, I would not have had to rollback. Ma= jor incompatibilities (such that binary upgrades and rollbacks in fact do not w= ork) 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 roll= ing back binary updates. ZFS boot environments aren't applicable to UFS/FFS installations, and ZFS i= sn'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 sligh= tly 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-250700-7141-VUavFj2eaT>