A Possible workaround to the SEGFAULT issue..

[onemyndseye]

This thread refers to the issues discussed here:
http://regnumonlinegame.com/forum/showthread.php?t=36774

******* THIS METHOD IS NOW OBSOLETE ************

it occurred to me that we should be able to get around this using a chroot environment and I have begun some loose scripting to build a hardy chroot, configure it, install RO and get it to run from your current desktop.

This means your PC would NOT be locked into using Hardy (2 versions old now) you would just simply need a very basic install of hardy.. just afew hundred megs.. debootstraped into a local directory or partition and properly setup... then a wrapper script to run RO bottled in this environment. This is the same way 64bit users once solved the problem of needing to run 32bit apps... and Sounds "simple" enough but I have hit some snags that I am hoping you guys here can help with....

On my test platform (Ubuntu Intrepid) I tried this with a Hardy chroot and was excited to see RO run..RO was started like this:

sudo chroot ./test-root/ /opt/regnum/rolauncher


However once the intro movie started the RO window flicked and distorted. and the terminal spamed msgs like:

libGL: Display claims not to support XXXX visual


Bah! back to the drawing board...

So I decided I would start a seperate X session inside the chroot on :1. Desktop starts as normal but RO gives the old "Your video card is too old" crap. Upon further investigation I found that ' glxinfo |grep direct ' says I have no direct rendering... and this is where Im stuck.

I followed these instructions on setting up the environment which suggests that DRI should "just work"
https://wiki.ubuntu.com/DebootstrapChroot


also as a side note.. I followed the examples above to create a hardy chroot inside hardy.. installed xorg, mesa, openal, gtk and RO and running RO worked perfectly as I tried 1st above (sudo chroot ./test-root/ /opt/regnum/rolauncher). Im guessing the graphics issues I experienced on the Intrepid <==> Hardy chroot is due to incompatibilities between the mesa libs being used and the running X server. ... Also, starting a X session under this chroot also showed that DRI was NOT available. So this is where I will start trying to solve as I feel at this point running it in chroot with the Hardy libs on a Intrepid X server will be a lost cause.



Froste? imefisto? Xephandor? anyone? Can this be solved? if so I can provide a nice little wrapper to work around this issue..

thanks,
-onemyndseye

*** EDIT: Issues to overcome
-------------------------------------------------
[SOLVED] 1. More secure xhost incantation
[SOLVED] 2. Solid way to move away from running as root
3. ??

[Bamm-Bamm]

It might be due to incompatibilities between the DRI version used in the kernel and the x-driver used in your chroot.

Could you post the output of
grep "EE" /var/log/Xorg.0.log

[onemyndseye]

Just thought of of posting that myself :) .. however as stated above DRI does not enable on a Hardy chroot inside a Hardy install.. all versions all the same -- this was my "control" for testing and I will not move further until DRI will function on this control... once this works it should work on the Inptrepid ==> Hardy chroot unless as you stated we run into module problems


I believe the related portion is:

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) [drm] DRM interface version 1.0
(EE) [drm] Could not set DRM device bus ID.
(EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.

[ArcticWolf]

Wow, this is a great idea! Using chroot to run Regnum on new Ubuntu releases, without having to keep your old release just to play. Nice workaround. :P

Could you please post the kernel version numbers for both Hardy and Intrepid? I don't know if chroot may have problems if you're loading modules from older kernel releases, as qwasd said.*

Maybe this can help: http://www.phoronix.com/forums/showpost.php?p=71718&postcount=4


*In fact, I only use chroot to build packages, and it's been a long time since the last time. =/

[onemyndseye]

Thanks ArticWolf :)

Pretty big difference in versions:

Hardy: 2.6.24-24
Intrepid: 2.6.27-7
Jaunty: 2.6.28-11 (The finial target)


However, again we need a proof of concept.. this means a Hardy <==> Hardy chroot should have Direct Rendering.. and at this point it does not. This control setup is identical to its host


**** EDIT:

Xeph, according to the link you provided Direct Rendering on a secondary desktop is not implemented in DRI :( bummer :( --- Hopes of running RO in a seperate chrooted X session are dashed, atleast for now

That being the case I suppose it wouldnt hurt to take a solid pass at running it chrooted without the 2nd X session but it doesnt look good.

I'll post back with some debug info

[imefisto_foro]

Thanks Xep :)

Pretty big difference in versions:

Hardy: 2.6.24-24
Intrepid: 2.6.27-7
Jaunty: 2.6.28-11 (The finial target)



Hi. I don't have experience with chroot environment, so I may be wrong.


If you build Xorg in a chroot environment, make sure the kernel version of the base system and the target system are the same. This is especially important if you enabled DRI support as a module as instructed above.
LINK (http://www.linuxfromscratch.org/blfs/view/5.1/x/installing.html). X-Org's Version in that document is old, but maybe it can help.

Considering your info about your kernel's version, maybe that's the problem.

[onemyndseye]

********* UPDATE ***************

YESS!!!!!

While I had trouble hosting RO on intrepid running from a hardy chroot... Hosting on Jaunty seems to work splendidly!!!

i have to make sure I can duplicate it several different ways but at this time I believe I will have a wrapper posted within about 24 hours to build your chroot and setup RO to be run under it... Though I cant promise a working script for non-ubuntu releases. However I will detail the process enough here that one should be about to handle it... worst case scenario for a non ubuntu user having this problem will probably be to setup a small partition for a minimal ubuntu hardy. My method will include using debootstrap to get the needed files so if someone can chime in with info of using debootstrap on a non-debian/ubuntu system that would be helpful.

So far this looks like GREAT news!!!!!

[onemyndseye]

This is confirmed and reproducible on Ubuntu Jaunty running from a Hardy chroot!!

expect an update with a script to make it happen inside 24hours

[Bamm-Bamm]

Cool! good job, man.
Let me know if you need any help with the scripting

[onemyndseye]

Thanks :)


Its finished and posted here:
http://regnumonlinegame.com/forum/showthread.php?t=41850


Please direct questions and comments related to the methodology here and HOWTO related info in the thread linked above.


Check out the script and let me know of any changes that needs to be made.. Im not really fond of the xhost + statement but the acess is required to get RO on your current desktop -- if any of you have a better solution please speak up

Take care guys,

[onemyndseye]

all good, but running regnum as root user?

anyway i'll try it on my arch boot (obviously some modifications will be needed) when i get the time.


This is a valid concern.. however not as bad as it seems at face value IMHO.. since we are running in a fake root... If it was compromised only certain parts of the host system could be read... i.e. the parts mounted like /tmp /dev etc etc... but still something that needs to be worked around...

The biggest problem is that you cannot detect what user is running the installer under sudo.. so permissions cannot be setup properly. At first glance I thought that setting ownership to root:users or something similar would solve but this proves to be problomatic during RO updates

So using schroot to enter the chroot as a unpriv user will atleast eventually fail to update some resources or cause quirky behavior like Screenshots cause RO to freeze since it doesnt have permissions to write the image




I've edited the orignal post in this thread to include a running list of issues to work out... feel free to speak up here

[Nightchill]

tried with archbootstrap, rest steps are mostly same as yours, it works but i'm not going to run it as root (even as a fake one). i don't want anything accessing my / if not sys related.

edit: for those truly willing to experiment, maybe regnum works better with directfb (http://www.directfb.org/) then with xorg

[onemyndseye]

...... it works but i'm not going to run it as root (even as a fake one). ....
But its not only a fake root account... but a fake install... completely seperate from your own -- It may as well be a VirtualBox machine. its not accessing your / at all. It does bind your home directory but this can be avoided if it needs to be...

However I do agree that this isnt ideal and I am still working on this issue as I type this... no luck with the schroot method .. I have my doubts about this method working -- or either I have no idea how to configure it properly. (very possible)

I tried adding a user to the chroot (regnum) and calling rolauncher like this:

export DISPLAY=:0
su regnum -c ./rolauncher
Error: Unable to initialize gtk, is DISPLAY set properly?


:( this method would eliminate the issue of RO running as a priv user -- the chroot call is performed by root (as it must be).. then the RO process is exec'ed by "regnum"

After a second thought I tried adding the user to the host system as well.... still no joy ---- anyone have input on this??? I cant seem to find any method to get a unpriv to contact the running X

[Nightchill]

it'd be nice actually if any devs replied to any of these segfaults threads and offer an answer..

[onemyndseye]

This is why this is been going on for anout 5 months now :/ After constant pleas and Bug reports with absolutely ZERO comment from NGD... for people like me that needs a newer distro to support their mobile hardware properly this is the 1st promise of a workaround.. ever how painfull it may be..

Oh trust me .. I VERY much wish they would reply -- it would probably have saved be COUNTLESS hours of effort at this point

[Nightchill]

well, i doubt ngd would pack up broken release so it must work for them with their hardware (which is obviously better then shit we have since we're forced to use open source drivers). so only possible explanation for no one of the devs not replying here would be that they can't reproduce this error.

edit: btw got msn or something, think we could cooperate easily over some im... or come to irc (#regnum-online on quakenet.org)

[onemyndseye]

I've got an effected video card that I would gladly donate -- if theyd show interest

MSN info is: onemyndseye -at- yahoo.com

[Nightchill]

nice, i'll add you as soon i find a decent im for linux (just noticed i don't have any im on my linux boot)

edit, added you: {optik[at]live[dot]com};

[onemyndseye]

Ok... this issue is solved with alittle extra chroot setup and modifiying the loader script.. and in doing so solved the xhost issue as well


expect an update later today

[Nightchill]

today i downloaded new regnum binary package from ngd's website, installed and noticed there's a folder called test_linux. inside that folder is app called "game" and upon starting it it just quits in the same moment, no error or nothing. what might this be? some sort of official "patch" from ngd or?

[onemyndseye]

You mean inside the install directory? the ~/regnum/test is for the Amun server. and you cannot run game binary directly as it just exits (returns 1) without being called by the launcher. but at any rate this is the RO binary that rolauncher calls after it checks for patches and you Login and click "Enter game world"


Updated the HOWTO and script to solve the security issues revolving xhost and running RO as root

[Nightchill]

You mean inside the install directory? the ~/regnum/test is for the Amun server. and you cannot run game binary directly as it just exits (returns 1) without being called by the launcher. but at any rate this is the RO binary that rolauncher calls after it checks for patches and you Login and click "Enter game world"


Updated the HOWTO and script to solve the security issues revolving xhost and running RO as root

it's /regnum/test_linux and it's first time i see it. and on my windows boot RO doesn't even have test dir since i never logged to amun after reinstalling ro

[onemyndseye]

I dunno... dont have that it my install.

You could try backing up /live/game and replacing it with that one to see what happens

[Nightchill]

i did. does nothing, segfault as usual.