Various problems to fix before to be able to login as a low level user....

free-and-bsd said:
Then how does it load ok manually after boot is complete?
Click to expand...
I don't know, that's why I'm asking. If the BIOS is set to "use this for the default" that typically means "during the boot of the computer" but does not mean that it becomes the default device chosen for vgapci0 by the OS.
By the time he is able to log in as root, maybe the kernel has fully enumerated the bus and actually sees an i915 capable device.
 
mer said:
I don't know, that's why I'm asking. If the BIOS is set to "use this for the default" that typically means "during the boot of the computer" but does not mean that it becomes the default device chosen for vgapci0 by the OS.
By the time he is able to log in as root, maybe the kernel has fully enumerated the bus and actually sees an i915 capable device.
Click to expand...
It actually means that THE OTHER DEVICE IS NOT AVAILABLE to the system.
 
free-and-bsd said:
It actually means that THE OTHER DEVICE IS NOT AVAILABLE to the system.
Click to expand...
Disagree. If you say "disabled" yes, but "default" is not "disable all the other ones". Look at the pciconf output he posted. The kernel is detecting every single one of the devices.
 
ziomario Are the Nvidia devices on separate cards or are they built it? Can you physically remove them from the computer or explicitly Disable them in the BIOS? If you can do either of that, could you try remove/disable so only the i915 device is available to the kernel and see what happens after a reboot without explicitly kldload as root?

I've got a system with an internal i915 device and a PCI card with Nvidia. I want to use the nvidia so I have the opposite of you.
In the BIOS I explicitly DISABLE the internal i915 graphics. When system boots I load the Nvidia DRM bits and pciconf -l shows ONLY the Nvidia device. In the past, without the explicit disable things got confused. It's been a while since I've mucked with that, but I do know what the system shows for devices right now.

You could also install the Nvidia driver stuff and use that if you want.
 
mer said:
Disagree. If you say "disabled" yes, but "default" is not "disable all the other ones". Look at the pciconf output he posted. The kernel is detecting every single one of the devices.
Click to expand...
I'm wrong here, sorry. Though, if it's not a laptop, it will only use the one attached to monitor.
But that pciconf output shows there are 3 , not 2 graphics cards.
 
mer said:
ziomario Are the Nvidia devices on separate cards or are they built it? Can you physically remove them from the computer or explicitly Disable them in the BIOS? If you can do either of that, could you try remove/disable so only the i915 device is available to the kernel and see what happens after a reboot without explicitly kldload as root?

I've got a system with an internal i915 device and a PCI card with Nvidia. I want to use the nvidia so I have the opposite of you.
In the BIOS I explicitly DISABLE the internal i915 graphics. When system boots I load the Nvidia DRM bits and pciconf -l shows ONLY the Nvidia device. In the past, without the explicit disable things got confused. It's been a while since I've mucked with that, but I do know what the system shows for devices right now.

You could also install the Nvidia driver stuff and use that if you want.
Click to expand...
Do you have to do that? On my system, whenever 'discreet' video card is attached, the internal Intel will not even work.
 
free-and-bsd said:
I'm wrong here, sorry. Though that pciconf output shows there are 3 , not 2 graphics cards.
Click to expand...
Not a problem; that's why I asked for that specific output. Multiple graphics cards in theory should not be an issue, trying to use them all in X takes a bit of xorg.conf magic with specifying bus ids and such, but this is weird.
dmesg is showing the i915 is recognized as the boot device, but something else must be preventing the module from loading in rc.conf. The posted rc.conf looks correct (aside from the sound/snd stuff), that should be happening late enough in the boot sequence to work, but obviously it's not. I wonder is there is any debug sysctl that can be turned on to log failures to load during boot.
Speculation here: I wonder if because of 3 devices the resource enumeration is not complete when the i915 module gets loaded during rc.conf and that causes the driver to not load. Then by the time he can log in, that's all straight and the driver loads fine.

free-and-bsd said:
Do you have to do that? On my system, whenever 'discreet' video card is attached, the internal Intel will not even work.
Click to expand...
I think that is system (BIOS) dependent. My desktop that has the Nvidia card is on a Gigabyte mobo and I know I had issues if both were left enabled. I can see a BIOS going "if I see a video card plugged into a slot I will disable the internal device", maybe even UEFI booting letting you specify exactly which video device is enabled.
 
ziomario sorry if I got a little off base; I still think if you can disable/remove the NVIDIA devices you will get the best data on the root cause.
If not, the way it is now, if you login as root, kldload i915, logout, login as your user, you should be able to startx as your user since you added user to video group.

Then it becomes "Can we add a kldload i915 somewhere as a workaround to this"? free-and-bsd suggestion of adding a line in /etc/rc.conf.local is a good place to start.

Edit:
Actually looks like the correct thing would be as root to create
/etc/rc.local
with the kldload i915 line in it.
 
mer said:
ziomario Are the Nvidia devices on separate cards or are they built it? Can you physically remove them from the computer or explicitly Disable them in the BIOS? If you can do either of that, could you try remove/disable so only the i915 device is available to the kernel and see what happens after a reboot without explicitly kldload as root?

I've got a system with an internal i915 device and a PCI card with Nvidia. I want to use the nvidia so I have the opposite of you.
In the BIOS I explicitly DISABLE the internal i915 graphics. When system boots I load the Nvidia DRM bits and pciconf -l shows ONLY the Nvidia device. In the past, without the explicit disable things got confused. It's been a while since I've mucked with that, but I do know what the system shows for devices right now.

You could also install the Nvidia driver stuff and use that if you want.
Click to expand...

No. The Bios let me only choose the default graphic card that I want to boot the computer with. I can't disable the other ones. And anyway,even if I can do it,I will not do it because I want to try to passthrough them inside the bhive VM. The nvidia cards aren't built in. They are placed on the same PCI express bus,if I remember well.
 
  • Like
Reactions: mer
Ok, sounds good. I think the best thing is to figure out if you can put the kldload statement in an rc script and have it work.

Sorry I can't help more than that.
 
mer Anyway,you have found a good workaround. I had not thought to logout as root and re-login as normal user. It worked. And as normal user I can see the content of the mounted disks,as root I can't. Now,I would like to know if it is a bug. As root,that means that I have all the powers,I should have the ability to show the content of a mounted disk. Or not ? I'm angry that as low level user I can do what I can't do as root. It is not acceptable.

Istantanea_2021-08-09_19-10-58.png
 
  • Like
Reactions: mer
ziomario said:
yes,I know. but the first question of this thread : https://forums.freebsd.org/threads/kld_list-i915kms-does-not-stick-on-etc-rc-conf-at-all.81445
has been :


Hello.

I've added this parameter to /etc/rc.conf :

kld_list="i915kms"

adding it on the rc.conf file should make the setting permanently,right ? But why,everytime I reboot the PC and I come back to FreeBSD,I should write "kldload i915kms",otherwise Xorg does not start,causing the error "cannot run in framebuffer mode. Please specify busIDs" ?

so,its the first thing that I tried,don't u think ? that problem is stil there,man.
Click to expand...
Yesterday I installed FreeBSD on my HP Stream laptop, and saw this "cannot run in framebuffer mode" error, after I had installed drm-kmod, but before I had installed xf86-video-intel. After pkg install xf86-video-intel the error went away, and X started normally.

As I've mentioned elsewhere, I did not put kld_list="i915kms" in /etc/rc.conf. It gets loaded automatically during the startx process. After reading this thread, I'm guessing now that xf86-video-intel might have something to do with this.
 
ziomario I'm not sure what the behaviour should be in the utilities, simply because I don't use them.
Opinion:
A lot of the different file managers will use variations of automount and "gvfsd" to mount hot pluggable media (USB thumb drives). They may have restrictions on users (or root) as to what is visible, so I don't know if you are seeing a bug or not.

I'm old school. Like really old school. Moses and the Ten Commandments on stone tablets is more advanced than me :)
I use old school window managers, I create a term window, su/sudo and mount a device.
Graphical file mangers are a waste of my time BUT I recognize they can be useful to people (Heck Macs have had them forever).
Your da1 is a removable media of some kind, so I'm guessing that Thunar uses a bunch of stuff that magically mounts it for your user. It is also likely that there is something magically preventing root from doing the same thing. I just don't know.
 
ziomario said:
I'm angry that as low level user I can do what I can't do as root. It is not acceptable.
Click to expand...
Yeah, as root you can do anything you want. In the console. X11 was never meant to be run as root, so you shouldn't really complain about things not working when you try to use X11 as root. Thunar wasn't designed to be used as root or to mount your drives as root. This has nothing to do with FreeBSD in the first place.

You know you can simply use sudo or doas to issue commands as root without actually logging in as root, right?
 
ziomario said:
No. The Bios let me only choose the default graphic card that I want to boot the computer with. I can't disable the other ones. And anyway,even if I can do it,I will not do it because I want to try to passthrough them inside the bhive VM. The nvidia cards aren't built in. They are placed on the same PCI express bus,if I remember well.
Click to expand...
Why in that case you can configure pci_passthrough at boot time, in which case neither card will be usable by the system.
If you're NOT going to use them for video output, then do it right away and be done with it :D :D
And put an end to all your troubles as well!!!
 
dieselriot said:
Yeah, as root you can do anything you want. In the console. X11 was never meant to be run as root, so you shouldn't really complain about things not working when you try to use X11 as root. Thunar wasn't designed to be used as root or to mount your drives as root. This has nothing to do with FreeBSD in the first place.

You know you can simply use sudo or doas to issue commands as root without actually logging in as root, right?
Click to expand...

As root I didn't find one only file manager that shows the content of a mounted ext4 / ntfs disks and I've tried many. I believe that a user who is not particularly familiar with computers in general certainly does not expect that with maximum powers on his machine he is not able to view the contents of his disks. Doesn't that sound too limiting to you ? I think there must be a limitation to what can be secured and what not, otherwise the concept of security becomes egual to the concept of a paranoid syndrome. Who is the owner of the PC,of the disks,of the informations inside ? the programmers or it belongs to the person that uses it ? Because often I see that the programmers impose too much what they think is right. I use Linux from a lot of years and I never seen this behavior. When I login as root I see the content of every disk I mount.
 
Last edited:
A user who is not particularly familiar with computers shouldn't be doing everything as root in the first place. The potential for disaster is enormous. It's not just about "security", it's also about not fucking up your system by accident.

ziomario said:
does not expect that with maximum powers on his machine he is not able to view the contents of his disks.
Click to expand...

You can view the contents of your disks as root. You can either mount them manually as root and access them from the console, access them from a file manager, or even setting up automounting and accessing automounted drives as root. It's all there in the handbook.

The problem is, you're expecting an application that wasn't designed to be used as root, to behave like it does when you run it as a regular user. File manager developers don't care if automounting as root works because they weren't designed to be used like that in the first place.
 
Vull said:
Yesterday I installed FreeBSD on my HP Stream laptop, and saw this "cannot run in framebuffer mode" error, after I had installed drm-kmod, but before I had installed xf86-video-intel. After pkg install xf86-video-intel the error went away, and X started normally.

As I've mentioned elsewhere, I did not put kld_list="i915kms" in /etc/rc.conf. It gets loaded automatically during the startx process. After reading this thread, I'm guessing now that xf86-video-intel might have something to do with this.
Click to expand...
Easy to check what is installed with xf86-video-intel:
Code: 
pkg info -l xf86-video-intel
xf86-video-intel-2.99.917.916,1:
    /usr/local/lib/libI810XvMC.so
    /usr/local/lib/libI810XvMC.so.1
    /usr/local/lib/libI810XvMC.so.1.0.0
    /usr/local/lib/libIntelXvMC.so
    /usr/local/lib/libIntelXvMC.so.1
    /usr/local/lib/libIntelXvMC.so.1.0.0
    /usr/local/lib/xorg/modules/drivers/intel_drv.so
    /usr/local/man/man4/intel.4x.gz
    /usr/local/share/licenses/xf86-video-intel-2.99.917.916,1/LICENSE
    /usr/local/share/licenses/xf86-video-intel-2.99.917.916,1/MIT
    /usr/local/share/licenses/xf86-video-intel-2.99.917.916,1/catalog.mk
I don't see any single file other then driver and its shlibs... And I can confirm that when I remove "i915kms" from kld_list, it doesn't load automatically.
EDIT: So what I mean to say, this is, obviously, NOT a type of behaviour users of this driver can reliably expect.
But then, we have the good old /etc/rc.conf.local /usr/local/etc/rc.d/rc.local that can be used to "patch" some inexplicable irregular kind of things ;) ;)
That's the beauty of it, isn't it? No such thing in Windows LOL.
 
free-and-bsd said:
Easy to check what is installed with xf86-video-intel:
Code: 
pkg info -l xf86-video-intel
xf86-video-intel-2.99.917.916,1:
    /usr/local/lib/libI810XvMC.so
    /usr/local/lib/libI810XvMC.so.1
    /usr/local/lib/libI810XvMC.so.1.0.0
    /usr/local/lib/libIntelXvMC.so
    /usr/local/lib/libIntelXvMC.so.1
    /usr/local/lib/libIntelXvMC.so.1.0.0
    /usr/local/lib/xorg/modules/drivers/intel_drv.so
    /usr/local/man/man4/intel.4x.gz
    /usr/local/share/licenses/xf86-video-intel-2.99.917.916,1/LICENSE
    /usr/local/share/licenses/xf86-video-intel-2.99.917.916,1/MIT
    /usr/local/share/licenses/xf86-video-intel-2.99.917.916,1/catalog.mk
I don't see any single file other then driver and its shlibs... And I can confirm that when I remove "i915kms" from kld_list, it doesn't load automatically.
EDIT: So what I mean to say, this is, obviously, NOT a type of behaviour users of this driver can reliably expect.
But then, we have the good old /etc/rc.conf.local that can be used to "patch" some inexplicable irregular kind of things ;) ;)
That's the beauty of it, isn't it? No such thing in Windows LOL.
Click to expand...
No it's from drm-kmod but maybe the software in the intel driver helps to identify what it needs. Without looking at sources or disassembly all I can do is guess.
Code: 
root@fzfs:~ # pkg info -l drm-fbsd13-kmod-5.4.92.g20210419
drm-fbsd13-kmod-5.4.92.g20210419:
    /boot/modules/amdgpu.ko
    /boot/modules/drm.ko
    /boot/modules/i915kms.ko
    /boot/modules/linuxkpi_gplv2.ko
    /boot/modules/radeonkms.ko
    /boot/modules/ttm.ko
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/BSD2CLAUSE
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/GPLv2
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/LICENSE
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/MIT
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/catalog.mk
root@fzfs:~ #
 
Vull said:
No it's from drm-kmod but maybe the software in the intel driver helps to identify what it needs. Without looking at sources or disassembly all I can do is guess.
Code: 
root@fzfs:~ # pkg info -l drm-fbsd13-kmod-5.4.92.g20210419
drm-fbsd13-kmod-5.4.92.g20210419:
    /boot/modules/amdgpu.ko
    /boot/modules/drm.ko
    /boot/modules/i915kms.ko
    /boot/modules/linuxkpi_gplv2.ko
    /boot/modules/radeonkms.ko
    /boot/modules/ttm.ko
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/BSD2CLAUSE
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/GPLv2
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/LICENSE
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/MIT
    /usr/local/share/licenses/drm-fbsd13-kmod-5.4.92.g20210419/catalog.mk
root@fzfs:~ #
Click to expand...
Did you answer any questions about your graphics subsystem during install?
Because I usually don't use bsdinstall, but rather do manual install... because of my disk configuration and other OSs installed alongside.
 
free-and-bsd said:
Did you answer any questions about your graphics subsystem during install?
Because I usually don't use bsdinstall, but rather do manual install... because of my disk configuration and other OSs installed alongside.
Click to expand...
No there are no such questions. As you know, FreeBSD is not a desktop-centric OS like Linux tends to be. Such info wouldn't be nearly so critical for a lot of FreeBSD uses, such as, for instance, a headless server configuration. A bare bones FreeBSD configuration will nevertheless detect most supported and unsupported devices during the boot process, as we can later review in the dmesg output. Install xorg, etc., and voila, all that information is ready and available when and if it's needed.
 
I have installed xf86-video-intel,I did not put kld_list="i915kms" in /etc/rc.conf and X started normally. Vull solution worked. Very thanks to everyone. There are experienced and tenacious people here.
 
ziomario said:
I have installed xf86-video-intel,I did not put kld_list="i915kms" in /etc/rc.conf and X started normally. Vull solution worked. Very thanks to everyone. There are experienced and tenacious people here
Click to expand...
Yes, Vull is right :). And I was deceived by the fact that fb mode didn't start at boot time. But it only means, the driver is loaded by X itself... which is usually somehow NOT the case.
 
ziomario said:
are u telling that there is something mis configured in my system ?
Click to expand...
No :) I'm saying that the same thing is happening on my laptop with i915kms. I just didn't try starx when I saw the driver was NOT loaded. But when I tried -- it worked!
But this is quite unusual because with nvidia driver, for example, it will not be loaded by startx.

Still, I wonder: why do you need to passthrough your PCI-e videocards to bhyve? What's so special about your planned bhyve usage that you think simple VLC access will not be good enough?
 
You must log in or register to reply here.
Back
Top