X - no screens found - error

I have previously commented that xorg-minimal works but I have just tried it with xf86-video-intel (with /xorg.conf.d/driver-intel.conf) and got:
"EE No screens found"
I can post my Xorg.0.log if anyone is interested.
Note that I have Skylake C/GPU and I do not know if these are supported with -intel, I am fairly new to BSD world and do not know if my issue is related.

PS. drm-kmod works for me just fine, I just wonder if drm-kmod adds additional layer because I see some freezes on my system
 
I have previously commented that xorg-minimal works but I have just tried it with xf86-video-intel (with /xorg.conf.d/driver-intel.conf) and got:
"EE No screens found"
I can post my Xorg.0.log if anyone is interested.
Note that I have Skylake C/GPU and I do not know if these are supported with -intel, I am fairly new to BSD world and do not know if my issue is related.

PS. drm-kmod works for me just fine, I just wonder if drm-kmod adds additional layer because I see some freezes on my system

we tried drm-kmod but it did not help.

The issue comes from Xorg, and it is also known and reported in Linux distributions.

The best would be to have a BSD-X11 non dependent of Linux.
 
No, you're being obtuse and intentionally disruptive.
Indeed. You now have plenty of time during the next 7 days.

SirDice, again, with respect, I don't know any of you and Spartrekus may be a problem child (troll)....
That said, what I do know is that all of the remedies suggested by other participants of this thread have failed to fix the "no screens found" error on my (and others') PC. By contrast, the one solution that DID fix the error came from the guy (I presume) you just banned.
 
this line also shows up in my /var/log/Xorg.0.log and my 'CLI-only' box also has version 0.14 of libpciaccess

Can you build libpciaccess 0.13.5 from source?
Code:
cd /usr/ports/devel/libpciaccess
svn update -r438045
make clean
make reinstall

Or just grab it (only this package!) from release_0 repo, doesn't really matter.
 
UPDATE: 12, X and xfce are now re-installed and running properly (i.e., at high res) with XF86-video-nv AND Spartrekus's pkg12x package (will NOT run without pkg12x). Many thanks to all of you (especially the banned guy) for your help:
 

Attachments

  • xfce 1600x1200 001.jpg
    xfce 1600x1200 001.jpg
    99.3 KB · Views: 176
You arrived here with Xorg.0.log prominently displaying the message from nvidia-driver v. 340: "The NVIDIA GeForce4 440 Go GPU installed in this system is supported through the NVIDIA 96.43.xx Legacy drivers." Then you demanded to make it work regardless. What reaction did you honestly expect? I'm not a hardware compatibility fairy, SirDice is not a magic unicorn.
 
You arrived here with Xorg.0.log prominently displaying the message from nvidia-driver v. 340: "The NVIDIA GeForce4 440 Go GPU installed in this system is supported through the NVIDIA 96.43.xx Legacy drivers." Then you demanded to make it work regardless.....

"Demanding"? Is that how you interpret a sincere request for help fixing something that's been working and then stopped working?

Again, I'm sorry if my request for help has offended you (or anyone else), but here's my original "demanding" post re the '96 driver: "
Change of mind. Here're some of the configuration files that may be relevant just in case the fault is mine...
Note: Currently, running Nvidia 340 (legacy) driver for GeForce4 440 Go video. I also tried the "NVIDIA 96.43.xx Legacy driver" (96.43.23) (from their website), but "make install" error's out.
Also, I ONLY tried "Xorg -configure" AFTER the auto-configuration failed (repeatedly).
"

Of course, at this point, it's all academic since the problem's been fixed. Again, my apologies if I've offended or inconvenienced you. It certainly was NOT intentional. Peace.
 
Can you build libpciaccess 0.13.5 from source?
Or just grab it (only this package!) from release_0 repo, doesn't really matter.

Seems like a good idea, besides that I don't want to mess too much with my main box although it has the 'no screens' issue. Maybe that's the same for others -- how much of a mess can you handle to bring back the X...

Several people here suggest to use another BSD distro, changing and downgrading one or a few components would be a better option than to install a new OS (which should lead to a serious 'feature request' for pkg -- # pkg downgrade -1 <package>, where `-1' would be one release-version back)

After all -- my hope -- is that the issues here are soon to be resolved. When using Fedora Linux around version 10, I learned that maintainers always get in whitin a week or so, releasing the community from the 'Bleedin Edge of Disaster', and it was best to just wait for a few days -- temporary discomfort. However, I don't know how swift maintainers of FreeBSD components are. IMHO the best solution would be if those with profound knowledge just roll back the bits causing trouble on the repo, so that regular end users can go on.
 
Of course, at this point, it's all academic since the problem's been fixed. Again, my apologies if I've offended or inconvenienced you. It certainly was NOT intentional. Peace.
I'll just try to dissolve the tension a bit here (and I'm not a mod). Spartrekus isn't banned, but he has been put on a timeout. Consider the postings he did in the other thread as the proverbial drop in the bucket.
He has had many people on a very short fuse in the last weeks, and tension has risen above boiling point as a result. It's a shame, because this is one of the few really amicable forums on the web. It'll return back to normal soon.

Going back to your problem, the fix that you're using now is dangerous to say the least. What you have now is that you basically are now using a bunch of old or possibly modified packages made by someone you don't know.
Might be fine now, but will go wrong when you update from the official repositories again. Or at least it should. If it doesn't, the fix isn't in what you installed but somewhere else.
You can actually easily check that, just execute (as root) rm -rf /var/cache/pkg/* pkg upgrade -f and all packages will be updated. Don't worry, you can always go back to the solution you already had.

At this point it depends. If it is no longer working, then indeed an update (of installed software, not the OS) will break your system as-is without any other changes.
Now going back to the fix that I saw in the other thread:
Code:
cd /usr/ports/devel/libpciaccess
svn update -r438045
make clean
make reinstall
You mentioned it "didn't work". What exactly in these commands didn't work? Especially, what was the output of the svn command? This will only work if the ports tree you have is actually checked out using subversion.
Unless I'm missing something, that won't be the case with the most common installed ports tree (through portsnap) and I suspect that's where it went wrong.
So if you let us/me know how you installed the ports tree we can work from there. The general possibilities are the "normal" way using portsnap, Subversion/SVN and Git.

Also note that in your current solution you're using the open-source 'nv' driver. This and the vesa driver are most likely your only option, since the official driver no longer works. That's fine though when it works.
Just don't confuse x11/nvidia-driver-xxx and x11-drivers/xf86-video-nv
 
This will only work if the ports tree you have is actually checked out using subversion.

I copied that from the relevant PR. Indeed, portdowngrade would be more user friendly option. In that particular case:
Code:
mkdir ~/libpciaccess-workaround
cd ~/libpciaccess-workaround
portdowngrade devel/libpciaccess 438045
cd libpciaccess
make reinstall
 
You mentioned it "didn't work". What exactly in these commands didn't work?

"Didn't work" = did not eliminate the "no screens found" error that first appeared last week when running startx.


So if you let us/me know how you installed the ports tree we can work from there. The general possibilities are the "normal" way using portsnap, Subversion/SVN and Git.

Because the problem's been solved and my posts appear to do little more than incite people, I'll just say that I normally install ports during installation (i.e., selecting ports from the install options). When completed, the first thing I do is run "freebsd-update fetch" and "freebsd-update extract". It's here (within the ports) where I reckon the problem's occurring, but that's just a hunch.
Thanks.
 
When completed, the first thing I do is run "freebsd-update fetch" and "freebsd-update extract". It's here (within the ports) where I reckon the problem's occurring, but that's just a hunch.
Well, these commands are updating FreeBSD (the base OS as it's known).
EDIT: note that your second command is wrong. It should be freebsd-update install
This will not give you the latest ports tree in any way or shape.
For that, you need to run portsnap fetch && portsnap update. That is of course normally only relevant if you are not using packages, but since the problem you're hitting is related to packages you'll have to
compile devel/libpciaccess from ports until the problem has been fixed. See shkhln's post right above your post for relevant commands.
 
Well, these commands are updating FreeBSD (the base OS as it's known).
EDIT: note that your second command is wrong. It should be freebsd-update install
This will not give you the latest ports tree in any way or shape.
For that, you need to run portsnap fetch && portsnap update. That is of course normally only relevant if you are not using packages, but since the problem you're hitting is related to packages you'll have to
compile devel/libpciaccess from ports until the problem has been fixed. See shkhln's post right above your post for relevant commands.

Sorry, I confused the update procedure for 'BSD and ports (my multitasking skills aren't what they used to be).

To clarify a number of issues, I've attached screenshots of the instructions I put together for a friend when I initially installed 12 onto the Inspiron 8100 laptop in December. These're kept in the laptop case, so others can refer to them since I've wiped/reinstalled BSD to demo for other friends since then. It was during one of these demos last week that, for the first time, startx failed to start X, resulting, instead, in the "no screens found" error.

As you can see—circled in red—I installed nvidia-driver-340 for X (as I've been using BSD for many years, I still often refer to it as X-11). And this's the video driver I've been using, without issue, to run X and xfce4 since that initial 12 install in Dec.
 

Attachments

  • Image2.jpg
    Image2.jpg
    110.8 KB · Views: 211
  • Image1.jpg
    Image1.jpg
    114.5 KB · Views: 197
Code:
mkdir ~/libpciaccess-workaround
cd ~/libpciaccess-workaround
portdowngrade devel/libpciaccess 438045
cd libpciaccess
make reinstall

I ran this on a fresh install of FreeBSD 12 RELEASE p8 i386 with ports installed and was able to downgrade libpciaccess from 0.14 to 0.13.5. After that X started as normal.

The downgrade of libpciaccess also triggered to downgrade two other files because of version dependencies. So my warning here is not to fiddle around too much!!! (and I also can imagine now why not to mix ports and packages, it surely makes a mess of your system).

Reproducing the process above on my 64-bit production machine portdowngrade noted a clear and explicit "stop" because of known vulnerabilities in libpciaccess 0.13.5. So I stopped, but found it remarkable that this warning was not given on a 32-bit system.

I'll keep it with a CLI production machine, patiently waiting for an upgrade of libpciaccess. After all CLI is for productivity and GUI for socializing ;-)
 
Hi!
There have been several reports of issues with libpciaccess when using vesa or nv xorg driver (and possibly others). The issue is being tracked in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239065 . I think I have the issue circled, but I need some time to develop the fix.
As I'm not very active on this forum, the easiest way to reach out to me is either in that PR, or by mail: zeising@ . You can also use the public mailing list x11@ if needed. I'll try to keep this forum post updated as well.
Sorry for the breakage. Xorg is a big beast with many moving parts, and sometimes issues slip through.
Thank you!
Regards
Niclas Zeising
FreeBSD Graphics Team
 
I just updated the PR with a patch that hopefully mitigates the issue. The same patch is attached here as well. Please help out and try it out and report back.
The patch needs to be applied with patch -p1 -E < path/to/patch, from the top of the ports tree (or using svn patch or whatever the git equivalent is). It can also be found here:
 

Attachments

  • ports.devel.libpciaccess.0.16.diff.txt
    24.1 KB · Views: 181
mate, I need to buy you a beer. that fixed it for me on two systems. of course i have pretty much stuffed my X setup by fiddling, trying to fix the problem myself, but at least now the GUI is back.
 
Back
Top