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



## ziomario (Aug 9, 2021)

Hello.

After that several users told me that I shouldn't work on my FreeBSD installation as root,I've got the decision to login as a low level user,even if my sensible informations aren't on the FreeBSD disk,so I should not care. But I care,because security is always important. Firstly because I'm learning and I should keep it in mind from the beginning,and second because it's not right to give the bad example to the other people. So,ok. I want to login as a low level user,but unfortunately at the moment I have some problems to fix before to be able to do that. I tried to fix them by myself,but the solutions that I found are partially. So,I'm here again to ask help. The problems that I need to fix are the following :

1) when I tried to login to FreeBSD inserting my low level username and password,I got the error : "https://forums.freebsd.org/threads/kld_list-i915kms-does-not-stick-on-etc-rc-conf-at-all.81445/#post-524306)". That's because usually,when I login as root,I start Xorg with the following script :


```
kldload i915kms
startx
```

what's the problem ? that as root,I can do "kldload i195kms" without problems. but as a low level user,I can't do it. If I do it,the error becomes :

*kldload: can't load i915kms: Operation not permitted*

this error persists even if I have added the low level user marietto inside the wheel group with this command :



```
root@marietto:/ # pw group mod -n wheel -m marietto
```


2) after having logged in as root,I tried to becomes low level user with :



```
root@marietto:~ # su - marietto
```

and then I tried to show the content of one of my disks (in the example below it is formatted with ntfs and the disk is mounted within the /etc/fstab file) and as u can see,from the terminal I can see what's inside it :


```
marietto@marietto:/mnt $ ls da0p1

$RECYCLE.BIN            Desktop                Serie-TV
Animazioni            Domotica            System Volume Information
Backups                Downloads            vms
CG                OS
CG2                OurStories
```


but if I want to use thunar,this is what happens :


```
marietto@marietto:/mnt $ thunar

thunar: Failed to initialize Xfconf: can't launch automatically D-Bus without $DISPLAY X11

Unable to init server: can't connect to 127.0.0.1: Connection refused

(thunar:1874): Gtk-WARNING **: 13:33:52.019: cannot open display:
```

As u can imagine,if I don't fix these problems asap,I can't login with the low level account,but only as root,because as root I don't have such problems.


----------



## eternal_noob (Aug 9, 2021)

ziomario said:


> that as root,I can do "kldload i195kms" without problems. but as a low level user,I can't do it.


You are supposed to add the i195kms module to /etc/rc.conf so it does get loaded automatically.

```
kld_list="i915kms"
```

And don't forget to add your normal user to the video group:

```
pw groupmod video -m <username>
```

See https://wiki.freebsd.org/Graphics and https://docs.freebsd.org/en/books/handbook/x11/


----------



## ziomario (Aug 9, 2021)

You didn't read the post that I have started some time ago and that's still open (https://forums.freebsd.org/threads/kld_list-i915kms-does-not-stick-on-etc-rc-conf-at-all.81445/#post-524306) where I told that I have already added "kld_list="i915kms" on the file /etc/rc.conf. It is not enough because I have several graphic cards in my PC and FreeBSD for some reason,is confused and it is not able to load the proper driver automatically in the right place at the right time. At the moment there isn't any solution to fix the problem at the root. The only solution is to run,as root,this script :


```
startx.sh

kldload i915kms
startx
```

or,if there is a method to kldload i915kms as a low level user. Do u know if and how can I  do this ?

PS : I'm checking if "pw groupmod video -m marietto" works or not.

it doesn't....


```
root@marietto:/mnt # pw groupmod video -m marietto

root@marietto:/mnt # su - marietto

marietto@marietto:~ $ kldload i915kms

kldload: can't load i915kms: Operation not permitted
```


----------



## SirDice (Aug 9, 2021)

ziomario said:


> It is not enough because I have several graphic cards in my PC and FreeBSD for some reason,is confused and it is not able to load the proper driver automatically in the right place at the right time.


That issue has nothing to do with the kernel module.


----------



## ziomario (Aug 9, 2021)

SirDice said:


> That issue has nothing to do with the kernel module.



Unfortunately I can't start xorg if the i915kms driver is not loaded automatically from /etc/rc.conf. I can do it later,as root,but not as a low level user. If u want to understand better what's the problem,you can read this post made by vull,that has checked deeply inside my log file :









						kld_list="i915kms" does not stick on /etc/rc.conf at all.
					

Sorry, meant to say /boot/modules/drm.ko My mistake




					forums.freebsd.org
				




So,If I login using a low level user,xorg will not start. And I can't use FreeBSD at all without it.


----------



## SirDice (Aug 9, 2021)

That has nothing to do with the kernel module but with your Xorg configuration.


----------



## free-and-bsd (Aug 9, 2021)

Well, as I see it, you FIRST complete your installation (as root), make sure everything works as you want it. Then, when you are sure everything works fine, you can work as regular user.

Neither can you launch any GUI app (thunar) without launching X first.


----------



## eternal_noob (Aug 9, 2021)

ziomario said:


> You didn't read the post that I have started some time ago and that's still open (https://forums.freebsd.org/threads/kld_list-i915kms-does-not-stick-on-etc-rc-conf-at-all.81445/#post-524306) where I told that I have already added "kld_list="i915kms" on the file /etc/rc.conf.


No, i didn't read that thread. You should get it working first before you try anything else.


ziomario said:


> if there is a method to kldload i915kms as a low level user. Do u know if and how can I do this ?


I don't know, like i said, you're supposed to load kernel modules in /etc/rc.conf. Everything else is ugly and not recommended.


----------



## ziomario (Aug 9, 2021)

So,If I'm not able to fix the first problem,because I'm not so expert,what else I can do ? I have no idea about how to fix it. It's too much complicated for me. And As I see,also for some of you. I'm sorry,at the moment the only method I have to use FreeBSD and continue to learn is to login as root. But if u want to help me more deeply (not only giving to me generic suggestions for complicated problems) I will be happy to stop using root. Thanks for your understanding.


----------



## SirDice (Aug 9, 2021)

Just make sure you have `kld_list="i915kms"` in /etc/rc.conf. That's all you need to do. After a reboot check with `kldstat` if the module has loaded.


----------



## ziomario (Aug 9, 2021)

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.


----------



## SirDice (Aug 9, 2021)

No, initially you have `kld_list` twice in rc.conf. And that's what your issue seems to be, not understanding that rc.conf is just a collection of shell variables, they're not commands.


```
dice@molly:~/test % cat test.sh

foo="bar"
foo="not bar"

echo $foo

dice@molly:~/test % sh test.sh
not bar
```
See, the second definition of `foo` overwrote what was set initially. The same happens in /etc/rc.conf:

```
kld_list="i915kms"
{...}
kld_list="fusefs"
```
Now `kld_list` _only_ contains `fusefs`. If you need to load _both_ you need to use this:

```
kld_list="i915kms fusefs"
```


----------



## ziomario (Aug 9, 2021)

I missed these Vull's suggestions :









						kld_list="i915kms" does not stick on /etc/rc.conf at all.
					

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




					forums.freebsd.org
				




so,let's try.


----------



## ziomario (Aug 9, 2021)

this is my rc.conf


```
hostname="marietto"
keymap="it.kbd"
ifconfig_em0="DHCP"
local_unbound_enable="YES"
sshd_enable="YES"
powerd_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
dumpdev="NO"
dbus_enable="YES"
slim_enable="NO"
sound_load="YES"
snd_hda_load="YES"
kld_list="i915kms"
libvirt_enable="YES"
linux_enable="YES"
linux_mounts_enable="YES"
gateway_enable="YES"
```


----------



## free-and-bsd (Aug 9, 2021)

Seems like sound_load does not belong here. All the *_load entries go into /boot/loader.conf. Neither do you need it at all, system will load your sound subsystem automatically.


----------



## SirDice (Aug 9, 2021)

Remove these two:

```
sound_load="YES"
snd_hda_load="YES"
```
They don't belong in rc.conf. And you don't need to load them anyway, they're already included in the GENERIC kernel. Other than that, it looks fine. Reboot, login and check with `kldstat` if i915kms is loaded. If it's loaded there's nothing else you need to do. Loading it again using kldload(8) is useless, it'll just give you an error message the module is already loaded.


----------



## Geezer (Aug 9, 2021)

ziomario said:


> I have no idea about how to fix it. It's too much complicated for me.



Do what everyone else does and *read the handbook*. It is all in there, including adding your user to the video group.


----------



## ziomario (Aug 9, 2021)

---> Loading it again using kldload(8) is useless, it'll just give you an error message the module is already loaded.

that it wasn't true right now. After having logged in as root,I was able to kldload the driver and then to startX. Now I have uninstalled xorg and Im going to reboot. let's see.


----------



## ziomario (Aug 9, 2021)

Geezer said:


> Do what everyone else does and *read the handbook*. It is all in there, including adding your user to the video group.



sometimes,for complicated problems,it's not enough to "read the handbook" ; mostly true for the beginners. The learning process is faster,at least for me,reading from the various websites that have the advantages to don't make a list of parameters to try,but they offer ready to go commands,that I can try and compare to the same type of commands that I found somewhere else. My learning method is something like this. To give the full list of parameters to use,hoping to guess the right syntax,it's not the proper way to explain something. Anyway,I use the handbook when it is more explanatory.


----------



## mer (Aug 9, 2021)

ziomario I think what SirDice was saying is "If the module gets loaded correctly from the loader, you do not have to do kldload again.  If you do, the kldload command will return an error".  Since you were able to load it correctly after a boot, it means that the module did not load from loader/rc.conf.

kldstat is the command that lists the loaded modules (similar to Linux lsmod), so if everything is correct in loader.conf and rc.conf after a reboot you should see something like this:

`kldstat | grep i915
 9    1 0xffffffff82a3a000   158458 i915kms.ko`

If you do, and you have added your user to the video group, you should be able to log in as that user and run startx.
In your user home directory, do you have a file named ".xinitrc"?  That's a file that startx will call to start up your preferred window manager or desktop environment.

Now if after a reboot kldstat does NOT show the module there is more digging/debugging to do.

The handbook.  Just like anything else in life, reading the handbook or the manual or the instructions can help, but sometimes adds to the confusion because of assumptions made by the writers.  So it's not perfect but it always a good place to start.


----------



## ziomario (Aug 9, 2021)

Here I am. I've checked two things :

1) which graphic card is set as default from the BIOS : and it is the internal graphic card (intel card : i915kms driver)

2) I've checked if,after having removed xorg and reinstalled,the i915kms driver can be loaded from rc.conf. Unfortunately it doesn't. When I login with normal user,xorg don't start,telling that it can't run in framebuffer mode. If I do the login as root,I can load the driver and then I can start xorg succesfully. If I do the login as root,without kldload the driver,xorg does not start because the framebuffer error.

3) yes,I have added the user to the video group.

4) after the reboot,I see the i915 driver because I have loaded it as soon as I have logged in as root ! if I don't do this,Xorg does not start.


```
root@marietto:/ # kldstat | grep i915

27    1 0xffffffff82cc7000   158458 i915kms.ko
```

Maybe is useful to focus our attention where the problem really is,as suggested by Vull :


*His system is starting lightdm at line 395 in his dmesg.txt log / Pastebin link, but for some reason I don't see lightdm_enable="YES" in his /etc/rc.conf file?

Please notice that everything in dmesg.txt after line 400 happens after lightdm starts, and everything before line 401 does not.

Edited to add:

@ grahamperrin - My amd64 13.0-RELEASE-p3 system has /boot/modules/fusefs.ko but does not have fuse.ko anywhere. Very strange.

@ ziomario - You might benefit from  freebsd-update fetch && freebsd-update install


I've already added lightdm_enable="YES" on rc.conf but it didn't work. I've also did : freebsd-update fetch && freebsd-update install ; but I can try again.*


----------



## free-and-bsd (Aug 9, 2021)

Ok, I don't know what it is that prevents it from working the way it is supposed to work. Probably, this way you'll take a long time before you finally discover some (probably foolish) reason why.
Meantime you can do this to make your system workable. Create a script /etc/rc.conf.local  /usr/local/etc/rc.d/rc.localand place one command into it: `kldload i915kms`. Hope that makes it load automatically, after which you'll be able to launch your desktop.


----------



## mer (Aug 9, 2021)

Multiple graphics cards?  The internal i915 and something else like an nvidia/amd on PCI?
In the BIOS, can you actually disable the other one or can it be physically removed from the machine?
What's the output of:
`dmesg | grep -i vga

pciconf -lv`

Since you say multiple graphic cards I wonder if the wrong one is being attached and causing the module to not load during boot.


----------



## free-and-bsd (Aug 9, 2021)

mer said:


> Multiple graphics cards?  The internal i915 and something else like an nvidia/amd on PCI?
> In the BIOS, can you actually disable the other one or can it be physically removed from the machine?
> What's the output of:
> `dmesg | grep -i vga
> ...


Then how does it load ok manually after boot is complete?


----------



## ziomario (Aug 9, 2021)

mer said:


> Multiple graphics cards?  The internal i915 and something else like an nvidia/amd on PCI?
> In the BIOS, can you actually disable the other one or can it be physically removed from the machine?
> What's the output of:
> `dmesg | grep -i vga
> ...




```
root@marietto:/ # dmesg | grep -i vga

vgapci0: <VGA-compatible display> port 0x4000-0x407f mem 0x96000000-0x96ffffff,0x60000000-0x6fffffff,0x94000000-0x95ffffff irq 16 at device 0.0 on pci1
vgapci1: <VGA-compatible display> port 0x3000-0x307f mem 0x92000000-0x92ffffff,0x80000000-0x8fffffff,0x90000000-0x91ffffff irq 17 at device 0.0 on pci2
vgapci2: <VGA-compatible display> port 0x5000-0x503f mem 0x98000000-0x98ffffff,0x40000000-0x5fffffff irq 16 at device 2.0 on pci0
vgapci2: Boot video device
drmn2: <drmn> on vgapci2
vgapci2: child drmn2 requested pci_enable_io
vgapci2: child drmn2 requested pci_enable_io

root@marietto:/ # pciconf -lv

hostb0@pci0:0:0:0:    class=0x060000 rev=0x0d hdr=0x00 vendor=0x8086 device=0x3e30 subvendor=0x1458 subdevice=0x5000
    vendor     = 'Intel Corporation'
    device     = '8th/9th Gen Core 8-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S]'
    class      = bridge
    subclass   = HOST-PCI

pcib1@pci0:0:1:0:    class=0x060400 rev=0x0d hdr=0x01 vendor=0x8086 device=0x1901 subvendor=0x1458 subdevice=0x5000
    vendor     = 'Intel Corporation'
    device     = '6th-10th Gen Core Processor PCIe Controller (x16)'
    class      = bridge
    subclass   = PCI-PCI

pcib2@pci0:0:1:1:    class=0x060400 rev=0x0d hdr=0x01 vendor=0x8086 device=0x1905 subvendor=0x1458 subdevice=0x5000
    vendor     = 'Intel Corporation'
    device     = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x8)'
    class      = bridge
    subclass   = PCI-PCI

vgapci2@pci0:0:2:0:    class=0x030000 rev=0x02 hdr=0x00 vendor=0x8086 device=0x3e98 subvendor=0x1458 subdevice=0xd000
    vendor     = 'Intel Corporation'
    device     = 'CoffeeLake-S GT2 [UHD Graphics 630]'
    class      = display
    subclass   = VGA

none0@pci0:0:18:0:    class=0x118000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa379 subvendor=0x1458 subdevice=0x8888
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Thermal Controller'
    class      = dasp

xhci1@pci0:0:20:0:    class=0x0c0330 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa36d subvendor=0x1458 subdevice=0x5007
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH USB 3.1 xHCI Host Controller'
    class      = serial bus
    subclass   = USB

none1@pci0:0:20:2:    class=0x050000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa36f subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Shared SRAM'
    class      = memory
    subclass   = RAM

none2@pci0:0:22:0:    class=0x078000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa360 subvendor=0x1458 subdevice=0x1c3a
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH HECI Controller'
    class      = simple comms

ahci0@pci0:0:23:0:    class=0x010601 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa352 subvendor=0x1458 subdevice=0xb005
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH SATA AHCI Controller'
    class      = mass storage
    subclass   = SATA

pcib3@pci0:0:27:0:    class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086 device=0xa340 subvendor=0x1458 subdevice=0x5001
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI

pcib4@pci0:0:28:0:    class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086 device=0xa338 subvendor=0x1458 subdevice=0x5001
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib5@pci0:0:28:5:    class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086 device=0xa33d subvendor=0x1458 subdevice=0x5001
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib6@pci0:0:29:0:    class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086 device=0xa330 subvendor=0x1458 subdevice=0x5001
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI

isab0@pci0:0:31:0:    class=0x060100 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa305 subvendor=0x1458 subdevice=0x5001
    vendor     = 'Intel Corporation'
    device     = 'Z390 Chipset LPC/eSPI Controller'
    class      = bridge
    subclass   = PCI-ISA

hdac2@pci0:0:31:3:    class=0x040300 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa348 subvendor=0x1458 subdevice=0xa0c3
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH cAVS'
    class      = multimedia
    subclass   = HDA

ichsmb0@pci0:0:31:4:    class=0x0c0500 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa323 subvendor=0x1458 subdevice=0x5001
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH SMBus Controller'
    class      = serial bus
    subclass   = SMBus

none3@pci0:0:31:5:    class=0x0c8000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa324 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH SPI Controller'
    class      = serial bus

em0@pci0:0:31:6:    class=0x020000 rev=0x10 hdr=0x00 vendor=0x8086 device=0x15bc subvendor=0x1458 subdevice=0xe000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection (7) I219-V'
    class      = network
    subclass   = ethernet

vgapci0@pci0:1:0:0:    class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1e04 subvendor=0x19da subdevice=0x2503
    vendor     = 'NVIDIA Corporation'
    device     = 'TU102 [GeForce RTX 2080 Ti]'
    class      = display
    subclass   = VGA

hdac0@pci0:1:0:1:    class=0x040300 rev=0xa1 hdr=0x00 vendor=0x10de device=0x10f7 subvendor=0x19da subdevice=0x2503
    vendor     = 'NVIDIA Corporation'
    device     = 'TU102 High Definition Audio Controller'
    class      = multimedia
    subclass   = HDA

xhci0@pci0:1:0:2:    class=0x0c0330 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1ad6 subvendor=0x19da subdevice=0x2503
    vendor     = 'NVIDIA Corporation'
    device     = 'TU102 USB 3.1 Host Controller'
    class      = serial bus
    subclass   = USB

none4@pci0:1:0:3:    class=0x0c8000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1ad7 subvendor=0x19da subdevice=0x2503
    vendor     = 'NVIDIA Corporation'
    device     = 'TU102 USB Type-C UCSI Controller'
    class      = serial bus

vgapci1@pci0:2:0:0:    class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1c02 subvendor=0x19da subdevice=0x2438
    vendor     = 'NVIDIA Corporation'
    device     = 'GP106 [GeForce GTX 1060 3GB]'
    class      = display
    subclass   = VGA

hdac1@pci0:2:0:1:    class=0x040300 rev=0xa1 hdr=0x00 vendor=0x10de device=0x10f1 subvendor=0x19da subdevice=0x2438
    vendor     = 'NVIDIA Corporation'
    device     = 'GP106 High Definition Audio Controller'
    class      = multimedia
    subclass   = HDA

nvme0@pci0:3:0:0:    class=0x010802 rev=0x03 hdr=0x00 vendor=0xc0a9 device=0x5403 subvendor=0xc0a9 subdevice=0x2100
    vendor     = 'Micron/Crucial Technology'
    class      = mass storage
    subclass   = NVM

xhci2@pci0:5:0:0:    class=0x0c0330 rev=0x03 hdr=0x00 vendor=0x1912 device=0x0014 subvendor=0x1912 subdevice=0x0015
    vendor     = 'Renesas Technology Corp.'
    device     = 'uPD720201 USB 3.0 Host Controller'
    class      = serial bus
    subclass   = USB
```


----------



## mer (Aug 9, 2021)

free-and-bsd said:


> Then how does it load ok manually after boot is complete?


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.


----------



## free-and-bsd (Aug 9, 2021)

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.


It actually means that THE OTHER DEVICE IS NOT AVAILABLE to the system.


----------



## mer (Aug 9, 2021)

free-and-bsd said:


> It actually means that THE OTHER DEVICE IS NOT AVAILABLE to the system.


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.


----------



## mer (Aug 9, 2021)

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.


----------



## free-and-bsd (Aug 9, 2021)

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.


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.


----------



## free-and-bsd (Aug 9, 2021)

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


Do you have to do that? On my system, whenever 'discreet' video card is attached, the internal Intel will not even work.


----------



## mer (Aug 9, 2021)

free-and-bsd said:


> I'm wrong here, sorry. Though that pciconf output shows there are 3 , not 2 graphics cards.


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.


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.


----------



## mer (Aug 9, 2021)

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.


----------



## ziomario (Aug 9, 2021)

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



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.


----------



## mer (Aug 9, 2021)

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.


----------



## ziomario (Aug 9, 2021)

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.


----------



## Vull (Aug 9, 2021)

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


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.


----------



## mer (Aug 9, 2021)

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.


----------



## dieselriot (Aug 9, 2021)

ziomario said:


> I'm angry that as low level user I can do what I can't do as root. It is not acceptable.


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?


----------



## free-and-bsd (Aug 9, 2021)

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.


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  
And put an end to all your troubles as well!!!


----------



## ziomario (Aug 9, 2021)

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?



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.


----------



## dieselriot (Aug 9, 2021)

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.



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.


----------



## free-and-bsd (Aug 9, 2021)

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.


Easy to check what is installed with xf86-video-intel:

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


----------



## Vull (Aug 9, 2021)

free-and-bsd said:


> Easy to check what is installed with xf86-video-intel:
> 
> ```
> pkg info -l xf86-video-intel
> ...


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.
	
	



```
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:~ #
```


----------



## free-and-bsd (Aug 9, 2021)

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


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.


----------



## Vull (Aug 9, 2021)

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.


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.


----------



## ziomario (Aug 9, 2021)

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.


----------



## free-and-bsd (Aug 10, 2021)

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


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 (Aug 10, 2021)

are u telling that there is something mis configured in my system ?


----------



## free-and-bsd (Aug 10, 2021)

ziomario said:


> are u telling that there is something mis configured in my system ?


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?


----------



## ziomario (Aug 10, 2021)

I like to virtualize everything. I learnt esxi ; qemu + kvm on amd64 and on arm64 ; xen on amd64,now I want to learn bhyve on freebsd. Passing through the rtx 2080 ti I want to install Blender inside the linux VM and I want to configure it with the nvidia driver and the cuda libraries to render some footages with cycles. Maybe can I do this directly in FreeBSD ?


----------



## dieselriot (Aug 10, 2021)

I can confirm that Blender itself works great on FreeBSD on my radeon card. Not sure about those cuda libraries you mentioned.


----------



## ziomario (Aug 10, 2021)

Unfortunately at the moment nvidia does not support the cuda libraries on FreeBSD. So,it's not possible to use the power of my 2080 ti on FreeBSD with cycles. But I think that I can do it with linux and bhyve. The biggest problem is that I need to passthrough the whole PCI-e bus to Linux. It includes all my 3 graphics cards,right ? even the intel graphic chipset integrated to the mobo will be passed ? I will have no graphic card available for FreeBSD and no monitors. That's too bad. Any suggestion to give me ?


----------



## free-and-bsd (Aug 11, 2021)

ziomario said:


> Unfortunately at the moment nvidia does not support the cuda libraries on FreeBSD. So,it's not possible to use the power of my 2080 ti on FreeBSD with cycles. But I think that I can do it with linux and bhyve. The biggest problem is that I need to passthrough the whole PCI-e bus to Linux. It includes all my 3 graphics cards,right ? even the intel graphic chipset integrated to the mobo will be passed ? I will have no graphic card available for FreeBSD and no monitors. That's too bad. Any suggestion to give me ?


Yes, there are suggestions. Carefully READ and try to understand THE DOCUMENTATION before jumping to conclusions.
Did you read the PCI passthrough Wiki? 
Might also want to consult this thread. 
Every small detail matters... like the xf86-video-intel driver that you overlooked and created this long discussion


----------

