Solved firefox-72.0_1,1 Segmentation Fault

Does anyone have issues or I am the only one? Just upgraded (pkg) Firefox because of the recent security issue, and now getting segmentation fault when starting it. No error messages or anything in the logs.

% uname -v
FreeBSD 12.1-RELEASE r354233 GENERIC
 
Well that's not very helpful! I think there was a thread or 2 here about other folks having FF core dump but that was some time ago. I don't use it so can't report any issues.
 
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 the 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?

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

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!
 
Thank you very much for this!!!! I am having the same sort of problem on only ONE computer. Probably because there has been a change....somewhere...between the time I did the first machine and doing the second one. What a PITA!

Again, thanks...a big one!!! :) In plainer language, Bless you...a bunch.

Ken Gordon
 
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 the 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?

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

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!

linux will put you through this kind of shit every day though
 
The OS software repo still ships with a broken GUI for Intel and AMD chipsets, after what, a month this has been detected?
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).

This issue can present itself with every minor update during the 3 month transition period.
 
SirDice, that's exactly my point! It is being explained over and over, everyone knows about it for months, but everyone's acting like it's a feature. If FreeBSD is considered as something more than solely an experimental operating system for computer enthusiasts, I think this particular issue should be among the top in the TODO list - unless we deliberately want to piss off all new users exploring FreeBSD. It's unthinkable, for example, for any serious Linux distribution, MacOS, Windows, or just any other, to ship with a non-working X system for video cards that comprise, perhaps, 2/3 of the consumer systems out there.

And then we wonder why Linux took over FreeBSD!
 
It is being explained over and over, everyone knows about it for months, but everyone's acting like it's a feature.
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.

I think this particular issue should be among the top in the TODO list
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?
 
  • Thanks
Reactions: a6h
“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.” - Douglas Adams

Imagine a person, say, a long-term Windows or Linux user, installing FreeBSD for the first time. You know, fiddle around the system, see how it runs on a home PC. Recall how we all started... We messed around.

What kind of attitude you will develop to a system that ships BROKEN out of the box, with its prominent users saying "oh, it's actually a feature of it's own packaging concept!" 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!

What will you think if your car ships with the steering wheel falling off the axis with a note somewhere in the trunk, and the factory people saying something along "oh, but sometimes we use those particular wheels on our older models, and they work fine there!"
 
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!
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.

The system that's currently in place certainly isn't perfect. But it works for most people, most of the time.
 
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 probably organizationally infeasible to enforce even.

*Does FreeBSD even have a public/private distinction for kernel code? That might be a part of the problem.
 
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.
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.
 
SirDice, I am not the maintainer of drm-kmod, and I have limited understanding of FreeBSD architecture, 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. Perhaps, some kind of a pkg rule that checks against the kernel version and installs the correct version of drm-kmod? 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. Or at least not call 12.1 a "production" version, as it hangs after the installation on probably 2/3 of personal computers.
 
I am not the maintainer of drm-kmod,
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.

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.
Even the best AI in the world doesn't come near the flexibility and problem solving skills of the person sitting behind the keyboard.

Perhaps, some kind of a pkg rule that checks against the kernel version and installs the correct version of drm-kmod?
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.

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

Or at least not call 12.1 a "production" version, as it hangs after the installation on probably 2/3 of personal computers.
I'm fairly certain most of the install base uses FreeBSD as a server platform.
 
  • Thanks
Reactions: a6h
On the FreeBSD's web site: "FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms." I said 2/3 of personal computers, meaning desktop users, not the whole install base.

I wonder if packages should include meta-data with the ABI version they were compiled with, so pkg wouldn't even try to install a package that is not going to work. I am not suggesting to screw anybody. Just don't automatically install a package that is incompatible with the system. If a port is broken and supposed to do that then we need to find ways to appeal to port maintainers, but I don't hear anyone saying drm-kmod is broken. Is it?

And yeah, if ABI changes then we should have packages compiled for both production versions of the OS. If one of the versions is not compatible with its binary repository then it shouldn't be called a production version IMHO.
 
And yeah, if ABI changes then we should have packages compiled for both production versions of the OS.
You mean like these? http://pkg.freebsd.org/FreeBSD:12:amd64/release_1/ and http://pkg.freebsd.org/FreeBSD:12:amd64/release_0/

It's assumed the AI (Assumed Intelligence?) behind the keyboard actually sets their repository correctly though.

On a more fun note, I'm expecting 12.0 to EoL at the end of this month. February is a very short month so this whole discussion will be moot very shortly.
 
  • Thanks
Reactions: a6h
I hoped this discussion could have stayed beyond petty insults, SirDice. I don't understand your effort to protect the current behavior of the system at all costs, not to mention calling names people who are hitting this landmine. Anyways, it's your choice. This discussion may be moot in a month but with this kind of attitude we'll see the next "drm-kmod" appearing soon. It just isn't fun at all.
 
Note that I have not read through this whole thread.

Too much I read lately about people complaining when some third party software doesn't work on FreeBSD. Software that FreeBSD has no control over. And FreeBSD must change it in order to make it work but somehow it is FreeBSD's fault.

Elsewhere, this morning, I read about someone complaining in the same manner and finished with "...I understand FreeBSD is the best operating system I've ever used..." after a long tirade of complaints about incompetence.
Almost always these complaints are about desktop software and almost always the complaints come from casual users and Linux or Windows users.
And then we wonder why Linux took over FreeBSD!
No. This isn't the reason and isn't remotely related.

I've said it multiple times and I even have it in my signature. FreeBSD is a professional operating system for professionals. It's a MAC truck to get work done, not the family van. It doesn't go chasing after the latest fad but if the latest fad proves useful...we'll think about it, make sure it makes sense and follows the architecture and philosophy. FreeBSD doesn't throw anything against the wall in the hope that it sticks.

Technical excellence is more important than being popular. Being popular among the highly proficient is good, and it also brings in enthusiasts who add value and contribute, but it also drags in the amateurs who only want to play their games. These people forget where they are and start complaining to the grizzled, old veteran about why he still uses a hammer when he could be using a pneumatic gun while ignoring the stare he gets back as the sweat rolls off his furrowed brow.

Things can go wrong and break in an industrial complex that do not happen at your kitchen at home.
 
I disagree on many levels here.

1) An automatic installation of a binary package that makes the OS hang on boot is not technical excellence. There are many parts of FreeBSD that are excellent, but I disagree that we should consider this behavior to be one of them.

2) I disagree it is a third party software issue. We, of course, can take the position that the binary repository has nothing to do with the operating system, but this particular drm-kmod issue is NOT related to the third party software. E.g., citing SirDice above: "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."

3) When you say that things can break in an industrial complex the way they don't happen at my kitchen, well, we're back to the discussion of how FreeBSD is presented to the world. Are we treating FreeBSD the way we treat laboratory equipment? On the FreeBSD Advocacy Project web page:

FreeBSD very rarely crashes (and when it does it is usually due to hardware faults), but while that was a great boast a decade ago, now it is an expected feature for any operating system.

. . .

Backwards compatibility is very important to the FreeBSD team, and any release in a major release series is expected to be able to run any code—including kernel modules—that ran on an earlier version.
[And drm-kmod is actually a kernel module!]

. . .

FreeBSD gives you an easy-to-use, working, UNIX®-like system.

So, I disagree with you that FreeBSD is actually being presented to the world as a lab gear that operates in ways other operating systems aren't. If an operating system automatically installs a kernel module that makes it hang on boot then IT IS BAD, either if the operating system is intended to use by professionals or home users.

I find it alarming there is so much headwind here. Our unwillingness to acknowledge drawbacks is a bad signal.
 
Back
Top