i915kms package breaks on 12.2-RELEASE (workaround - build from ports)

IMHO, it should be (at least) in the Errata for the release. So yes, create a bug report and ask for the errata to be updated. (BTW, /usr/ports/UPDATING is less useful these days, as most folks are using packages, which doesn't have that file.)
 
This "problem" will resolve itself in February, when 12.1 is EoL.
 
I have Sandybridge processor and integrated graphics. Can I build drm-kmod port alone? I'm using pkg BTW.
With IvyBridge GPU I am still using the driver (drm2) contained in the kernel sources. I know it is considered obsolete, and it will go away in Rel.13, but I just copied the config from 11.4 to 12.2, and it still works as before.

OTOH, with any drivers (from ports) that plug into the kernel, these need a rebuild whenever a new kernel appears. Thats not only true for graphics, but give-or-take everything else (OSS from ports, etc) also.

I guess that's the price you pay for the convenience of using binary packages then?
It's probably the price for running a server OS on a desktop. ;) HiRes graphics may be considered not an integral part of the system, but a specialized hardware add-on, which needs to be treated specially.

I for my part am not very happy with the decision of moving graphics out of the kernel, but I do understand the rationale behind.

Is that assumption based on facts or the predominant attitude of FreeBSD being a server operating system amongst FreeBSD developers?
[/QUOTE]
Good question! I think it's facts.
Personally I have used FreeBSD as a desktop since the early 1990s
Me too. And indeed I am quite happy that it is a server OS - because that way one can perceive the various parts as nicely separate (and tackle them individually, in case of need). If you go the other way and try to create a well integrated desktop experience, then you get a vast heap of all interdependent pieces, which may work right from the beginning - but if they happen to do not, then you don't get a clue on why. Anyway, Apple did this already, Linux tried to do it and found systemd. Whatever it hurts - there's upsides and downsides on either way.
 
  • Thanks
Reactions: a6h
This "problem" will resolve itself in February, when 12.1 is EoL.
The problem there is that FreeBSD has stable kernel ABI policy for minor releases, which is being repeatedly violated. The next non-.0 release will have exactly the same issue. I'll especially note here that the reason FreeBSD 12 doesn't receive any DRM driver backports is the fear of breaking said stable ABI policy, this is downright embarrassing.
 
The problem there is that FreeBSD has stable kernel ABI policy for minor releases, which is being repeatedly violated.
It's this or tell everyone they'll have to wait for 13.0 before they can use the Intel/AMD graphics drivers. Neither situation is ideal.
 
Good question! I think it's facts.
I'm not so sure about that. I think it's mostly bias and wishful thinking.
The problem there is that FreeBSD has stable kernel ABI policy for minor releases, which is being repeatedly violated.
This for one is an execellent point, and also I see the current package build process as problematic. How can you release a new OS version without packages being built for this particular version and expect anything other than a less than optimal outcome? Packages should be built for the most recent release version starting from the very day it is released, with the (compatibility) packages for the older version fading away as soon as it becomes EoL, not the other way around. It's just sad to get bitten by issues like this one, just because you happen to be one of those people who likes to keep their stuff up-to-date, always.
 
How can you release a new OS version without packages being built for this particular version and expect anything other than a less than optimal outcome? Packages should be built for the most recent release version starting from the very day it is released, with the (compatibility) packages for the older version fading away as soon as it becomes EoL, not the other way around.
There is only one repository for a major version. As 12.1 is still supported the packages are being built for the lowest, still supported, version. It's not a problem to install 12.1 packages on 12.2 except for a small number of kernel modules. And the only reason it's a problem for those kernel modules is because the ABI changed. If the ABI didn't change there would be no problem at all. But if the ABI wasn't changed then you wouldn't get a working Intel/AMD driver at all until the next major release.

Remember, there is only a finite amount of resources they can use. Sure they could build more repositories, but that's going to take away those finite resources from somewhere else. And then those people are going to complain. Whichever way you go there will always be somebody getting disappointed.

I see the same thing happening at work. Project A says they have priority, project B comes along and says they have priority too. I can't clone myself and there's only a finite amount of hours in a day I can work on anything. Something has to give. Either A or B will get priority, not both. Heck, me trying to do both actually ended up with me at home not being able to work at all for 4 weeks (stress and RSI are not a good combination).
 
But if the ABI wasn't changed then you wouldn't get a working Intel/AMD driver at all until the next major release.
This is a completely bizarre statement. None of those breakages are actually intentional. They are unrelated to DRM work.
 
This is a completely bizarre statement. None of those breakages are actually intentional. They are unrelated to DRM work.
Yes, you are correct. Not DRM but device driver. It costed me a new graphics card, display port cable and a wasted week. Yet, I can't but be grateful to the developers and community for the great OS.
 
Remember, there is only a finite amount of resources they can use. Sure they could build more repositories, but that's going to take away those finite resources from somewhere else. And then those people are going to complain. Whichever way you go there will always be somebody getting disappointed.
I surely can respect that. Still, if the number of incompatible binary packages is limited to only a few kernel modules as you say, creating a separate repository for the new OS version that only contains those few problematic modules built for this particular OS/ABI version with everything non-problematic symlinked to the previous versions would also be an option. This would still be a lot better than having users either wait three months before they can upgrade their systems to the latest release, or somehow manually fiddle around the breakage. Problems like this one reduce the overall usefulness of binary packages to a certain degree. When I decide that a particular system is to use binary updates for the OS and packages, then it will neither have a source tree nor ports tree installed, both of which are rather massive and also will require updating by other means, not necessary otherwise.
 
Here we are suggesting a new repo and what not, when the path of least resistance is just adding a warning line to release notes and/or errata. If the affected people build their affected packages from ports, problem solved, is it not? Is it not so simple with those other affected packages? Because with i915kms it sure is. Am I missing something here?
As SirDice said, it's just 4 or 5 packages (out of 40k+), unfortunately, one of those is graphics driver, which is very popular amongst desktop users.

For me, personally, this was not that big of an issue, but I was a bit dissappointed by the lack of information. FreeBSD is a professional system, so I expected to be officially, professionally informed about an issue before I encoutered it. Especially when I took my time to read release notes, errata etc. And not to dig out information on forums/google, etc. FreeBSD taught me to trust official channels, manpages, etc, so I tend to look there in the first place, not google.
 
I wonder if we can build drm-kmod for each FreeBSD version out there (it's not big at all) and then include a pre-install script in a drm-kmod package to select the right version. Would that be an acceptable workaround while the ABI policy violation issue is resolved? This is definitely disappointing and borderline embarrassing for all new and current desktop FreeBSD users.
 
Who are these "we" you are talking about?
The ports team has stated many times that they don't have the capacity (read: manpower) to support more package branches than they already do.
 
  • Thanks
Reactions: a6h
Sigh. It took 2 days of thrashing through ddg/google searches before stumbling across this thread. Thanks for workaround. Can now use 12.2-release on a macmini5,1. Would very much appreciate any future warning signs (in handbook? in wiki?) to flag something like "work in progress. use this detour."
All said, I'm very much looking forward to migrating my "work-from-home" FreeBSD desktop to a 64-bit system; it's time to retire the macmini2,1
 
Dear Diego,

I am facing the same problem. Do you have the detailed Steps? I tried to compile the graphics/drm-fbsd12.0-kmod, but failed.

Code:
#make install clean BATCH=yes
Code:
/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi/gplv2/include/linux/i2c.h:236:2: note: previous implicit declaration is here
        device_unregister(&client->dev);
        ^
--- linux_irq.o ---
11 errors generated.
*** [linux_irq.o] Error code 1

make[2]: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi
--- linux_i2c.o ---
11 errors generated.
*** [linux_i2c.o] Error code 1

make[2]: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi
2 errors

make[2]: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod

Thread freebsd-12-2-startx-failed-ee-open-dev-dri-card0-no-such-file-or-directory.78157


Building the package with portmaster ---> compiling 15 minutes --> go back "modesetting" driver --> reboot
It worked !!!
Code:
Probe URL: https://bsd-hardware.info/?probe=f9a374a310
 
I tried to compile the graphics/drm-fbsd12.0-kmod, but failed.
And your snippet doesn't include any of the ACTUAL build errors. But anyways, check whether you are indeed on 12.2-RELEASE and whether you have anything in /etc/make.conf.
what's puzzling here is why drm-kmod maintainers even accept this?
There's nothing THEY could do about it. The problem is that ABI *inside* the kernel changes, so a kernel module built for 12.1 will not work on 12.2. Still there's only one (userspace) ABI for FreeBSD-12 and therefore only one package repository.

Yes, this is annoying, and there should be at least some prominent warning about it when upgrading. The solution still is simple, just build packages containing kernel modules yourself until EOL of 12.1.
 
I agree with many of the users here: it is unfortunate that FreeBSD has this ABI problem (but understandable), and the solution was simple enough. However, the problem should have been communicated clearly, in advance, through the Release Notes, Errata and/or UPDATING.

I read them all before upgrading and, unless I missed it, it simply wasn't mentioned (correct me if I'm wrong). Really... Correct me if I'm wrong.

Arguing that this is essentially a non-issue, and that it requires no changes to the project (no matter how small) because you knew about it in advance, or at least knew what to do after it happened, seems to be overly defensive.

Nobody is "overtaxed". New users may not know how to deal with it but they can easily find out how to fix it.
I think the fact that people have to go to forums and ask for help from more experienced users is pretty good evidence they are overtaxed. I know the solution was pretty simple, but as always: "It's easy when you know how."

The kmod incompatibility issue is not a big deal only if you know about it beforehand, otherwise this has all potential to be a major annoyance.
something that breaks the system should be documented and in an obvious place.
IMHO, it should be (at least) in the Errata for the release.
I also read the release notes, errata and release announcement before running freebsd-update, but yeah, silly me, expecting to be informed beforehand about this 'niche' issue.
...
the path of least resistance is just adding a warning line to release notes and/or errata.
...
For me, personally, this was not that big of an issue, but I was a bit dissappointed by the lack of information. FreeBSD is a professional system, so I expected to be officially, professionally informed about an issue before I encoutered it.
I agree with all you guys. Instead of downplaying the problem (small as it is for those who know how), ignoring it, dismissing users because they use FreeBSD on the desktop, etc., or even asking for new repos and build processes, it's obvious that all that was needed was a line or two in one of the official communication documents.
 
I'd be surprised if the drm kmod package was the only one affected, it's probably just the most widespread one as almost every desktop installation will have it. In general, any kmod package can be affected. As this doesn't happen for the first time (roughly the same amount of confused questions were posted during transition 12.0 -> 12.1) and introducing more repos just for this corner case might be a bit exaggerated, yes, it should just be documented.

Maybe the handbook would be a good place, as this is a recurring issue. It will always happen during the 3-month period when two minor releases of the same major release are supported. One could add a link to release notes or in an UPDATING message, or something like that.
 
One can submit a patch too. I'm not sure how one does that for the handbook. I remember back in the days when you used send-pr I was able to submit to UPDATING with a simple textfile, but that was back in the days of FreeBSD-4.x. These days, though, I'm somewhat remind of Arch Linux where one misses something and posts I have this problem, someone says, did you read news, Yeah, I read news and nothing there, and then Did you look at the forums, Yeah, and nothing there, and then Oh, no wonder! You dumb newb, you should be subscribed to the developer list as well, it was mentioned there.
And I would reply, It should be like FreeBSD, where it's clearly there, under UPDATING. And, back then, it would be.

So, in this case, in my very arrogant opinion, it should be clearly stated under /usr/ports/UPDATING. As I've become much older, I get too lazy to submit but, I think it would be worth an email to the port maintainer at least. I find it's true for amdgpu drm-kmod, on CURRENT as well.
I've gotten lazy and selfish in my old age, and it's something I know about already, so at this point, all I do is answer forum questions about it if I see them.
 
These days, though, I'm somewhat remind of Arch Linux where one misses something and posts I have this problem, someone says, did you read news, Yeah, I read news and nothing there, and then Did you look at the forums, Yeah, and nothing there, and then Oh, no wonder! You dumb newb, you should be subscribed to the developer list a well, it was mentioned there.
And I would reply, It should be like FreeBSD, where it's clearly there, under UPDATING. And, back then, it would be.
Really? I think that's the other way around.
 
[2020-11-11] Due to slight changes to the ABI and KBI between FreeBSD 12.1 and FreeBSD 12.2, it is important to note that certain third-party kernel modules may need to be rebuilt locally, until FreeBSD 12.1 reaches end of life.

Of note, this includes, but is not limited to, graphics/*-kmod, net/*-kmod, and possibly others that are too extensive to list.
 
Back
Top