pkg upgrade
- about 454 packages, 400 MB download. Reboot, black screen. Oh, the freaking drm-kmod is still broken! I cannot believe this. The OS software repo still ships with a broken GUI for Intel and AMD chipsets, after what, a month this has been detected? fsck
, fixing stuff, then mounting the root read-write, editing rc.conf. Done. Then doing make deinstall
of the broken drm-kmod, then make install
- nothing, clear screen. No error messages. Something's odd. make deinstall
, looks like, doesn't remove the binary package that was automatically installed by pkg
. Fine... At least it could've said something! pkg deinstall
, then make install
of the drm-kmod from ports to get the X back. Editing rc.conf again. Now everything's back working. All that crap just to get the Firefox upgraded... pkg install graphics/drm-fbsd12.0-kmod
kld_list="/boot/modules/i915kms.ko"
Fixed. I freaking hate when FreeBSD is doing this...
So, some other apps weren't starting after the Firefox upgrade. Something is odd - I guessed Firefox upgrade has pulled some dependencies in. Right, did thepkg upgrade
- about 454 packages, 400 MB download. Reboot, black screen. Oh, the freaking drm-kmod is still broken! I cannot believe this. The OS software repo still ships with a broken GUI for Intel and AMD chipsets, after what, a month this has been detected?
Reboot into single user mode, trying to edit rc.conf to get rid of the broken drm-kmod. Read-only file system. Obviously, the hard reboot caused by broken module did something to the file system. Doingfsck
, fixing stuff, then mounting the root read-write, editing rc.conf. Done. Then doingmake deinstall
of the broken drm-kmod, thenmake install
- nothing, clear screen. No error messages. Something's odd.make deinstall
, looks like, doesn't remove the binary package that was automatically installed bypkg
. Fine... At least it could've said something!pkg deinstall
, thenmake install
of the drm-kmod from ports to get the X back. Editing rc.conf again. Now everything's back working. All that crap just to get the Firefox upgraded...
But seriously... If I would be approaching a Unix/Linux system as a beginner, and it would give me this shit, I would remove it in an instant. Although I remember spending endless nights lurking out of dependency hell on a Slackware with 0.99 kernel. FreeBSD is a lego sometimes, and one that occasionally requires to hammer some pieces in!
Oh, the freaking drm-kmod is still broken!
pkg lock -y drm-fbsd12.0-kmod
pkg lock -y gpu-firmware-kmod
And the reason has been explained a million times already. The default package repositories are still being built for 12.0 because that's the lowest, still supported, version. This is fine for 99.9% of the packages but can cause problems with 3rd party kernel modules, like the one installed with graphics/drm-mod. We're talking about 3 or 4 packages out of 38000+ that are problematic. This will automatically resolve itself when 12.0 is EoL and the packages will get built for 12.1. During the 3 month transition period, either build those problematic kernel modules from ports or use the release_1 package repository (those are specifically built for 12.1; but only the latest branch is available).The OS software repo still ships with a broken GUI for Intel and AMD chipsets, after what, a month this has been detected?
unless we deliberately want to piss off all new users exploring FreeBSD
It's not a feature. But it is something you could have known in advance and acted accordingly to prevent it. Don't blame FreeBSD for your failure.It is being explained over and over, everyone knows about it for months, but everyone's acting like it's a feature.
It's explicitly mentioned in the errata notes. Several solutions have been provided. What more do you want? You want the package repositories to build for 12.1 as soon as it's available? That's fine, but what about those people that are still on 12.0 and almost all of their packages fail to install or work?I think this particular issue should be among the top in the TODO list
Well, what do you suggest for a solution then? Make sure your solution works for every supported version, on every supported architecture, now and in the future. And, by your own requirements, has to work out of the box.We need a new freaking approach to the repositories if a previous version prohibits the current one to work out of the box. I just can't wrap my head around how it cannot be obvious!
That certainly doesn't help. But the alternative is that people are going to have to wait until the next major version comes out in order to use that shiny new graphics driver. So you're damned if you do and damned if you don't.Afaik, the root of the issue is that the kernel ABI* is supposed to be stable within a major version. This is not consistently enforced.
It's not an issue specific to this port/package. It's due to the way the entire ports structure and accompanied package repositories work. During this period it just happens to be to one that's most noticeable. I've had the exact same issues in the past with other kernel modules. These things happen.I am not the maintainer of drm-kmod,
Even the best AI in the world doesn't come near the flexibility and problem solving skills of the person sitting behind the keyboard.but it's rather puzzling that in this age of neurointerfaces, when AI is writing poems and creating other forms of art, the age of self-driving trains and cargo ships, the mundane task of installing the correct version of a software package even remotely appears as unachievable.
That's exactly what the port does. And the problem isn't related to the version but with the way a compiled binary works. Once it's been compiled it can't just change its ABI calls. So it tries to call an ABI which now lives on another address (due to the changes in the kernel). That's also why if they fail, they fail catastrophically.Perhaps, some kind of a pkg rule that checks against the kernel version and installs the correct version of drm-kmod?
In other words, screw the current install base that's still running 12.0 in favor of a handful of potential new users that can't read simple instructions? There is a reason why there's a 3 month transition period in the first place. It's to give the current user base time to upgrade.If this is impossible then by any means, I would vote for the repository to match the latest production version of the system, which is 12.1.
I'm fairly certain most of the install base uses FreeBSD as a server platform.Or at least not call 12.1 a "production" version, as it hangs after the installation on probably 2/3 of personal computers.
You mean like these? http://pkg.freebsd.org/FreeBSD:12:amd64/release_1/ and http://pkg.freebsd.org/FreeBSD:12:amd64/release_0/And yeah, if ABI changes then we should have packages compiled for both production versions of the OS.
No. This isn't the reason and isn't remotely related.And then we wonder why Linux took over FreeBSD!