# drm-fbsd13-kmod is gone (in favor of drm-510-kmod)



## zirias@ (Sep 7, 2022)

Good News Everyone!

`drm-fbsd13-kmod` died today, because with EoL of 13.0, there's no reason for it any more. graphics/drm-510-kmod is the recommended port for 13.1 now, and it contains newer drivers!

The recommended way to install Linux KMS graphics drivers is still to just install graphics/drm-kmod which will automatically select the correct version for your FreeBSD version and pull in all the firmwares. If you did that previously, a simple package upgrade will take care of the change.

If you installed manually (e.g. to only install the firmwares you actually need) and you're on FreeBSD 13.1, just install graphics/drm-510-kmod package now, this will automatically remove the deleted `drm-fbsd13-kmod`. For users of 12.x, nothing changes, the correct package is still `drm-fbsd12.0-kmod`.

This change was done on both main/latest and 2022Q3/quarterly. It might take a few days until the binary packages are available.

although I am already in my pyjamas *grumble*...


----------



## mer (Sep 7, 2022)

Cool.  Is there an easily accessible list of hardware supported by the drm-510-kmod package?  Perhaps not a big deal since drm-XYZ-kmod is for Intel and AMD, but I know the nvidia kmod stuff wound up catching a few people.  "nvidia-driver" moved ahead versions and broke because the latest version stopped supporting the version of hardware.

But regardless, thanks for this update.


----------



## zirias@ (Sep 7, 2022)

Not that I know of... but the new naming scheme directly hints at the Linux version the code is taken from, so you could try to find the info about Linux 5.10  


mer said:


> But regardless, thanks for this update.


I'm just bringing the message, cause I think people who installed manually might be confused by the removal of `drm-fbsd13-kmod`. All actual work done by others  (well, I just fixed a little nasty dependency bug in `drm-kmod`).


----------



## mer (Sep 7, 2022)

I know that folks were bit by something similar to the nvidia drivers.  "nvidia-driver" was "nvidia-driver-470.xxxxxx" for the longest time, but then became nvidia-driver-510.xxxxx so a simple pkg upgrade would roll you from 470 to 510 and the 510 version dropped support for some hardware supported by 470.  It was only a "big deal" if you ignored package messages.
Upgrading, Dante's 11 level of "fun"


----------



## zirias@ (Sep 8, 2022)

mer, for nvidia, these are the upstream version numbers of the proprietary Nvidia driver. Nvidia always dropped support for older GPUs from time to time, so packagers will typically provide older versions as well (like is done in FreeBSD ports).

The opensource KMS drivers from Linux are different. While I'm pretty sure they're sometimes dropping "ancient" stuff as well, we're talking about much longer periods of time. For example, I'm using radeonkms.ko on some AMD APU with integrated GPU from 2011, and i915kms.ko on an old i386 Asus EeePC


----------



## mer (Sep 8, 2022)

zirias@ said:


> Nvidia always dropped support for older GPUs from time to time


Yep, I know, I understand all that.  Was merely pointing out that the package named nvida-driver at one time used 470 code from upstream, and eventually wound up using 510 code from upstream.  If a person did pkg install nvidia-driver when it used 470 code, then pkg upgrade nvidia-driver after it had moved to 510 code.  If their GPU was not supported by 510 code, then they wound up inadvertantly "upgrading".

I had that actually happen to me but not a big deal because the message from pkg upgrade nvidia-driver clearly stated "Your GPU is not supported by this version, so pkg delete nvidia-driver followed by pkg install nvidia-driver-470".

And yep, I understand the whole linuxkms support thing.


----------



## Alain De Vos (Sep 8, 2022)

I was hoping now i could use amdgpu instead of radeonkms but it seems the chipset is not yet supported.


----------



## astyle (Sep 8, 2022)

Alain De Vos said:


> I was hoping now i could use amdgpu instead of radeonkms but it seems the chipset is not yet supported.


This heavily depends on actual hardware you have... Some older GPU's still require `radeonkms`.

My hope is that Navi 21 is supported in this update.


----------



## mer (Sep 8, 2022)

Graphics stuff is a good example of why I've always tried to get "one or two generations back from latest and greatest" for my BSD systems.
CPUs are generally safe enough, but modern CPUs are not really just CPUs, they are SoC, so integrated graphics may not be supported.  
Rule of thumb, I keep video cards on hand.


----------



## kpedersen (Sep 8, 2022)

zirias@ said:


> well, I just fixed a little nasty dependency bug in `drm-kmod`.


I noticed about a month back (on i386 if relevant) that `pkg install drm-kmod` only pulled in firmware and not the actual drm-fbsd13-kmod. Is this fix your doing?


----------



## zirias@ (Sep 8, 2022)

kpedersen said:


> I noticed about a month back (on i386 if relevant) that `pkg install drm-kmod` only pulled in firmware and not the actual drm-fbsd13-kmod. If this fix your doing?


Hm, probably yes. This bug was weird. The meta-port pulled in the correct drm driver only on amd64. And only if it didn't do that, it pulled in the firmware instead. Not sure how that ever happened, but it should be fixed. Well, I hope so 

Edit, right now, there's another strange issue on i386, drm-510-kmod refuses to build. I got around that somehow, but it seems strange that all these patches should be needed, still waiting for feedback from manu...


----------



## Alain De Vos (Sep 8, 2022)

Zirias, some things are hidden in the mailinglists. 
So i like it when some information becomes available in the forum like this.
As it allows to foresee problems, and gives more insight into what happens behind the scenes/curtains.


----------



## zirias@ (Sep 9, 2022)

kpedersen, I'm currently testing a patch for graphics/drm-510-kmod on i386. As you're using these drivers on i386, maybe you'd like to test as well?

If this works fine, the non-atomic replacement functions for `readq()`/`writeq()` should probably go into base linuxkpi first...

Edit: no need to test that any more, the fix is in base (-CURRENT) now and a workaround in drm-510-kmod for older versions on its way


----------



## Harry Stone (Sep 18, 2022)

This breaks Intel video for 13.0.  It would be great if we could run pkg upgrade out of cron without breaking our systems.


----------



## zirias@ (Sep 19, 2022)

Harry Stone the only *guarantee* for no breakage would be to never upgrade anything, and even that would "break" eventually for various reasons (security holes, missing support for newer hardware, etc).

That said, graphics/drm-510-kmod works perfectly fine here on two very different machines using i915kms.ko, so your statement obviously isn't true. That doesn't mean it won't break anything on _some_ hardware, but then please open a PR and give the required info for ppl to reproduce and fix it.

Oh. Wait. Did you write 13.0? Then please don't open a PR. 13.0 is EoL. There's no support any more whatsoever. You had (as always) three months for upgrade to avoid breakage. Now, you can still fix it by just upgrading.


----------



## jbo (Sep 19, 2022)

Harry Stone said:


> This breaks Intel video for 13.0.


13.0 is EOL (as also mentioned in the opening post).


----------



## mer (Sep 19, 2022)

Harry Stone said:


> This breaks Intel video for 13.0.


zirias@ is it possible that the changes for drm-510-kmod needed changes in the kernel that are not in 13.0?
jbodenmann 2 seconds faster on the keyboard than me.


----------



## Harry Stone (Sep 19, 2022)

Yes 13.0 is EOL but that's no reason to break it.  Pkg upgrade on 13.0 installs a package that can't possibly work.  Nowhere is it stated that at EOL systems will purposely be disabled.  But whatever, reduce system reliability and then blame the user.


----------



## zirias@ (Sep 19, 2022)

There's only one package repository per major version. And EoL means EoL (which then, for example, enables finally delivering things that didn't work with the old version). You had a transition phase of 3 months, and still you "forget" updating and then blame the project? Well then...


----------



## Alain De Vos (Sep 19, 2022)

Isn't the easiest solution to upgrade to 13.1. Problem solved.


----------



## jbo (Sep 19, 2022)

Harry Stone said:


> Yes 13.0 is EOL but that's no reason to break it.


EOL does indeed not translate to "lets intentionally break it". It translates to "no more support for it". This means that any changes (including in ports) are done without any regards to 13.0 (or any other EOL'd version).


----------



## zirias@ (Sep 19, 2022)

It's the *only* solution. FreeBSD major versions are supported for 5 years, but you are obliged to follow the minor versions. They keep the same ABI, so they will never break existing software. But _some_ newer software just *won't work* on the older minor. And of course, security issues won't be fixed. EoL means EoL means no support.


----------



## astyle (Sep 19, 2022)

zirias@ said:


> It's the *only* solution. FreeBSD major versions are supported for 5 years, but you are obliged to follow the minor versions. They keep the same ABI, so they will never break existing software. But _some_ newer software just *won't work* on the older minor. And of course, security issues won't be fixed. EoL means EoL means no support.


Maybe I'm being pedantic here, but according to https://www.freebsd.org/releases/, 13.0 was released just a little over a year ago (April 13, 2021), so isn't it a little early to call 13.0 EoL?

If we follow the logic of supporting major versions for 5 years, then 13.0 would be EoL in 2026???


----------



## bakul (Sep 19, 2022)

jbodenmann said:


> EOL does indeed not translate to "lets intentionally break it". It translates to "no more support for it". This means that any changes (including in ports) are done without any regards to 13.0 (or any other EOL'd version).


It means no heroic efforts will be made to make things work!


astyle said:


> Maybe I'm being pedantic here, but according to https://www.freebsd.org/releases/, 13.0 was released just a little over a year ago (April 13, 2021), so isn't it a little early to call 13.0 EoL?


See https://www.freebsd.org/security/#sup -- a minor release is supported 3 months past the next minor release.


----------



## Alain De Vos (Sep 19, 2022)

Maybe I'm pendantic here, but i also use gentoo-linux. It's a rolling release, meaning it's always EOL.
Another point is the timeline of major-releases and the timeline of video-driver-releases. And how they interact.


----------



## zirias@ (Sep 19, 2022)

astyle, you're confusing major and minor. 13.x (from the `stable/13` branch) is supported for 5 years (and indeed, this will end in 2026). As I said, you are obliged to follow the minor releases during that time. And the transition phases for these are 3 months.

A minor release doesn't change ABI (so it won't break any existing software, there's no need to reinstall packages, etc), therefore all you need is a small maintenance window, very similar to a simple patch release.


----------



## astyle (Sep 19, 2022)

zirias@ said:


> astyle, you're confusing major and minor. 13.x (from the `stable/13` branch) is supported for 5 years (and indeed, this will end in 2026). As I said, you are obliged to follow the minor releases during that time. And the transition phases for these are 3 months.
> 
> A minor release doesn't change ABI (so it won't break any existing software, there's no need to reinstall packages, etc), therefore all you need is a small maintenance window, very similar to a simple patch release.


Ah, `stable` is for major, but `-RELEASE` is for minor??? yeah, then patchlevels `-pN` wouldn't be of any help...


----------



## zirias@ (Sep 19, 2022)

astyle said:


> Ah, `stable` is for major, but `-RELEASE` is for minor??? yeah, then patchlevels `-pN` wouldn't be of any help...


Not exactly, "major" is just the first number in the version... So there are many minor releases in one major (and there's not "the" one major relase, but at any time, there's a current minor release of each supported major...). Technically, more or less yes, as all releases for the same major are from the same `stable` branch, so support time for that branch equals support time for a major release, and that's IIRC 5 years.


----------



## astyle (Sep 19, 2022)

zirias@ said:


> Not exactly, "major" is just the first number in the version... So there are many minor releases in one major (and there's not "the" one major relase, but at any time, theres a current minor release of a major...). Technically, more or less yes, as all releases for the same major are from the same `stable` branch, so support time for that branch equals support time for a major release, and that's IIRC 5 years.


So, would 13.0 be a major or minor release??? I'd think that `.0-RELEASE` would be a _major_ release, but it seems like it's getting treated as a _minor_ release here...


----------



## zirias@ (Sep 19, 2022)

Does this self-quote answer this question? 


zirias@ said:


> there's not "the" one major relase, but at any time, there's a current minor release of each supported major



IOW, every release is a "minor release", and part of a "major release". Maybe using a wording with "version" instead of "release" would be better. (strike that, then you could ask "is 13.0 a major version", leading to the same confusion... hehe)


----------



## mer (Sep 19, 2022)

Release Information
					

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




					www.freebsd.org
				




says exactly what "production" releases are currently supported, what is EOL.
The overlap of 13.0 and 13.1 until 13.0 went EOL meant that all packages were built against Lowest Common Denominator, or 13.0.  That meant any changes to any packages were based on 13.0.  Things like drm-kmod were bound to whatever was in the kernel for 13.0.  Honestly, to the best of my recollection, this has been the "truth" for as long as I can remember (which is probably only 11.x for me using binary updates, before that I always built from source, base and ports).

The original post in this thread merely pointed out "13.0 is EOL so now drm-kmod is based on whatever support is in the 13.1 kernel".  The implication of that is "a drm-kmod built against 13.1 could break if installed on a 13.0 system"
My assumption here is trying to build drm-510-kmod on a 13.0 system would fail.  zirias@ is that a valid assumption?

Perhaps the pkg command should hard fail if the versions are "greater than or equal to":
Pkg repo built against 13.1, pkg command is being run on a 13.0 system, pkg command should hard fail everything and say "build from ports".  It would be a pain for a lot of applications that really don't depend on kernel ABI, but I think having all of them fail with an explicit message "Your version is EOL, if you want to use current packages you need to update" would be better.

Didn't we have a thread recently similar to this?  Someone complained that there were no official package repos for an EOL 12.x or 11.x system?


----------



## zirias@ (Sep 19, 2022)

mer said:


> My assumption here is trying to build drm-510-kmod on a 13.0 system would fail. _*[FONT=monospace]zirias@[/FONT]*_ is that a valid assumption?


This is correct, it never worked on 13.0, this is why the old `drm-fbsd13-kmod` was still the default on 13.


mer said:


> pkg command should hard fail everything and say "build from ports"


This wouldn't help either, as soon as 13.0 was EoL, support for it was removed from the ports tree.


----------



## mer (Sep 19, 2022)

zirias@ said:


> This wouldn't help either, as soon as 13.0 was EoL, support for it was removed from the ports tree.


I was thinking more generically:  
if the pkg command reported it's version ("Hey repo, I'm being run on a 13.0 system") the repo could respond with a hard fail of "So sorry, you must be at least 13.1 to use this repo"
That logic would work during the overlap (repo built against 13.0, 13.0 and 13.1 are valid)
Yes it means that some packages that would normally be fine won't be upgraded, but it would tend to force users to:

upgrade base so they can use prebuilt packages
start building ports against their current/static base
stay static and never upgrade base or packages

My personal opinion is everyone should upgrade sooner rather than later, but they need to feel comfortable.  I tend to run pkg upgrade every couple weeks so I pick up firefox/etc upgrades quicker, but running freebsd-update I wait a week or two letting problems shake out.  I just don't think the project should maintain official repos for EOL releases.


----------



## Harry Stone (Sep 19, 2022)

mer said:


> My personal opinion is everyone should upgrade sooner rather than later, but they need to feel comfortable. I


Or at least have pkg give a message on each run that it can break their system.

In the end it's a learning experience for me.  The FreeBSD package tool can sometimes install kernel modules that are incompatible with the running kernel, and remove drivers that were working, and the developers consider that a problem for the end user to solve because hey, EOL.  Not our problem buddy.  if you didn't want us to break your server you should have upgraded.  

I've certainly learned something about FreeBSD.


----------



## mer (Sep 19, 2022)

Harry Stone said:


> I've certainly learned something about FreeBSD.


True, but how many times will a Windows/iOs/Android update break something and you don't get any answers?  Here, you got answers.  You man not like the anwers, but you got them.
Keeping up to date is always an interesting/fragile thing.  You want to update to get latest security patches but "if it ain't broke don't fix it"

My opinions follow.  Agree, disagree, tell me I'm an a***hole, all fine with me.

For the record, I've been where you are in the past.  But I looked at it from the other side:  "Homer Simpson doh I was stupid" and should have upgraded.   A flip side would have been doing "pkg upgrade -n" and seeing something odd around drm-kmod stuff and making a choice "should I stay or should I go".  To me, no blame here on anyone, just a misunderstanding about "things".


----------



## Harry Stone (Sep 19, 2022)

It seems to me like having 'pkg upgrade' do nothing at all on an EOL system would solve this problem, and also there would be no need to try to justify it making changes to a system that is supposed to be at end of life anyway.


----------



## mer (Sep 19, 2022)

Harry Stone said:


> It seems to me like having 'pkg upgrade' do nothing at all on an EOL system would solve this problem, and also there would be no need to try to justify it making changes to a system that is supposed to be at end of life anyway.


I'm not going to argue against that, but it may break POLA.


----------



## Harry Stone (Sep 19, 2022)

mer said:


> I'm not going to argue against that, but it may break POLA.


I see your point.  If there's a long standing practice of EOL systems getting updates it might not be obvious to users that they've stopped without at the very least a message telling them so.  

On the other hand, why do EOL systems get updates anyway?  Maybe zirias should have never been put in this position in the first place.


----------



## oops (Sep 20, 2022)

Harry Stone said:


> Or at least have pkg give a message on each run that it can break their system.


Already happens since pkg 1.10.4.


----------



## Harry Stone (Sep 20, 2022)

oops said:


> Already happens since pkg 1.10.4.


obviously it didn't work in this case


----------



## zirias@ (Sep 20, 2022)

Oh, I'm pretty sure this warning works (at least IIRC, it's "just" a warning as long as the ABI still matches, and this would make sense because without ABI changes, >99% of all packages are expected to still work). If you didn't read all the output carefully, you probably just didn't see it.

FreeBSD doesn't prevent "foot shooting" (you could even override a "fatal" problem like wrong ABI if you want). You can always do unsupported things, then the system assumes you know what you're doing...

You _could_ argue pkg should outright prevent to install anything on an EoL version. Then we'd see even more threads from people complaining they can't install anything on their EoL system  (and they might rightfully ask, if 99% of packages would still work, why am I forced not to use them?)

In the end, it's simple. To avoid trouble, stick with what's supported. And IMHO, a transition phase of 3 months should be long enough for everyone, after all, a minor upgrade is quick and non-breaking. Otherwise, you could even blame it on the system when your server is cracked after you didn't install a security update....

BTW, "break your system" is strong wording for what happened here. A driver doesn't work any more. And all you have to do to make it work again is upgrade your system to 13.1. Nothing needs to be reinstalled or "fixed" otherwise.


----------



## Harry Stone (Sep 20, 2022)

I'm just never going to agree that pkg installing incompatible drivers is the right choice.  If you need to frame that as user error in order to justify it for yourself then so be it.  Good luck.


----------



## zirias@ (Sep 20, 2022)

It doesn't "just install it", it warns you. If you use, as you said, cron, so you don't ever see the warning, that's not a problem with FreeBSD tooling. And I don't "frame" anything a user error, operating an EoL system and ignoring warnings *is* a user error.


----------



## bakul (Sep 20, 2022)

Note that this drm change was documented in /usr/ports/UPDATING on May 1, 2022. But I guess most people don't update /usr/ports and even fewer look at the UPDATING file. There should be a way for the pkg program to warn the user of the latest UPDATING entries when they do "pkg update"....

While not ideal, you can checkout a local git repo of /usr/ports at the right commit and build the port yourself.


----------



## astyle (Sep 20, 2022)

mer said:


> I'm not going to argue against that, but it may break POLA.


I agree that this breaks POLA - Principle Of Least Astonishment...   It does take some thinking to realize that just patching up 13.0-RELEASE (IIRC, it's on p15) is not going to help.


----------



## sidetone (Sep 20, 2022)

Things like this happen, then it affects enough people, and it gets fixed for most within a month.

It's good when things get eol'd, but if you're unsure of your environment, wait a while to upgrade packages/ports, and start fresh with that.

I'm glad some got obsoleted and replaced with a more standard one. However, I can't afford to mess with it now, even though I could. So, I'll wait a while to reinstall packages fresh. I could have been quiet about this, but to me, it does take a little work, and while it should work without a hitch. I usually can get it to work in about a day, on this, my guess is 75% with a little bit of effort on my behalf, or even 95% also including that and within a week after reporting/troubleshooting the error, but I don't want to mess with it now, because I have to focus on other things.

I also have this healthy fear of my only computer blowing out again, while trying to upgrade. I'm scared to do anything heavy with this laptop. Sure, I could get another harddrive, and put it in but still.

I may get criticism for saying this. But most people stay quiet, and I often troubleshoot, report bugs, write on the email list, or mention it here. I can't focus on fixing it if my upgrade from 54 to 510 goes wrong right now. The improvement of video drivers will be better for the near and longterm future.


----------



## mer (Sep 20, 2022)

An interesting aspect is there is a large percentage of packages in the repo, built against 13.1 that work just fine on 13.0.  But those are applications, not something like drm-kmod which by it's nature depends on the kernel version.
I've never been a fan of blindly doing binary upgrades, simply because I've been burned in the past when something got broken.
So, to me, my opinion, is running pkg upgrade automatically from a cron job is less than optimal.
If it was only checking for updates that's fine, but to automatically perform the upgrade is not a good idea.
That's why I still run pkg upgrade -n to see if there are updates, if so, I may simply up arrow, backspace, y Enter but sometimes I'll just update one or two packages instead of all of them.

But that's just my opinion, my procedures, my way of getting my "warm and fuzzies" and it may not work for you.


----------



## zirias@ (Sep 20, 2022)

Well, in theory, package upgrades are safe.

In practice, there's a lot that can go wrong, from "forgetting" to upgrade your EoL base system  to ports fucking up dependencies by human (err committer/maintainer) error resulting in removal of half your packages ... 

mer fully agree, doing that via cron is not a great idea, unless, maybe, you're on a local repository that's only updated after testing everything on one test machine ....


----------



## jbo (Sep 20, 2022)

And once again a reasonable step would be to create a BE before upgrading so one can at least easily boot back into a running system while trying to figure out what went wrong and why if your system broke after any sort of upgrade rather than being stuck with a "broken" system.

The day I started using BEs was the day I stopped worrying _too_ much about upgrades.

Yes, this requires ZFS but personally I feel like a lot of the discussion regarding the resource/performance impact of ZFS vs UFS are negilable for anyone who has to ask about this in the first place - especially given the advantages.


----------



## mer (Sep 20, 2022)

zirias@ said:


> Well, in theory, package upgrades are safe.


"Until they aren't"

I've rarely had a problem with package upgrades.  Most recent was the nvidia-driver equivalent of what this thread is about, but my pessimism/overly cautious method let me actually see the warning and told me how to get out of it.  Other than that,there may have been a firefox upgrade that had minor breakage but was fixed very quickly.

I've also been very good about not staying on an EOL base. (I feel like I'm talking to my dogs:  whose a good boy)



jbodenmann  The day I started using BEs was the day I stopped worrying _too_ much about upgrades.

Absolutely agree with this.  I don't always create a new BE before doing a package upgrade, but "always" (or 99% of the time) create a new one before doing a freebsd-update.

It all boils down to your comfort level on doing things.


----------

