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

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 :

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


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


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


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

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

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

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

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


So,If I login using a low level user,xorg will not start. And I can't use FreeBSD at all without it.
 
That has nothing to do with the kernel module but with your Xorg configuration.
 
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.
 
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.
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.
 
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.
 
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.
 
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.
 
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.

Code:
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:
Code:
kld_list="i915kms"
{...}
kld_list="fusefs"
Now kld_list only contains fusefs. If you need to load both you need to use this:
Code:
kld_list="i915kms fusefs"
 
I missed these Vull's suggestions :


so,let's try.
 
this is my rc.conf

Code:
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"
 
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.
 
Remove these two:
Code:
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.
 
---> 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.
 
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.
 
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.
 
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.

Code:
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.
 
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.
 
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.
 
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.
Then how does it load ok manually after boot is complete?
 
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.

Code:
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
 
Back
Top