OpenSim + Raspian hard-float = What was once broken now works!
A while ago I decided to go into a journey of OpenSim because I liked working offline from SecondLife and I like keeping a backup of my stuff. It’s good to have backups in the event Linden Labs completely fails you. Anyhow! In my past blog about the Raspberry Pi I talked about how I must have fried my Pi from running quake 3 on it overclocked like crazy, and it still maybe the case! but for now I’m not going to use my Pi for accessing it’s GLES capabilities but instead use it to act as a server for OpenSim. Because I do not know the learning curve of the average Pi or OpenSim User; I should note that this guide is going to a bit long and has bits from installing OpenSim as well as compiling all of the sources needed to get OpenSim functioning properly.
When you look at the server specs for OpenSim and what they suggest would be a good server for OpenSim. You would be quick to notice that your average spec for a island sim is about 2Ghz of CPU power and 1GB of ram. I later found out that the programming language Mono which OpenSim is based around really likes multi-core processors. So suddenly a raspberry Pi 2 becomes a very workable unit. To those which are still rocking the single-core Raspberry Pi A or B+ you’ll find that running OpenSim works but will be very slow as physics/scripting/assets are all being bounced off of just that one armv6 700Mhz processor.
When I first tried OpenSim a long time ago. I ran into roadblock after roadblock. Eventually finding out that you cannot install MONO onto a raspberry Pi which is running hard-float from the Debian libraries. You either had to run Wheezy or Pidora in soft-float mode. Which in soft-float everything feels like your running on a 300Mhz Pentium II desktop! It’s painfully slow.
But First! Lets do the basics and update your Pi!
sudo apt-get update
sudo apt-get upgrade sudo ldconfig sudo apt-get install libgdiplus
Use MySQL instead of OpenSim SQL-Lite!
After a bit of usage on my Pi I noticed I was getting a lot of file not found errors flying on my console just by simply camera panning in and out on my phoenix/firestorm viewer. It seemed like the hyper experimental Mono compile is simply having issues looking up null table references. It didn’t effect moving around the sim. Once again this was an annoyance. So understanding that the build of Mono I have is experimental. The goal is to take as much as you can out of the hands of the Mono development language so that OpenSim runs smooth and stable.
It’s going to queue you for the root password for MySQL. This is really important to write this down! We will need it later in the chapter!
We’re going to create the initial opensim database for it to use and generate a userid “opensimuser” within MySQL with the password “opensimpassword”. I prey you use something slightly more original then these user/pass.
$ mysql -u root -p Enter password: mysql> create database opensim; Query OK, 1 row affected (0.00 sec) mysql> use opensim; Database changed mysql> create user 'opensimuser'@'localhost' identified by 'opensimpassword'; Query OK, 0 rows affected (0.01 sec) mysql> grant all on opensim.* to 'opensimuser'@'localhost'; Query OK, 0 rows affected (0.01 sec) mysql> quit
Mono Language installation onto your Pi.
apt-get install mono-complete mono --version
Your Mono will report with the following information:
Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4+rpi1) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notifications: epoll Architecture: armel,vfp+hard Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: sgen
This is a start to get you up to at least version 3.2.x. However, this is no longer an effective means of getting OpenSim or OSGrid stable. Mono version 3.2.x works fine in stand-alone mode but when you run it in hypergrid or region mode with other servers you’ll quickly find out that people can teleport into your region but can’t teleport out.
Doing a bit of reading about how mono v3.2.8 came to be on Debian Wheezy and the Raspberry Pi community the person porting it states that it was “Mostly” working. OpenSim/OSGrid is really not the kind of program you want to say “Mostly” with because weird things occur such as my teleportation on OSGrid error blog.
Upgrading from Mono 3.x to mono 4.x
The good folks at Mono-Project have not only compiled a version of 4.0 for debian wheezy but made a sub-compilation for Armv7 processors. This is fantastic news for people like me which have a Banana Pi or people that have Raspberry Pi 2’s. To get the latest version following their Linux installation instructions you pass the following commands onto your Pi.
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list sudo apt-get update sudo apt-get upgrade
If you are getting the following errors stating that Mono 4.0 packages are being “held back” then WITH EXTREME CAUTION pass the following command.
sudo apt-get dist-upgrade
And this will begin the process of replacing the mono-complete package provided you even installed that.
To confirm you have version 4.x or better, type in the following.
and it should respond with something like this.
Mono JIT compiler version 4.0.4 (Stable 184.108.40.206/5ab4c0d Tue Aug 25 23:45:14 UTC 2015) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notifications: epoll Architecture: armel,vfp+hard Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: sgen
Congratulations! The mono language is now up to date and setup properly.
Since mono development is rather fluid in its upgrades there will be times where downgrading to a more stable version of mono is preferred for OpenSim. At the time of this update Mono version 220.127.116.11 is released and although it takes less memory to run OpenSIM it increases its idle processor to %50 and crashes every few hours. This is not cool.
To start we are going to blow up any previous versions of Mono that exist on our pi.
sudo apt-get remove mono-complete
sudo apt-get purge mono-complete sudo apt-get autoremove
Next, we will take a earlier snapshot from the repo tree index. We prefer version 18.104.22.168 as it was about the version that was released at the time of this blog but you may try others.
sudo echo "deb http://download.mono-project.com/repo/debian wheezy/snapshots/22.214.171.124/. main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
Finally, install mono onto this unit.
sudo apt-get update
sudo apt-get mono-devel mono-complete
Note: If you are receiving an error as follows:
W: Conflicting distribution: http://download.mono-project.com wheezy/snapshots/4.2.3 Release (expected wheezy/snapshots but got wheezy)
You can try the following:
sudo echo "deb http://download.mono-project.com/repo/debian wheezy/snapshots/126.96.36.199 main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo echo "deb http://download.mono-project.com/repo/debian wheezy/snapshots 188.8.131.52/main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
It really depends on your flavor of linux that is running on your Pi.
Legacy Mono 2.x instruction for Rpi-b’s
Continuing on we do the basics such as setup the OpenSim.ini to operate in standalone mode by default. And then we have to modify the StandAlone.ini file to switch database control over to MySQL
wget http://opensimulator.org/dist/opensim-0.7.6.tar.gz sudo tar zxvf ./opensim-0.7.6.tar.gz cd opensim-0.7.6 cd bin cp OpenSim.ini.example OpenSim.ini nano OpenSim.ini
Now go to cursor position 1064 where it says the following:
; Include-Architecture = "config-include/Standalone.ini"
Include-Architecture = "config-include/Standalone.ini"
Ctrl-X and ‘y’ to save changes then:
cd config-include nano StandaloneCommon.ini
Then Change the following lines so it shows like this.
; SQLite ;Include-Storage = "config-include/storage/SQLiteStandalone.ini"; ; MySql ; Uncomment these lines if you want to use mysql storage ; Change the connection string to your db details StorageProvider = "OpenSim.Data.MySQL.dll" ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensimuser;Password=opensimpassword;Old Guids=true;"
Effectively, you are turning off the built in SQLite that is handled poorly by the experimental MONO package by commenting it out and uncommenting the Storage Provider and Connection String for MySQL, filling out your database name, username and password and then saving this file Ctrl-X and “y”
Now it’s important that when executing mono files that it is case sensitive, in this case “OpenSim.exe” is the file we need to launch.
Choose your physics engine:
The LibOpenJpeg module:
This library is responsible for generating map-tiles of your Region so that users can see you on the world map. It may be responsible for other functions within the OpenSim engine.
After you’ve installed and configured your estate and parcel for the first time, you’ll see this annoying errors that pop up 3 times every few minutes talking about how it cannot take a snapshot of your terrain because your missing libopenjpeg now! Following the Troubleshooting section it says to do the following:
git clone git://github.com/openmetaversefoundation/libopenmetaverse.git libopenmetaverse cd ./libopenmetaverse/openjpeg-dotnet/
I should note that the address on my site and the address in OpenSim troubleshooting is different. OpenMetaverse Foundation changed their file structure without telling anyone! So I updated my link. Before we continue any further! We’re going to pass the command:
The reason why is we have to strip the -m32 flag out or else when we pass the “Make” command it will get pissed off because we’re not on a X86 processor. go to line 37 where it says the following
and change it to:
save the file and continue to compile the library
make cp -p libopenjpeg-dotnet-2-1.5.0-dotnet-1-i686.so /opensim/bin/lib32/libopenjpeg.so
Finally we have to tell OpenSim where our new library is which mean editing the OpenMetaverse.dll.config in the opensim-0.7.6/bin with nano so “nano OpenMetaverse.dll.config” to get there. This is the original file.
<configuration> <dllmap os="osx" dll="openjpeg-dotnet.dll" target="lib64/libopenjpeg-dotnet-184.108.40.206-dotnet-1.dylib" /> <dllmap os="!windows,osx" cpu="x86-64,ia64" dll="openjpeg-dotnet.dll" target="lib32/libopenjpeg-dotnet-220.127.116.11-dotnet-1-x86_64" /> <dllmap os="!windows,osx" cpu="x86-64,ia64" dll="openjpeg-dotnet-x86_64.dll" target="lib64/libopenjpeg-dotnet-18.104.22.168-dotnet-1-x86_64" /> <dllmap os="!windows,osx" cpu="x86" dll="openjpeg-dotnet.dll" target="lib32/libopenjpeg-dotnet-22.214.171.124-dotnet-1-i686" /> <dllmap os="!windows,osx" cpu="x86" dll="openjpeg-dotnet-x86_64.dll" target="lib64/libopenjpeg-dotnet-126.96.36.199-dotnet-1-i686" /> </configuration>
And this is what mine is:
<configuration> <dllmap dll="openjpeg-dotnet.dll" target="lib32/libopenjpeg.so" /> </configuration>
Once again, stripping out the OS detection flag and pointing it to the right folder. save your file and restart OpenSim.exe
[quote]Can I get libopenjpeg.so from you as well?[/quote]
LibOpenJpeg binary download.
Once again, most people in the Linux community will give you the lecture of how pre-compiled binaries and slamming them into other linux environments can produce unstable results, and they are right! But for those who do not want to go through all of the “fun” of compiling the uploaded pre-compiled version is available right here. It was originally compiled on Raspbian with a Raspberry Pi v1 unit. It does work on the banana Pi which has a ARMv7 processor and thus it should work on the Pi v2 just fine. If you have a different processor other then ARM or running another flavor of Linux then the pre-compiled version will not work out for you.
Finishing touches on OpenSim configuration files
from the /opensim/installation/directory/bin/ folder wherever you installed it to. We are going to edit “nano /config-include/StandaloneCommon.ini” So that when we configure our viewer it will auto-populate with the correct login information and not give us any crap in terms of connection issues to it.
[LoginService] WelcomeMessage = "Welcome, Avatar!" ;; If you have Gatekeeper set under [Hypergrid], no need to set it here, le$ ; GatekeeperURI = "http://127.0.0.1:9000" SRV_HomeURI = "http://opensimpi:9000" SRV_InventoryServerURI = "http://opensimpi:9000" SRV_AssetServerURI = "http://opensimpi:9000" SRV_ProfileServerURI = "http://opensimpi:9000" SRV_FriendsServerURI = "http://opensimpi:9000" SRV_IMServerURI = "http://opensimpi:9000" ;; For Viewer 2 MapTileURL = "http://opensimpi:9000/"
You’re going to want to find the [LoginService] in StandaloneCommon.ini around line 110. We are going to change it from localhost to whatever the logical DNS that your Raspberry Pi is. If you have a Domain Name for your Pi web-server that automatically resolves the IP to you that is even better. In this example I am using the unix hostname ‘opensimpi’ that I configured in the advanced options in “sudo raspi-config” this will give the SecondLife client all of the information it needs when connecting to your Pi.
[GridInfoService] ; These settings are used to return information on a get_grid_info call. ; Client launcher scripts and third-party clients make use of this to ; auto-configure the client and to provide a nice user experience. If you ; want to facilitate that, you should configure the settings here according ; to your grid or standalone setup. ; ; See http://opensimulator.org/wiki/GridInfo ; login uri: for grid this is the login server URI login = http://opensimpi:9000/ ; long grid name: the long name of your grid gridname = "Raspberry Pi OpenSim Default Load" ; short grid name: the short name of your grid gridnick = "opensimpi"
Next, go to [GridInfoService] and do the same down here which is around line 190 on my configuration. Give it a unique grid-name and gridnick so that you can easily see it when you configure your SecondLife Client.
Configuration of OpenSim complete launch it!
Which after all of this, go back into your /opensim/bin folder and mono OpenSim.exe . it should launch nice and clean like the window below.
For those who want a snap-shot of the configuration files that I have altered above. you may download this file and unzip it into your /opensim/bin folder to replace the .config files. In my zip file i created a new directory /bin/lib/ where I pointed the libode.so and libopenjpeg.so files to so I can separate them from the other platforms that exist.
In this example I am using an older FireStorm v2 viewer so that I get mesh support and can build within the sim with something I already like on SecondLife.
As a note the beta versions of FireStorm do not have the Opensim tab in the preferences section of their client. I really don’t know why! So download the older final release and install it (Installing the final release while using the beta releases on Second Life do not conflict with each other. So you can have one configured for your Pi and the other that logs in normally.)
Under Add new grid type in opensimpi:9000 or whatever YOUR hostname that you defined in the StandaloneCommon.ini file. Once you have that typed in, you can hit the Apply button and it will disappear with an entry being added into your Manage Grids second. simply choose your new Pi and click Apply and OK.
The Log into Grid section will change to your Raspberry Pi and from there you simply type your username and password. hit Login and be patient as your OpenSim console on your Pi creates all of the assets of your new user for the first time logging in!
Performance of OpenSim
If you are expecting lightning quick action of OpenSim out of a arm7 processor that only eats a few watts of power. Well, we’re simply not up to the task! You can tell just by how long it takes to make a map-file. On my dual-core Pentium E6300 unit it takes about 5ms, on the Pi 47ms.
Perhaps you can run this in something like OSGrid since the amount of people that visit your Sim may be only a handful at a time. But for the person that wants a DIY Metaverse and to work offline peacefully or with just a few people connecting for group projects. Then the Raspberry Pi is a great alternative of making your 24 hour OpenSim station. Building and working with prim’s is fast. Using scripts is average but it really depends on the complexity of your SLscripts. Physics and Terra-forming is SLOW. it’s really better off to modify your sims parcel on a Linux box and then port it over later to your Pi.
You click on one section of the land and it takes a second for it to respond. The ODE Physics although it works you could potentially lag out your entire sim by rezzing about 32 cubes and turning physics on to watch them collide with each other. You will not only find it painful to move around, but your console will start to send you warnings about latency issues between server and client.
Performance Update with Banana Pi
Update note 12/24/2014:
I have now upgraded to a Banana Pi which is made by LeMaker. It is a dual-core ARMv7 processor which runs at 1Ghz and has a gig of ram. Which falls in line with OpenSim specifications much better then the Raspberry Pi.
Terraforming is almost real-time. Scripts now work as if I was on a low-end dual-core Pentium. Because of the Dual-Core action as well as the DDR3 ram on the Banana Pi which is separate from the On-chip ram of the Raspberry Pi I would say performance is about 4-5 times faster then the Pi.
As for power consumption it’s actually better then my classic B pi because it uses a switching power supply similar to the Raspberry Pi B+. Which means during idle it takes 320ma and when I hammer on the Sim with physics you are looking at 420-500ma which is better then the 700ma idle of the old Raspberry Pi. And for $20 extra you simply cannot beat that kind of price. I will be running my OpenSim on a Banana Pi until I can find something else.
OpenSim will probably run great on the Raspberry Pi 2/3. Anything with multi-core processing helps out mono and therefore helps out OpenSim for all of it’s physics and processing needs. It should be noted that you realistically only need two cores unless you plan on running multiple regions on one ARM based Pi.
Raspian vs. Pidora in OpenSim
I tried Pidora (Fedora for Raspberry Pi) for this procedure and the experimental mono package got even more unstable! Although it lets me login just fine. If you shift-clicked on a prim to make a clone of a pre-existing prim in OpenSim. It would crash giving null database errors even when switching to MySQL on. Although I love Pidora for it’s firewall features which Raspian does not have. And it DID seem to run a little faster under Pidora.. The stability issues was just too much. I also tried to follow the instructions to hand-compile mono hard-float and it didn’t work.
Screenshot above as to the world that is inside of my Pi upon launch. We have since linked it to OpenSim as you could see my progress in this blog entry.
Some final touches to background OpenSIM so you can log off of your headless server
You probably don’t want to keep an SSH connection going all of the time on another computer. You want to run your Raspberry Pi in a headless state like I am doing. Well, there’s a very old Unix command that can help you with this.
sudo apt-get install screen
The screen command is a great tool allowing you to background processes so that even when you logout the process continues to perpetually run to get this started. type the following:
It will just go back to a blank shell prompt then cd into your OpenSim directory and launch your application:
Once that is done simply hit control+A and then control+d to detach this screen session. You can type ‘top’ to verify that mono is still running in the background before you logoff.
To restore your detached session simply type in:
And your right at your OpenSim console!
You may want to have a script that automatically reloads OpenSim in the event of a crash (Since depending on the version of MONO Installed it may happen often) follow this script:
until mono OpenSim.exe ; do EXIT_CODE=$? echo "`date +%Y-%m-%d\ \ %T` # OpenSim crashed with exit code $EXIT_CODE. Restart in 10 seconds." >> crash.log sleep 10 done
This will put it in a loop to restart in case of crash unless you of course quit out of OpenSim Normally
Hope this has helped you! Take care and server protect you!
END OF LINE+++