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



## unitrunker (Oct 28, 2020)

This looked important enough to pass on here.






						250700 – drm-kmod i915kms binary package not working on 12.2-RELEASE
					






					bugs.freebsd.org
				




"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.


----------



## mickey (Oct 28, 2020)

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?


----------



## unitrunker (Oct 29, 2020)

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.


----------



## Abraham79 (Oct 29, 2020)

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.


unitrunker said:


> "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.


----------



## the3ajm (Oct 29, 2020)

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.


----------



## Jaekelsson (Oct 29, 2020)

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


----------



## SirDice (Oct 29, 2020)

Abraham79 said:


> 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.



mickey said:


> 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. 



mickey said:


> 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.


----------



## mickey (Oct 29, 2020)

SirDice said:


> 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.
> ...


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.


----------



## SirDice (Oct 29, 2020)

mickey said:


> 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. 



mickey said:


> 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.


----------



## mickey (Oct 29, 2020)

SirDice said:


> 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.


----------



## SirDice (Oct 29, 2020)

mickey said:


> That's 4 or 5 _problematic_ kernel modules


Yes, out of 41000+ packages. I'd say that's a fairly good score.



mickey said:


> 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. 



mickey said:


> 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.



mickey said:


> 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.


----------



## shkhln (Oct 29, 2020)

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


----------



## mickey (Oct 29, 2020)

SirDice said:


> 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.



SirDice said:


> 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.


----------



## blackhaz (Oct 29, 2020)

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.


----------



## garry (Oct 29, 2020)

unitrunker said:


> This looked important enough to pass on here.
> 
> 
> 
> ...


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).


----------



## diego (Oct 30, 2020)

unitrunker said:


> This looked important enough to pass on here.
> 
> 
> 
> ...


Same issue for my laptop --> specification on this BSD database:

```
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)


----------



## richardtoohey2 (Oct 30, 2020)

mickey said:


> 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.


----------



## diego (Oct 30, 2020)

diego said:


> I will try to compile the driver "graphics/drm-fbsd12.0-kmod" from ports (fingers crossed)


Building the package with portmaster ---> compiling 15 minutes  --> go back "modesetting" driver --> reboot
It worked !!!

```
Probe URL: https://bsd-hardware.info/?probe=f9a374a310
```


----------



## mickey (Oct 30, 2020)

SirDice said:


> 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.


----------



## matt_k (Oct 30, 2020)

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)


----------



## monwarez (Nov 4, 2020)

richardtoohey2 said:


> 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


----------



## George (Nov 6, 2020)

Ouch.. I ran into this, too.


----------



## scottro (Nov 7, 2020)

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.


----------



## nickednamed (Nov 9, 2020)

@ SirDice - I have to agree with some of the others here. While the "fix" is not that complicated, it is nonetheless not good enough.



SirDice said:


> This issue is going to crop up with _every_ new minor release


...


SirDice said:


> 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.



SirDice said:


> 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.*



SirDice said:


> 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?*


----------



## scottro (Nov 10, 2020)

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.


----------



## tingo (Nov 10, 2020)

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.)


----------



## SirDice (Nov 10, 2020)

This "problem" will resolve itself in February, when 12.1 is EoL.


----------



## PMc (Nov 10, 2020)

Abraham79 said:


> 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.



mickey said:


> 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.



mickey said:


> 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.


mickey said:


> 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.


----------



## shkhln (Nov 10, 2020)

SirDice said:


> 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.


----------



## PMc (Nov 10, 2020)

shkhln said:


> The problem there is that FreeBSD has stable kernel ABI policy for minor releases



Question: does this apply to kernel drivers, or only to the kernel <-> userland interactions?


----------



## shkhln (Nov 10, 2020)

PMc said:


> Question: does this apply to kernel drivers, or only to the kernel <-> userland interactions?


I just googled https://lists.freebsd.org/pipermail/freebsd-current/2015-July/056625.html for you.


----------



## SirDice (Nov 10, 2020)

shkhln said:


> 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.


----------



## shkhln (Nov 10, 2020)

SirDice said:


> It's this or tell everyone they'll have to wait for 13.0 before they can use the Intel/AMD graphics drivers.


This is addressed right after the next sentence (of the post you are replying to).


----------



## mickey (Nov 10, 2020)

PMc said:


> Good question! I think it's facts.


I'm not so sure about that. I think it's mostly bias and wishful thinking.


shkhln said:


> 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.


----------



## SirDice (Nov 10, 2020)

mickey said:


> 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).


----------



## shkhln (Nov 10, 2020)

SirDice said:


> 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.


----------



## Lamia (Nov 11, 2020)

shkhln said:


> 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.


----------



## mickey (Nov 11, 2020)

SirDice said:


> 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.


----------



## matt_k (Nov 11, 2020)

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.


----------



## blackhaz (Dec 7, 2020)

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.


----------



## tingo (Dec 10, 2020)

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.


----------



## PKern (Dec 12, 2020)

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


----------



## Hanson (Dec 24, 2020)

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.


```
#make install clean BATCH=yes
```


```
/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




diego said:


> Building the package with portmaster ---> compiling 15 minutes  --> go back "modesetting" driver --> reboot
> It worked !!!
> 
> ```
> ...


----------



## zirias@ (Dec 24, 2020)

Hanson said:


> 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.


blackhaz said:


> 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.


----------



## nickednamed (Dec 30, 2020)

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.



SirDice said:


> 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."



shkhln said:


> 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.





scottro said:


> something that breaks the system should be documented and in an obvious place.





tingo said:


> IMHO, it should be (at least) in the Errata for the release.





matt_k said:


> 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.


----------



## zirias@ (Dec 30, 2020)

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.


----------



## scottro (Dec 30, 2020)

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.


----------



## shkhln (Dec 31, 2020)

scottro said:


> 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.


----------



## blackhaz (Jan 9, 2021)

nickednamed said:


> I agree with all you guys. Instead of downplaying the problem . . . it's obvious that all that was needed was a line or two in one of the official communication documents.


With a bomb sign.


----------



## SirDice (Jan 13, 2021)

> [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.











						FreeBSD 12.2-RELEASE Errata
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org


----------



## blackhaz (Jan 13, 2021)

This is going to be breaking news every release going forward.


----------



## SirDice (Jan 13, 2021)

Maybe, maybe not. If the ABI/KBI doesn't change then it's not going to be problem. Since none of us can predict the future we'll just have to wait and see.


----------



## MasterOne (Jan 28, 2021)

So *four more days* to go?

Is there any way to confirm that the `i915kms` package has been rebuilt for 12.2-RELEASE before I try a fresh installation?


----------



## SirDice (Jan 28, 2021)

MasterOne said:


> So *four more days* to go?


Plus a bit of time for the package clusters to build everything.



MasterOne said:


> Is there any way to confirm that the `i915kms` package has been rebuilt for 12.2-RELEASE before I try a fresh installation?





			https://pkg-status.freebsd.org/builds?type=package


----------



## dave01 (Feb 14, 2021)

SirDice said:


> This "problem" will resolve itself in February, when 12.1 is EoL.


I just upgrade from 12.1 to 12.2 today, Feb 14th, and got bitten by this too.  My system defaulted to the Vesa driver and I had vague memories of reading about this issue so it was a reletively quick fix for me to manually rebuild the relevant ports.  It seems the "fix" hasn't made it to the pkg repository yet.  Or at least the upgrade process doesn't check for or upgrade that port.  pkg upgrade didn't offer it.


----------



## SirDice (Feb 14, 2021)

dave01 said:


> It seems the "fix" hasn't made it to the pkg repository yet. Or at least the upgrade process doesn't check for or upgrade that port. pkg upgrade didn't offer it.


There is no "fix", there is no new version. The only thing that's different is that it's now being built for 12.2. `pkg install -f drm-fbsd12.0-kmod` will force a reinstall.


----------



## Emrion (Feb 14, 2021)

Did an upgrade from 12.1 to 12.2 last Friday. All went smoothly, but I disabled the drm driver until 12.2 was definitively installed (two reboots needed). Then, I ran `pkg upgrade` (from latest repository). No problem so far.


----------



## SirDice (Feb 14, 2021)

Emrion said:


> (two reboots needed).


I honestly never reboot in between. Just keep running `freebsd-update install` until it tells you there's nothing left to do. You may want to force a reinstall of everything, just to be sure; `pkg upgrade -f` (so you get the freshly built 12.2 packages for everything). Don't forget `pkg autoremove` to clean up any old dependencies. Then reboot.


----------



## Emrion (Feb 15, 2021)

Yes, I certainly do more reboots than really needed. Whenever I upgrade something, I reboot since I had some bad surprises in the past. Because without this practice, if after a reboot something goes wrong, it's more difficult to find a workable BE (if such a BE remains) and what is the exact origin of the problem.

Thanks for your advices.


----------



## SirDice (Feb 15, 2021)

So far, in all the years I've been running FreeBSD there was only one occasion where you absolutely had to boot the new kernel _before_ running `installworld` (binary upgrades didn't exist back then), and that was because of the UFS1 -> UFS2 change of FreeBSD 5.0. Of course I read that note in /usr/src/UPDATING _after_ I screwed everything up


----------

