Hello world :-) I have just upgraded my machine from 12.0-RELEASE to 12.1-RELEASE with `freebsd-update upgrade -r 12.1-RELEASE`. Unfortunately the DRM module causes machine to reboot on load. I had to get into single mode and remove DRM and i915 modules from rc.conf. I cannot see a DRM for 12.1 yet. Rebuilding module does not help. I am without DRM right now unable to use external monitor/projector. Any hints welcome :-) Tomek FreeBSD 0xCFMX4 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64 0xCFMX4% pkg info drm-kmod drm-kmod-g20190710 Name : drm-kmod Version : g20190710 Installed on : Thu Nov 7 11:55:49 2019 CET Origin : graphics/drm-kmod Architecture : FreeBSD:12:* Prefix : /usr/local Categories : graphics Licenses : Maintainer : x11@FreeBSD.org WWW : https://github.com/FreeBSDDesktop/kms-drm Comment : Metaport of DRM modules for the linuxkpi-based KMS components Annotations : Flat size : 0.00B Description : amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components on amd64, i915 and radeonkms DRM modules from the former base DRM component on other architectures. Metaport for different versions of Linux DRM based on the FreeBSD version in use. This port encompasses the recommendations of the FreeBSDDesktop team of DRM versions for FreeBSD versions based on the last update to the LinuxKPI in that code base. In general, the most recent supported stable DRM for a give FreeBSD version will be installed. CURRENT receives the most recent development DRM. This port does not however hinder the expert user to make other decisions and continue to install DRM ports directly. WWW: https://github.com/FreeBSDDesktop/kms-drm
Could that be related? https://github.com/FreeBSDDesktop/kms-drm/issues/183
*** This bug has been marked as a duplicate of bug 241101 ***
Why not just create two additional ports? These already exist: /usr/ports/graphics/drm-fbsd11.2-kmod /usr/ports/graphics/drm-fbsd12.0-kmod Create these (along with packages against 11.3 and 12.1 source): /usr/ports/graphics/drm-fbsd11.3-kmod /usr/ports/graphics/drm-fbsd12.1-kmod Problem solved. Treating older 12.0 version as 'more important' instead of newer 12.1 seems out of logic. Regards.
I fully agree, this module is highly experimental, not production ready, should be banned from a RELEASE and PKG because it breaks them in many ways on a production environments. The problem with PKG is that 12.1 packages are built on 12.0 system, while this module changed KERNEL API and this is the root cause of the problem. SO LINUX :-( Here is a bug to follow: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241101
(In reply to vermaden from comment #3) That won't help the situation. The problem is that ports are built on the lowest common platform, which means, for 12 it is built on 12.0 until 12.0 is EOL (same for 11.2 and 11.3). The issue here is that while the kernel modules are indeed compatible with their respective branch (drm-fbsd11.2-kmod works on 11.3 and 11-stable, and 12.0-kmod on 12.1 and 12-stable), they have to be built together with kernel sources of the same version of the kernel actually running the module. Creating drm-fbsd12.1-kmod, or 11.3-kmod would not help, they would either be built on 12.0 and 11.2 respectively (well, 11.2 is EOL now, so the 11.2 module should work on 11.3 out of the box these days), or not built at all, depending on how the version check in the ports' Makefile is set up. I can agree that the naming of the modules are unfortunate and somewhat confusing, but renaming 11.2-kmod to 11.3-kmod was ruled out when Rene removed 11.2 support from the ports tree. See https://reviews.freebsd.org/D21974 for that discussion. In the end, the ambition is to have the user simply install drm-kmod and let that port pick the proper kernel module port for your specific system. Regards Niclas Zeising FreeBSD Graphics Team. PS. Please keep the discussion in the open PR (or the github issue, it gets more visibility that way).
(In reply to Niclas Zeising from comment #5) That is the root cause of the problem. Packages for 12.1 should be built on 12.1. Other - more important aspect of such bugs/problems - why FreeBSD would instantly panic on loading a module with wrong version? This is so Windows like. It was the same with VirtualBox package between 11.2 and 11.3 when VNET became the default on 11.3. IMHO the first thing to do should be making these modules NOT INSTANTLY PANIC entire system. Second should be separate package repositories for each version, currently for 'Production' releases which means - 12.1 / 12.0 / 11.3 - as stated on FreeBSD page. Current situation is far from 'production ready'. Regards.
(In reply to vermaden from comment #6) > Packages for 12.1 should be built on 12.1. If we did that, as soon as 12.1 came out, we would have stranded the users of pkg on 12.0 (you can't assume you can go downwards). Or, we could buy enough hardware to have every single branch built -- plus, enough people to look after the build results. (disclaimer: I am one of the people that looks after the build results) No, it can't be farmed out to virtual instances somewhere, due to security implications. tl:dr; some thought has actually gone into these decisions. This is the one rare case where we've been bitten.
(In reply to vermaden from comment #6) > That is the root cause of the problem. Packages for 12.1 should be built on 12.1. I would humbly point that the root cause is Kernel API changes between releases of the same major number.. maybe even different major number. If we had an architecture designed first in a way that would provide stable Kernel API there would be no problem at all. Kernel API changes between each release is so Linux. It smells like a maintenance nightmare we are observing right now because we try to fix the problem that creates a complication with a new complications. Is it really necessary here in FreeBSD? I don't think so. Is there really no way to avoid it? :-)
From naive user's point of view this problem can be described as 'bad user experience' when executing action according to the documentation (# freebsd-update -r XX.X-RELEASE upgrade) lead to a dead system. Very rough estimation shows that this problem can be potentially triggered by any of ~56 ports: # find /usr/ports -type f -name Makefile|xargs cat|grep USES|grep kmod|wc -l Moving graphics/drm entirely into ports (e.g. no binary packages for users) will kick back FreeBSD into stone age and discard all enormous and amazing work done by graphics team (IMHO). How about *in addition* to whatever solution will be found for the graphics/drm package change behavior of 'freebsd-update'? Well, strictly speaking - pitch such idea to mainstream FreeBSD developers? If user execute 'freebsd-update -r XX.X-RELEASE upgrade' the script analyze current content of /etc/rc.conf and /boot/loader.conf and detect presence of configuration that includes loading of 3rd-party modules (any kernel module not shipped with the base system). If such presence is detected - freebsd-upgrade print warning message and exit (refuse to execute upgrade) until user disable 3-rd party modules in his/her config files or specify new argument such as: # freebsd-update -r XX.X-RELEASE --UNSAFE upgrade Doing this will eliminate unintentional unsafe upgrade and mitigate possible bad UX. Regards, Denis
The solution is simple. Just build packages for FreeBSD 12.1 on 12.1 system. You are wasting time looking for other solutions/workarounds. Eventually to save time/compute power first use 12.0 packages and then rebuild 'problematic' or kernel related packages again so that 12.1 packages will be fully working out of the box. The situation where the most up to date FreeBSD 12.1 is less supported (and broken) then older 12.0 version seems stupid to me to say the least ... Regards, vermaden