libGL error: failed to open drm device: Permission denied

[Gabriel Guzman]

Hello misc@,

I noticed the following error while running chrome from the shell this
evening: 

libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965

Which I think means that I'm not getting accelerated X.

A search of misc archives led me to this:
https://marc.info/?l=openbsd-misc=146159057503035=2 which in turn
led to: https://marc.info/?l=openbsd-misc=145125527304834=2 

Based on the information in those threads, I checked to see what TTY I
was logged in on: 

gabe@xps:~$ env
_=/usr/bin/env
LOGNAME=gabe
WINDOWPATH=ttyC4
WINDOWID=20971533
XTERM_SHELL=/bin/ksh
HOME=/home/gabe
LC_CTYPE=en_US.UTF-8
XTERM_VERSION=XTerm/OpenBSD(330)
DISPLAY=:0
SSH_AGENT_PID=92062
GOPATH=/home/gabe
PATH=/home/gabe/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games
SSH_AUTH_SOCK=/tmp/ssh-xfkLowrabhm9/agent.77539
PS1=\[\u@\]\[\h\]:\[\w\]\$ 
TERM=screen-256color
SHELL=/bin/ksh
USER=gabe
XTERM_LOCALE=en_US.UTF-8

Seemingly WINDOWPATH=ttyC4 (but I don't really know the right way to
check this) - so I added an entry to my /etc/fbtab: 

/dev/ttyC4  0600 
/dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0

duplicating what I saw for ttyC0.

I rebotted and confirmed that I was indeed now the owner of /dev/drm0:

gabe@xps:~$ ls -l /dev/drm*
crw---  1 gabe  wheel   87,   0 Aug 25 21:18 /dev/drm0
crw---  1 root  wheel   87,   1 Aug 25 21:18 /dev/drm1
crw---  1 root  wheel   87,   2 Aug 25 21:18 /dev/drm2
crw---  1 root  wheel   87,   3 Aug 25 21:18 /dev/drm3

Then I ran glxgears, and got the permission denied message again: 

gabe@xps:~$ glxgears  
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965

And, sure enough when I rechecked /dev/drm: 

gabe@xps:~$ ls -l /dev/drm* 
crw---  1 root  wheel   87,   0 Aug 25 21:18 /dev/drm0
crw---  1 root  wheel   87,   1 Aug 25 21:18 /dev/drm1
crw---  1 root  wheel   87,   2 Aug 25 21:18 /dev/drm2
crw---  1 root  wheel   87,   3 Aug 25 21:18 /dev/drm3

I'm no longer the owner.  I'm not sure when this started, but
I don't have this issue on my 6.1 box, just on the one running current. 

Sometimes, forcing the permissions on /dev/drm0 does work:

gabe@xps:~$ doas chown gabe /dev/drm0 
doas (g...@xps.my.domain) password: 
gabe@xps:~$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.

But then, as soon as I exit glxgears, /dev/drm0 goes right back to being
owned by root, and the error message comes back.  

Xorg log, and dmesg below... there are some drm0 errors in the dmesg
that maybe are related?  If anyone has any ideas, I'm open to trying
them out.  If not, I'l probably do a clean install on this machine as it
has been awhile since the last one.  

Also, not sure if it's relevant, but I'm a member of the `staff` login
class on this machine

Thanks,
gabe. 

gabe@xps:~$ cat /var/log/Xorg.0.log
[20.707] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
(Operation not permitted)
Check that you have set 'machdep.allowaperture=1'
in /etc/sysctl.conf and reboot your machine
refer to xf86(4) for details
[20.707]linear framebuffer access unavailable
[20.716] (--) Using wscons driver on /dev/ttyC4
[20.730] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[20.730] X Protocol Version 11, Revision 0
[20.730] Build Operating System: OpenBSD 6.2 amd64 
[20.730] Current Operating System: OpenBSD xps.my.domain 6.2 GENERIC.MP#40 
amd64
[20.730] Build Date: 25 August 2017  11:23:34AM
[20.730]  
[20.730] Current version of pixman: 0.34.0
[20.730]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[20.730] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[20.731] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug 25 22:22:37 
2017
[20.732] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[20.733] (==) No Layout section.  Using the first Screen section.
[20.733] (==) No screen section available. Using defaults.
[20.733] (**) |-->Screen "Default Screen Section" (0)
[20.733] (**) |   |-->Monitor ""
[20.734] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[20.734] (==) Disabling SIGIO handlers for input devices
[20.734] (==) Automatically adding devices
[20.734] (==) Automatically enabling devices
[20.734] (==) Not automatically adding GPU devices
[20.734] (==) Max clients allowed: 256, resource mask: 0x1f
[20.740] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,

Re: Dumb question about updating snapshots

[Bryan Linton]

On 2017-08-25 13:09:14, Jordon  wrote:
> I’ve been running snapshots on my machine for a while now.  About once or 
> twice a week I will interrupt the boot with ‘bsd.rd’ and run through the ‘U’ 
> process to get the latest builds.  The only weirdness is that it alway 
> defaults to a really slow mirror (i have to manually enter a different one) 
> and it simply doesnt work when I enter a number from the list.  Is this a 
> proper way to update?
> 
> What about when the version gets bumped?  Since the switch to 6.2, this 
> method doesn’t work because it doesnt give the list of packages - just the 
> kernel ones.  Is this expected behavior and the solution is to boot from a 
> flash drive or PXE from the latest 6.2 media?
> 

The older bsd.rd is probably only looking for files tagged with
its own version.  I.e. If you have 6.1 installed, it's looking
for base61.tgz and not base60.tgz or base62.tgz.

There are probably quite a few different ways to update to new
snapshots.  What I've been doing for a long time now is the
following:

1) Fetch latest snapshot from a local mirror, and save to HDD
2) Verify with signify
3) Copy /bsd and /bsd.rd to /bsd.old and /bsd.rd.old respectively
4) Copy the snapshot's bsd.rd to /
5) Reboot, select bsd.rd, and select 'U' for upgrade
6) When given the option to select where filesets are
   located, answer that the partition is already mounted
   (since in my case, I put them on /var, so it already is
   mounted) and manually type in the full pathname to the
   sets.

I wrote a basic shell script that does 1) and 2) all at once, so I
can just run "fetch-snap.sh" and it automatically backs up the
previous snapshot, fetches the new one, and verifies everything.

The process I use above does not seem significantly different to
what you're already doing, at least when compared to the
alternative of using a USB stick, so I'd recommend you consider trying
it.

If you have another machine on your local network, you could run a
minimal httpd instance and make said directory available to them.
I do this too, so I upgrade my main machine with the above steps,
but point all other machines on my local net to the local IP
address of the main machine when asked to choose a mirror and
proceed as normal.

I've not had any problems with this procedure in the many years
I've been using it, but YMMV.

-- 
Bryan

RE: Query regarding exec in mandocdb.c

[leo_tck]

[now I'm subscribed, might as well respond to some recent stuff from the
 archives...] 

321.geo...@gmail.com wrote:
> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
> process. It seems that if the logic from these programs were duplicated
> the pledge in mandocdb.c could be further restricted and even not bother
> with forking.
>
> Would such a change be pointless churn however? Both cmp(1) and rm(1)
> are simple programs and are pledge'd themselves. Not to mention the
> creation of the mandoc database is in itself a short lived process.
>
> To be clear I'm not proposing a change (indeed I have no diff) but
> rather I am simply curious to the opinion of others in the OpenBSD
> community.

Okay, in that case, please forgive me if I go off on a little bit of a
tangent.

I've used UNIX for quite a while now. Not being satisfied with just
using anything, I've (not deeply) poked at the luserspace internals
quite a bit over time.

Almost each time I read the source code of any UNIX program, whether it
came w/ the system or not, I find duplicated functionality.

As I see it, this is not just inefficient, but also a huge security
issue: if the same operation is stated differently in many different
places, how can we make sure that we squash all instances of a
particular bad habit or bug?

The only real solution that I've come up w/ over time is to put the
actual logic in libraries and leave the programs to be luser interfaces
to that logic.

Perhaps something not quite so extreme is needed. I wouldn't know.

It would certainly make it easier to execute the suggestion you make in
the first paragraph of your message.

--schaafuit.

[so, the spacing issue does not appear today, but the subject lines
 are fscked. g!]

wdc_pcmcia and ATA mode

[leo_tck]

Hi,

I'm to install OpenBSD on an old Thinkpad, but I first need to dump
the curr hdd contents, using the install cd, to a large CF card, via
a PCMCIA adapter.

The pcmcia stuff is correctly detected by the kernel, but wdc_pcmcia
only appears to access the device in pcmcia mode (1-sector PIO),
killing performance. I'm sure the CF card supports ATA mode and DMA
as it's been used in the past as an ATA device through (guess what)
an appropriate adapter.

Inspection of the source code appears to reveal that there's a rather
strict separation between wdc_pcmcia and (the presumably needed)
wdc_isa. Is this true?

Can I somehow safely force wdc_isa to attach instead of wdc_pcmcia, or
otherwise have OpenBSD have operate the card in ATA mode?

dmesg output has to be routed through the 10-finger interface and will
thus be provided only on request :)

Please understand that the situation is complicated by not having a
running OpenBSD install around (the whole point is to fix that!).

Nevertheless, I'm of course willing to try 'patches' in the form of
i386 CD boot images. If truly needed I can of course dump the hdd
contents through a certain terminal emulator developed in Helsinki,
but I'm sure you understand that I'd rather avoid that...

Thanks in advance for any insight or effort,

--schaafuit.

P.S.: Since I'm not currently subscribed to this mailing list, courtesy
  copies are very much appreciated. Also apologies for any broken
  spacing, this is currently beyond my control and will be fixed in
  the future.

wdc_pcmcia and ATA mode

[leo_tck]

[I sent this earlier w/o being subscribed, but I gather that the (imo
 fascist) anti-spam measures have eaten it, so here again it goes...]

Hi,

I'm to install OpenBSD on an old Thinkpad, but I first need to dump
the curr hdd contents, using the install cd, to a large CF card, via
a PCMCIA adapter.

The pcmcia stuff is correctly detected by the kernel, but wdc_pcmcia
only appears to access the device in pcmcia mode (1-sector PIO),
killing performance. I'm sure the CF card supports ATA mode and DMA
as it's been used in the past as an ATA device through (guess what)
an appropriate adapter.

Inspection of the source code appears to reveal that there's a rather
strict separation between wdc_pcmcia and (the presumably needed)
wdc_isa. Is this true?

Can I somehow safely force wdc_isa to attach instead of wdc_pcmcia, or
otherwise have OpenBSD operate the card in ATA mode?

dmesg output has to be routed through the 10-finger interface and will
thus be provided only on request :)

Please understand that the situation is complicated by not having a
running OpenBSD install around (the whole point is to fix that!).

Nevertheless, I'm of course willing to try 'patches' in the form of
i386 CD boot images. If truly needed I can of course dump the hdd
contents through a certain terminal emulator developed in Helsinki,
but I'm sure you understand that I'd rather avoid that...

Thanks in advance for any insight or effort,

--schaafuit.

P.S.: Apologies for any broken spacing, this is currently beyond my
  control and will be fixed in the future.

MediaTek Mt7601

[Heppler, J. Scott]

I just purchased a nano-usb wifi dongle with the expectation that it
would have a rtl8188cu chipset.  In fact it has a MediaTek MT7601U and
on perusing alot of purchase comments it seems that the MT7601U is
supplanting the RealTek chipset.

Ralink was fairly open and provided partial documentation for the
FreeBSD drivers that were imported into OpenBSD.  I'm not sure if
corporate policy changed when MediaTek bought RaLink but the MT7601
driver is in the Linux Kernel => 4.2, the source is GPLV2 and
redistribution of the closed source firmware is allowed.

https://wikidevi.com/wiki/Mt7601u

The MediaTek dongle came on a slow boat from China so I'm not sending it
back.  The wikidevi entry suggests that this may be low-hanging fruit to
add to OpenBSD/FreeBSD/NetBSD.  The question I have is whether to give
the MediaTek away and try to purchase on older RealTek or be patient and
wait a few months?  I'm presently using an older, larger rum(4) usb
device.

Thanks
--
J. Scott Heppler

Dumb question about updating snapshots

[Jordon]

I’ve been running snapshots on my machine for a while now.  About once or twice 
a week I will interrupt the boot with ‘bsd.rd’ and run through the ‘U’ process 
to get the latest builds.  The only weirdness is that it alway defaults to a 
really slow mirror (i have to manually enter a different one) and it simply 
doesnt work when I enter a number from the list.  Is this a proper way to 
update?

What about when the version gets bumped?  Since the switch to 6.2, this method 
doesn’t work because it doesnt give the list of packages - just the kernel 
ones.  Is this expected behavior and the solution is to boot from a flash drive 
or PXE from the latest 6.2 media?

Thanks.
Jordon

Re: reiser4fs in openbsd

[Luiz Gustavo dos S. Costa]

2017-08-25 17:19 GMT+01:00 Daniil Berendeev :
> On 08/25/17 15:47, Florian Obser wrote:
>>
>> zfs is already there:
>> https://marc.info/?l=openbsd-cvs=136482823110105=2
>
> I know about that commit, but there is still no userland utils
> for using ZFS, so we can't consider it being fully ported.
>

Nobody observed the commit date 

2013/04/01 08:56:42

I think it's a world day, right? or i am wrong?

-- 
Luiz Gustavo Costa  |  gugabsd

Re: reiser4fs in openbsd

[Peter N. M. Hansteen]

On 08/25/17 17:53, Victor Kukshiev wrote:
> 2017-08-25 18:47 GMT+03:00 Florian Obser :
> 
>> reply-to: misc
>>
>> could you all please fix your email client to not strip diffs when
>> posting to tech@? thanks
>>
>> ОК
> 
>> zfs is already there: https://marc.info/?l=openbsd-
>> cvs=136482823110105=
>> 
> 
> Why not implement it?

There is reason to believe that a port of the hitherto linux-only CPIP
(http://www.blug.linux.no/rfc1149/ and links therein) will appear sooner.

- P

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: reiser4fs in openbsd

[Luis Coronado]

Facepalm

On Fri, Aug 25, 2017 at 10:23 AM Daniil Berendeev 
wrote:

> On 08/25/17 15:47, Florian Obser wrote:
> > zfs is already there:
> https://marc.info/?l=openbsd-cvs=136482823110105=2
> I know about that commit, but there is still no userland utils
> for using ZFS, so we can't consider it being fully ported.
> --
> ~Cheers~
> pipfstarrd.net
> pipfsta...@jabbim.com
>
> PGP KEY ID ACE8 41D8 A1B6 54C0
> Keys can be retrieved at pgp.mit.edu
>
>

fun stuff to try on 6.2-beta

[sven falempin]

I have a fun behavior but it s on the deprecated 6.0 , sorry i m slow af.

Given the start procedure you can kill smtpd early by renewing the lease,
looks like the bug in ospf

So to the tester do:

rcctl smtpd stop
(smtpd -d &) ; sleep 0.1 && dhclient re0

replace re0 with your favorite fxp or em or whatever

the sleep must trigger the dhcp during the setup phase,
change the 0.1 according toyour speed.

setup_done(p_ca);
setup_done(p_control);
setup_done(p_lka);
setup_done(p_pony);
setup_done(p_queue);
setup_done(p_scheduler);

log_debug("smtpd: setup done");

i do not know if this can be consider as a bug . .. but it could be annoying.
I guess it is a bug if it happens during renew and you for some reason
reboot smtpd
sometimes

best,

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: reiser4fs in openbsd

[Daniil Berendeev]

On 08/25/17 15:47, Florian Obser wrote:

zfs is already there: https://marc.info/?l=openbsd-cvs=136482823110105=2

I know about that commit, but there is still no userland utils
for using ZFS, so we can't consider it being fully ported.
--
~Cheers~
pipfstarrd.net
pipfsta...@jabbim.com

PGP KEY ID ACE8 41D8 A1B6 54C0
Keys can be retrieved at pgp.mit.edu

Re: reiser4fs in openbsd

[Daniil Berendeev]

Reiser4 isn't dead FS, but with advanced features,

Mainline Linux kernel still doesn't have it, Hans Reiser is in jail,
and just a few people use reiserfs in production. I don't see any real
demand for it. It doesn't mean that reiserfs is bad, though.

i686 & amd64 are popular not because they are the best architectures out
there.


--
~Cheers~
pipfstarrd.net
pipfsta...@jabbim.com

PGP KEY ID ACE8 41D8 A1B6 54C0
Keys can be retrieved at pgp.mit.edu

Re: reiser4fs in openbsd

[Victor Kukshiev]

2017-08-25 18:47 GMT+03:00 Florian Obser :

> reply-to: misc
>
> could you all please fix your email client to not strip diffs when
> posting to tech@? thanks
>
> ОК

> zfs is already there: https://marc.info/?l=openbsd-
> cvs=136482823110105=
> 

Why not implement it?

Re: reiser4fs in openbsd

[Florian Obser]

reply-to: misc

could you all please fix your email client to not strip diffs when
posting to tech@? thanks

zfs is already there: https://marc.info/?l=openbsd-cvs=136482823110105=2

On Fri, Aug 25, 2017 at 05:39:11PM +0200, Philipp Buehler wrote:
> Am 25.08.2017 17:35 schrieb Daniil Berendeev:
> >>ok. is reiser4 need on openbsd?
> >Well, a dead fs is not much of an interest. If you would be porting
> >HAMMER or ZFS (the last one has a painful license though) there
> >probably would be much more interest.
> 
> HAMMER2 - yes, please.
> 
> (what happened to the netbsd "journalled" one?)
> -- 
> pb
> 

-- 
I'm not entirely sure you are real.

Re: maybe misc can help even it's not openbsd related

[Markus Rosjat]

thanks all for the suggetions I will take a look at it and come back 
with some kind of config output thought.


sorry for less usefull input but I'm trying to put pieces together in a 
way I can work with and this work is in progress and in a very early stage.


And once again this list is at least willing to responde to a dummy like 
me so thumbs up guys !!!


regards

markus

Am 24.08.2017 um 21:43 schrieb Mike Coddington:

On Thu, Aug 24, 2017 at 11:49:19AM +0200, Markus Rosjat wrote:

so here is my problem, I konfigured postfix and dkimproxy to work together.
So far so good because it works for outgoing mail. The problem i face is
with local mails. Postfix somehow rewrites the reciepent from the mail
adress to u...@domain.tld and then the lookup im my ldap directory fails.

So the real question is, can I configure postfix to ignore the forwarding to
dkimproxy for local delivery ?


Without seeing your configuration files, it's hard to tell. However, my
guess is that you've got dkimproxy set to process all of your mail
rather than having it only attached to the smtpd part of it. Check your
master.cf and make sure that you're only referring to dkimproxy there,
as opposed to calling it in main.cf somewhere.

For example, I have SpamAssassin in my pipeline but only for external
mail. I set it up that way by doing this with master.cf (among other
things):

smtpd pass  -   -   y   -   -   smtpd
 -o smtpd_client_restrictions=$client_restrictions
 -o content_filter=spamassassin

By including the content_filter there, I'm able to have it only affect
mail that originates from external hosts. I assume dkimproxy is called
in a similar fashion. DKIM's too much of a pain in the butt for me
though so I don't have first-hand experience with it.



--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT