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

That problem, again? Seriously? Am I glad I use nvidia hardware.
So what now? Wait til 12.1 goes EOL and packages will be built for 12.2 again?
 
If I read correctly, 12.1-RELEASE goes EOL in three months (12.2-RELEASE plus three months). I'm on 12.1-RELEASE now with quarterly updates so I can wait until January or February before moving to 12.2-RELEASE for anything running X.
 
After the upgrade to 12.2-RELEASE, I have to use VESA driver to get things working (at least, temporarily.). Of course, no 3D acceleration.
"Xorg complains that it cannot find mesa when i915kms is installed using the binary package, but runs just fine when built locally out of ports. Known bad on at least two systems."

I have Sandybridge processor and integrated graphics. Can I build drm-kmod port alone? I'm using pkg BTW.
 
Is this only affecting Intel HD Graphics? My system has the old school GMA X3100, I will update to 12.2 this Friday and will report back if I'm facing the same issue. I tried to update today but it seems it's not available for me yet on quarterly update.
 
Last edited:
Hi

I have build drm-kmod on my laptop
it's a ivy bridge GPU : pentium 2117u

And now every thing is perfect on it and freebsd 12.2:
glxgears OK
glxinfo | grep render OK (says direct rendering and ivy bridge hardware)

Xorg uses modesetting
 
Can I build drm-kmod port alone? I'm using pkg BTW.
graphics/drm-kmod is a so-called meta-port. It does nothing and only depends on other packages. In this case you need to build graphics/drm-fbsd12.0-kmod, which is the actual driver that gets installed as a dependency of graphics/drm-kmod.

That problem, again? Seriously? Am I glad I use nvidia hardware.
As the NVidia driver is a kernel module it can have the exact same problem.

So what now? Wait til 12.1 goes EOL and packages will be built for 12.2 again?
Yes. This issue is going to crop up with every new minor release. For 99.9% of the packages it's not a problem to install 12.1 packages on 12.2. It's only a handful of kernel modules that are problematic (4 or 5 out of 41000+). And the issue will only last for 3 months, until the old minor version is EoL'd.
 
graphics/drm-kmod is a so-called meta-port. It does nothing and only depends on other packages. In this case you need to build graphics/drm-fbsd12.0-kmod, which is the actual driver that gets installed as a dependency of graphics/drm-kmod.


As the NVidia driver is a kernel module it can have the exact same problem.


Yes. This issue is going to crop up with every new minor release. For 99.9% of the packages it's not a problem to install 12.1 packages on 12.2. It's only a handful of kernel modules that are problematic (4 or 5 out of 41000+). And the issue will only last for 3 months, until the old minor version is EoL'd.
Apparently x11/nvidia-driver-340 does not suffer from the same problem. I just updated my notebook to RELENG-12.2 using custom built kernel/world and stock packages and so far everything seems to be just fine. My other machines just finished rebuilding everything from src+ports last night and also run fine.

So basically you are saying that as a package user you have two options here:
1) Get a ports tree and compile it yourself (which probably will require a src tree also), onto a machine that isn't supposed to have either, or
2) Wait 3 months until official packages will be built for the correct OS version.

I guess that's the price you pay for the convenience of using binary packages then? I went through that same boot-loop caused by incompatible drm-kmod mess when upgrading a friend's notebook from 12.0 to 12.1. Back then it sounded more like this was kind of a last-minute oversight, and I was really hoping not to see this crop up again, but here we are.
 
So basically you are saying that as a package user you have two options here:
1) Get a ports tree and compile it yourself (which probably will require a src tree also), onto a machine that isn't supposed to have either, or
2) Wait 3 months until official packages will be built for the correct OS version.
Only for the 4 or 5 kernel modules in the ports tree that may be problematic during this transition period.

I guess that's the price you pay for the convenience of using binary packages then?
It's a minor inconvenience during the first three months of a new release, nothing more.
 
Only for the 4 or 5 kernel modules in the ports tree that may be problematic during this transition period.


It's a minor inconvenience during the first three months of a new release, nothing more.
That's 4 or 5 problematic kernel modules that happen to be used by a sizeable number of users with the potential to break a system in a way that could easily overtax novice users. Last time that minor inconvenience had me drive 30km to fix up a screwed update that could otherwise have gone smoothly. I ended up reverting to the old boot environment, redoing the entire update, pulling a ports and src tree, finally building drm-kmod from ports and locking the package thereafter. I guess this time I just build that damn thing at home and bring a USB stick.
 
That's 4 or 5 problematic kernel modules
Yes, out of 41000+ packages. I'd say that's a fairly good score.

with the potential to break a system in a way that could easily overtax novice users.
Seriously? Nobody is "overtaxed". New users may not know how to deal with it but they can easily find out how to fix it. At least that's been my experience helping those people here on the boards. You should give novice users more credit than that, they're not as dumb as you think they are.

happen to be used by a sizeable number of users
Desktop users are a minority, and only a small percentage of that minority may have some minor issues. There will always be a small percentage of users that are going to have problems with any kind of update/upgrade. For the majority however things will work just fine. As we say in Dutch, je probeert van een mug een olifant te maken (you're trying to create an elephant from a mosquito). In other words, don't make a problem bigger than it actually is.

Last time that minor inconvenience had me drive 30km to fix up a screwed update that could otherwise have gone smoothly.
So, you have a remote system and no form of remote KVM or IPMI? Really? Are you just mad at yourself and trying to shift the blame here? Updates/upgrades always have the potential of completely hosing your system. Luckily that happens quite rarely but in the past 20 or so years it has happened to me at least a few times (highly experienced people are just as capable of screwing things up). The only problem I see here is not having remote access to the console, then you could have easily fixed this remotely. As a sidenote, if I break stuff I would have to drive 80Km. So, yes, I have remote consoles for everything. Rarely need to use it but I'm always happy it's there when I need it.
 
  • Thanks
Reactions: a6h
I'll have to disagree there. 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. Ports have an UPDATING* file listing upgrade issues. In contrast, there no such place for packages. Release upgrade instructions also do not account for that issue as well.

It's not clear why it's so diffucult for the project to put some notice somewhere.

* which I never read, by the way
 
Seriously? Nobody is "overtaxed". New users may not know how to deal with it but they can easily find out how to fix it. At least that's been my experience helping those people here on the boards. You should give novice users more credit than that, they're not as dumb as you think they are.
I don't consider anyone daring enough to use FreeBSD dumb, but finding yourself trapped in a non-ending boot-loop with only seconds to react can pretty much ruin your day. As for easily finding out how to fix it... not even I did that easily. If I remember correctly, last time we had that drm-kmod mess, you were amongst those suggesting that switching the package repository to some bleh-1 repository followed by reinstalling all packages would fix the problem. I tried that back then, and no it did not fix the problem, let alone easily. The only real solution was to build it from source, which comes with a lot of prerequisites otherwise not required or present on a machine using binary updates.

Desktop users are a minority, and only a small percentage of that minority may have some minor issues. There will always be a small percentage of users that are going to have problems with any kind of update/upgrade. For the majority however things will work just fine. As we say in Dutch, je probeert van een mug een olifant te maken (you're trying to create an elephant from a mosquito). In other words, don't make a problem bigger than it actually is.
Is that assumption based on facts or the predominant attitude of FreeBSD being a server operating system amongst FreeBSD developers? Personally I have used FreeBSD as a desktop since the early 1990s, many years exclusively, and I know others who did so as well. Here on the forum many seem to use FreeBSD as a desktop too, but each time when there are problems related to FreeBSD desktop usage, it's exactly this kind of attitude that shines through rather sooner than later, and yes that makes me angry in a way. Is it really that hard to admit that you can have your cake and eat it too? I love FreeBSD, be it on the server or my desktop.
 
More than a year later and SirDice continues to say it's not a bug, it's a feature. One person is fine, but what's puzzling here is why drm-kmod maintainers even accept this? I mean, the whole X11 team is involved, right? Why would anyone on that team consider OS breakage every time someone decides to update it to be even remotely acceptable behavior? I am beyond puzzled.
 
This looked important enough to pass on here.


"Xorg complains that it cannot find mesa when i915kms is installed using the binary package, but runs just fine when built locally out of ports. Known bad on at least two systems."

Looks like we'll have to live with this until 12.3-RELEASE.
I got around this awkward transition by switching to 13-CURRENT. My drm-current-kmod has been working fine on an Intel SandyBridge i5 (HD3000) and on Intel IvyBridge i5 (HD4000). Of course now I'm upgrading the o.s. from source. Current binary ports, including drm-current-kmod, have been ok for me. When 13.0 is released in a few months I'll switch over to that and return to doing binary upgrades of the system. drm-current-kmod seems to be quite up-to-date with linux (5.4.62.g20201003).
 
This looked important enough to pass on here.


"Xorg complains that it cannot find mesa when i915kms is installed using the binary package, but runs just fine when built locally out of ports. Known bad on at least two systems."

Looks like we'll have to live with this until 12.3-RELEASE.
Same issue for my laptop --> specification on this BSD database:
Code:
https://bsd-hardware.info/index.php?probe=9168df8552
For me its a real problem, because the vesa driver works really poor and I dont think I could wait 3 months till the minor release.
I will try to compile the driver "graphics/drm-fbsd12.0-kmod" from ports (fingers crossed)
 
The only real solution was to build it from source, which comes with a lot of prerequisites otherwise not required or present on a machine using binary updates.
Can "someone" do that and post the binary file(s) "somewhere" and a how-to document? Or is it not that simple? Sorry if a dumb question, I don't (yet) use FreeBSD as a desktop environment, so it might not be practical.

I guess if a kernel module there's a huge security risk downloading a binary that someone else has compiled and uploaded to the internet, so might be a complete no-no because of that risk.
 
So, you have a remote system and no form of remote KVM or IPMI? Really? Are you just mad at yourself and trying to shift the blame here? Updates/upgrades always have the potential of completely hosing your system. Luckily that happens quite rarely but in the past 20 or so years it has happened to me at least a few times (highly experienced people are just as capable of screwing things up). The only problem I see here is not having remote access to the console, then you could have easily fixed this remotely. As a sidenote, if I break stuff I would have to drive 80Km. So, yes, I have remote consoles for everything. Rarely need to use it but I'm always happy it's there when I need it.
The system in question was a friend's notebook that I had installed for her, so no, there was no remote access. I was assisting her on the phone to perform the update but when things went south there was no other option. And if it wasn't for the drm-kmod incompatibility, this update would've been a smooth one.
 
Thank you for this thread, I was puzzled, being a FreeBSD novice. I was trying to get all the puzzle pieces together to make it work, I spent one evening istalling and uninstalling drm-kmod, drm-legacy-kmod, xf86-video-intel and also trying the built-in kernel i915kms.ko module and trying all possible combinations of those four drivers.

Now I know, that this will happen everytime there's an update of the system, because packages are being built against previous dot-release until EOL. 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.
Why would someone write this in the release notes: "ATTENTION i915kms USERS, BUILD graphics/drm-fbsd12.0-kmod FROM PORTS.

It's obvious for those who know what they are doing and the others are free to play with it for a few hours. I am very grateful, that we have this forum, otherwise, this would probably be a deal breaker for me, unable to reach a conclusion by myself.

Even the handbook is sparse on info about i915 driver, it's a bit confusing for a newcomer (and I am still confused, but I'll uninstall everthing intel-related: drm-kmod, xf86-video-intel、etc、 and I'll try building graphics/drm-fbsd12.0-kmod when I get to my computer)
 
Can "someone" do that and post the binary file(s) "somewhere" and a how-to document? Or is it not that simple? Sorry if a dumb question, I don't (yet) use FreeBSD as a desktop environment, so it might not be practical.

I guess if a kernel module there's a huge security risk downloading a binary that someone else has compiled and uploaded to the internet, so might be a complete no-no because of that risk.
I have a personal pkg repository that contain drm-kmod for 12.2, you can look at this post for instruction on how to enable it
https://darkness-pi.monwarez.ovh/posts/synth-repository

A direct link would be
https://darkness-pi.monwarez.ovh/amd64/All/drm-fbsd12.0-kmod-4.16.g20200221.txz
 
For me, I first installed drm-kmod (from pkg) and it didn't work. Ok, the wiki says with Haswell, which is what I have, you might need legacy. So did that and it worked. As this is a test laptop and I was trying out various installs, I then reinstalled. This time, drm-legacy-kmod didn't work and I had to use xf86-intel though when I booted, the console font would change to a smaller yet clearer font--typical of what happens when one uses the i915 module.

Anyway, saw this post, and this time, built regular, not legacy, drm-kmod from ports and all was fine. As it only takes a few minutes to build, I can't get overly upset about it.
 
@ SirDice - I have to agree with some of the others here. While the "fix" is not that complicated, it is nonetheless not good enough.

This issue is going to crop up with every new minor release
...
It's a minor inconvenience during the first three months of a new release, nothing more.

Again, it's not a show-stopper, but it would only be considered a "minor inconvenience" if it was clearly communicated beforehand, with a "solution" communicated beforehand.

This seems like something that should be addressed, not accepted. Even the guys at bugs.freebsd.org think so.

New users may not know how to deal with it but they can easily find out how to fix it
Where exactly? Serious question. Because I read the Release Notes, I read the Errata. Didn't see anything about, and just got blind-sided by it.

Do you mean here, in this thread? Or here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250700

While it is great that these two sources exist, they are really only useful after the fact.

Desktop users are a minority, and only a small percentage of that minority may have some minor issues.
FreeBSD is marketed as a General Purpose Operating system, is it not?

I actually run my business from a FreeBSD desktop/laptop (dumb?) and I lost a whole day of work (boohoo, I know), and so did my clients. Funny how this is a "minor issue" for me, but not for those running FreeBSD on a server.

FWIW, building from ports worked for me too. Nonetheless, I still feel like this should have been communicated better, or fixed beforehand.

So, for future reference, and for those in the same position as me:
Where could I have read about this problem (and solution) before I upgraded?
 
It should probably be in /usr/ports/updating. You could try filling out a bug report, but I don't know what the result would be. They may say that's not the place for it. And I agree with you, something that breaks the system should be documented and in an obvious place. Maybe release notes, with a big IMPORTANT to call attention to it. I suppose one can argue it doesn't break the system as you can use vesa, or in my case, before I saw this thread, the intel driver, but whether it's a matter of seeing the past through rose-colored glasses, or an objective memory, it does seem to me that back in the doubleoughts such things were mentioned in easy to find places, either release notes or UPDATING.
 
Back
Top