The Other Linux Thread

[Gfurst]

Derp. AMD, not ATI. Oy...

I get multi-screen working sort of with the AMD drivers. I got the screens and resolutions all set up, but I couldn't move windows to different screens. There was some Xandia or X-something thing that us supposed to allow you to do this if you check it on in CCC, but when I did that it caused it to grenade. Since I had dorked up GRUB I just went ahead and wiped and re-installed, so I'm back to baseline.

LoL, quite an adventure han?

Some more advices then: before installing the proprietary AMD drivers, try up with stock Xorg drivers, they might work better specially for Multi-screen setup. I can't help you with multiple monitors since I never delved into it and saw a necessity.

Since most of the issues you're getting are more OS related, be sure to head up to the Ubuntu forums, more likely where there will be a lot of helpful people to assist you. Try to stick with Ubuntu , but I would recommend using another graphical environment instead of it stock Unity, Xfce is light and flexible, ideal if you're only going to game on it.

[Insanitic]

Thanks for the informative post Skeevy.

I have a problem though with my KSP x64 build on Ubuntu 14.04. I have AMD's latest proprietary drivers installed and have tons of mods in my GameData folder also. I have transferred my Windows save file to my linux build. So I launch the x64 build of KSP and everything goes fine and dandy until I arrive at Kerbal Space Center bird's eye view point right after you load a save file. After a few seconds or so, KSP completely freezes, and a few seconds after KSP freezes, my whole compy freezes (not even the numlock light and mouse is working).

Does anyone have insight to this problem? I have read somewhere that it might be due to the fact that I'm using beta drivers version 14 and I need to downgrade to catalyst 13.12.

[steve_v]

Does it crash with the open source 'radeon' driver?

Is the proprietary driver stable on 32bit?

Rolling back to an earlier AMD driver version may help, but 'ware Xorg / kernel version compatibility issues.

If it does, we should probably document it somewhere, as people are wont to think 'newer is better'...

If X locks up (i.e. kbd / mouse / display) the magic SysRq key combo may well get you back a shell, where you can look through the system logs for errors from the driver. Or just ssh in from another machine.

Does dmesg output, /var/log/messages (or /var/log/syslog) or ~/.xsession-errors have anything interesting in it?

So far all the reports of crashing / locking up the X server are from people with AMD cards, running the proprietary driver, so...

Has anyone with an AMD card poked AMD / investigated on AMD forums regarding his problem? I don't think it's a KSP issue somehow.

Worth noting that migrating files from a Windows install may cause various subtle and annoying problems - GNU/Linux is case sensitive for file names, and uses different line endings in text files (LF vs CR/LF).

It may be worth testing with a new save, just in case. I suspect you're right about catalyst though.

[Insanitic]

Does it crash with the open source 'radeon' driver?

Is the proprietary driver stable on 32bit?

Rolling back to an earlier AMD driver version may help, but 'ware Xorg / kernel version compatibility issues.

If it does, we should probably document it somewhere, as people are wont to think 'newer is better'...

If X locks up (i.e. kbd / mouse / display) the magic SysRq key combo may well get you back a shell, where you can look through the system logs for errors from the driver. Or just ssh in from another machine.

Does dmesg output, /var/log/messages (or /var/log/syslog) or ~/.xsession-errors have anything interesting in it?

So far all the reports of crashing / locking up the X server are from people with AMD cards, running the proprietary driver, so...

Has anyone with an AMD card poked AMD / investigated on AMD forums regarding his problem? I don't think it's a KSP issue somehow.

Worth noting that migrating files from a Windows install may cause various subtle and annoying problems - GNU/Linux is case sensitive for file names, and uses different line endings in text files (LF vs CR/LF).

It may be worth testing with a new save, just in case. I suspect you're right about catalyst though.

Thanks for the reply.

When I tried it with the open source drivers, KSP and ubuntu in general was going at about 5 fps.

When I tried opening the x86 version, nothing happens. I doubleclick on the executable and nothing happens.

Also I've already applied the file name fix and my problem still persists.

Edited November 27, 2014 by Insanitic

[cantab]

Sounds like what I'd expect from the open source drivers performance-wise.

Also not surprised the x86 version doesn't run. 64-bit Ubuntu doesn't come with the needed 32-bit components by default. I can't remember what they are, but if you run KSP.x86 from the command line you should get an error message that'll tell you what's missing. You can then install the :i386 versions of the relevant components through the software centre.

Or you can just run the 64-bit version.

As for the crash, faulty beta drivers is the obvious guess really.

[sal_vager]

Ubuntu is supposed to come with them now so the old x86 compatibility packages are gone from the repos

You can try starting KSP with ldd though to see what you need "ldd KSP.x86 | grep "Not found""

If there is anything missing it can be installed using the terminal and ":i386" after the package name.

Edited November 27, 2014 by sal_vager

[Insanitic]

Thanks for clarifying some aspects of my problems.

But my ultimate goal is to make the x64 build playable since I have a ton of mods.

I tried installing 13.12 drivers but at the end of the setup process, it says there were errors (I downloaded an old 13.12 .run file and made it executable). So when I rebooted my compy, Ubuntu just returns a black screen appears with a crap load of errors in white text and the desktop environment won't even login.

So my question is: How do people get KSP working and playable in the newest Ubuntu 14.04/10?

I'm at a loss of what to do now since I'm a newbie to Linux

Edited November 27, 2014 by Insanitic

[steve_v]

How did you install the drivers in the first place? AFAICT Ubuntu 14.04 repos have 13.350, 14.10 has 14.201.

See here.

Installing old drivers with the .run file is bound to go horribly wrong, especialy if you didn't remove the existing driver first.

I suspect that old driver is incompatible with the kernel or Xorg version Ubuntu ships:

--8<--

Xorg/Xserver 7.4 and above (up to 1.14)

Linux kernel 2.6 or above (up to 3.11)

-->8--

Have you tried the *distribution provided packages* - eg. 'apt-get install fglrx'?

Deleting /etc/X11/xorg.conf (or restoring the backup you made, hint hint), removing the AMD driver & re-installing the open source driver *should* get X running so you can start again.

However, I have neither an AMD card nor an Ubuntu install (but I do have an xubuntu VM) so you'll have to post the actual error messages generated by 'startx' from the console if you want any help with them.

If you want to use the installer from AMD, or the betas, ensure you have read the instructions

When I tried it with the open source drivers, KSP and ubuntu in general was going at about 5 fps

I am aware that performance withthe radeon driver is somewhat lack-luster, but that sounds like you have no acceleration at all.

'glxinfo | grep direct' should return "direct rendering: Yes" if it's correctly installed.

Edited November 28, 2014 by steve_v

[Insanitic]

How did you install the drivers in the first place? AFAICT Ubuntu 14.04 repos have 13.350, 14.10 has 14.201.

See here.

Installing old drivers with the .run file is bound to go horribly wrong, especialy if you didn't remove the existing driver first.

I suspect that old driver is incompatible with the kernel or Xorg version Ubuntu ships:

--8<--

Xorg/Xserver 7.4 and above (up to 1.14)

Linux kernel 2.6 or above (up to 3.11)

-->8--

Have you tried the *distribution provided packages* - eg. 'apt-get install fglrx'?

Deleting /etc/X11/xorg.conf (or restoring the backup you made, hint hint), removing the AMD driver & re-installing the open source driver *should* get X running so you can start again.

However, I have neither an AMD card nor an Ubuntu install (but I do have an xubuntu VM) so you'll have to post the actual error messages generated by 'startx' from the console if you want any help with them.

If you want to use the installer from AMD, or the betas, ensure you have read the instructions

I am aware that performance withthe radeon driver is somewhat lack-luster, but that sounds like you have no acceleration at all.

'glxinfo | grep direct' should return "direct rendering: Yes" if it's correctly installed.

I reinstalled my Ubuntu and now it is a fresh install running the open source drivers.

So to ensure that x64 KSP works flawlessly, what driver package should I go with? And what method in the links you gave, would you recommend me take to ensure that KSP works?

[cantab]

I'd say keep it simple to start with. If you're fine with the command line,

sudo apt-get install fglrx

That will install the proprietary AMD graphics drivers, which ever version is considered stable for your Ubuntu install.

[steve_v]

As above, the easiest way to get GPU drivers is to use the distro provided packages:

'sudo apt-get install fglrx fglrx-amdcccle'

Details in section 2.1 of the instructions I linked.

As with most software on GNU/Linux the distro packages are the safest bet, only muck about with upstream updates if you think you need them.

Personally, I use the smxi scripts for upstream GPU drivers in the rare cases where I need them.

While I can provide information, I cannot & will not provide any warranty as to what will & will not work with your specific setup.

As I said, I don't have an AMD card to test - unless you count the HD 5450 in my work machine, which is running Debian Wheezy anyway.

If you want such assurances you must wait for someone with a working AMD install to chip in.

OTOH, you could try it and find out. You could even post back with what works, for the benefit of others

[Insanitic]

I understand. Thanks for all the help everybody.

Just one more thing. Is there a way to check whether I'm really running KSP x64? Because KSP works and I put in the right launch commands in Steam for x64 but it seems even slower than my Windows build (And yes, Hardware acceleration is working). I'm using the open source drivers.

[sal_vager]

It will be slower on the open drivers unfortunately, and if you started KSP x64 then that's what you're playing

[gsarducci]

Does it crash with the open source 'radeon' driver?

Is the proprietary driver stable on 32bit?

Rolling back to an earlier AMD driver version may help, but 'ware Xorg / kernel version compatibility issues.

If it does, we should probably document it somewhere, as people are wont to think 'newer is better'...

If X locks up (i.e. kbd / mouse / display) the magic SysRq key combo may well get you back a shell, where you can look through the system logs for errors from the driver. Or just ssh in from another machine.

Does dmesg output, /var/log/messages (or /var/log/syslog) or ~/.xsession-errors have anything interesting in it?

So far all the reports of crashing / locking up the X server are from people with AMD cards, running the proprietary driver, so...

Has anyone with an AMD card poked AMD / investigated on AMD forums regarding his problem? I don't think it's a KSP issue somehow.

Worth noting that migrating files from a Windows install may cause various subtle and annoying problems - GNU/Linux is case sensitive for file names, and uses different line endings in text files (LF vs CR/LF).

It may be worth testing with a new save, just in case. I suspect you're right about catalyst though.

Not just with the AMD drivers. I have the Open drivers running on my Ubuntu and I get hard locks. Let me step back a moment because I took some steps back and forward...

Blew out my old KSP folder and reinstalled bone stock game (this is direct download, not Steam, BTW). Then went to work to arrange my screens. I have four screens installed, three on the 7950 head, and one using the built in Intel on-die video. I was having wiggy mouse problems so I disabled the screen that was running through the processor vid and it stabilized that. I don't need that screen anyway for what I am doing here, so no harm no foul. Got the remaining three screens sorted out and they are arranged properly and working smashingly. Fantastic.

Ran the bone stock KSP.x86_64 by simply clicking the program. Loads up fine. Set up resolutions and visuals the way I like, loads up fine. Play the game for a few minutes and it's working fantastically (and it seems to run faster then Windows, or at least smoother).

Okay, so I want to run "Realism Overhaul" on this copy, so I set about installing the required mods for that. Following the instructions by the book I install Advanced Jet Engine, FAR, KJR, Module Mangler, ModuleRCSFX, Real Fuels and Real Solar System (with the huge textures because, hey, I am running the 64 bit stuff so I can enjoy the eye candy). Double and triple check everything is where it needs to be and fire up KSP (via the same way as previously). Game appears to load up fine and gets to the main menu, where a popup window comes up from Real Solar System saying it's applying some patches to the planets. It gets part way through this and hard locks the interface (no mouse control, keyboard does jack squat, full on hard lock). Ooookay. I reset the system and try it again. Again it loads up fine, gets to the main menu where the RSS interface pops up and says it's doing its thing, gets to the same spot in the process and HARD LOCKS.

So at least now it's repeatable. And I KNOW I had a working unit when it was bone stock, so its not something inherantly wrong with the video or OS interdependencies. I'm convinced this is something internal to KSP which is blowing up, which leads me to a question. Wasn't there some talk about "memory offsets" or something where KSP was getting beyond a certain threshold in memory paging and soiling itself? It seems like this problem manifests itself when I reach some sort of critical mass with memory usage and I remember somebody had a tidbit of hack code that would "fix" this problem with version 0.24.2, but I didn't see anything for 0.25. Do you think there is any merit to simply rolling back to 0.24.2? I didn't really look to see if that version was stable for Linux, nor whether mods rewritten for 0.25 would be backward compatible.

Needless to say I'm dead in the water again, though this time I KNOW I have a solid installation of Ubuntu 14.04 that is not in danger of grenading on me at a moments notice, so now I can concentrate on getting KSP to stop nuking.

[gsarducci]

Little update.

I found the offset information and applied it. This time it got a little further down the road with RSS applying its changes before it grenaded, but it still hard locked me.

[steve_v]

You appear to be straying into uncharted waters as far as my experience goes

I'd still be curious as to whether this is a real 'hard lockup' of the OS (unlikely IME) or KSP dying while it still has exclusive keyboard & mouse focus - thus rendering them unusable. Can you SSH in when this happens?

I was under the impression that hexedit hack wasn't needed anymore - IIRC it was due to some 32bit code lurking in the texture loader.

If it's still of some benefit it should probably go back in the OP.

[cantab]

How long did you wait when it locked? Linux is more prone than Windows to having the mouse pointer become non-responsive when the system's under heavy load. The RSS wiki mentions that the first run can take over ten minutes, and possibly on Linux this is being allowed to generally hang the system.

Also, the general advice to install and check one mod at a time is good I feel, especially when complex mods like RSS are involved.

On a sidenote, if a CPU-hogging program does render the GUI unusable, Ctrl+Alt+F1 will switch you to a command prompt. That can be more usable when the system's heavily loaded and you can identify and kill the offending program. Switch back to the GUI with Alt+F7.

[gsarducci]

I'm sure the OS is still alive in the background, so I suppose saying that it's "hard locked" is misleading. That being said, I have not tried SSH from another computer. On your suggestion I let it sit for 10 minutes and it didn't do anything new. ctrl+alt+f1 didn't do anything (I'm assuming the keyboard sunk along with the GUI).

The locking up thing seems to be a recurring theme with this once I reach a certain threshold. Unfortunately since the GNU system monitor promptly dumps upon running KSP I can't directly monitor resource usage while this is loading up to see if it consistantly happens when reaching a certain resource level.

Most frustrating is that this isn't happening with anyone else, which means it's fixable, and I'm slowly going insane trying to stumble blindly into the answer. If I could get some hint from a log or something where this is blowing up at least I'd have a road to do down, but all the KSP logs simply stop at the lock with no errors at all.

Oh, I tried 24.2. The mods that were updated to .25 don't work on this older version, so I'm boned on that experiment. FML.

edit: Side note. For some reason after a period of time it gave me my mouse back, but the GUI was still unresponsive to anything I did. Also, I attempted to SSH into here, but I failed to realize I didn't have SSH configured here. None the less, it refused my connection and responded to pings, so the underlying OS is still alive. I suppose I can start to jack around with the video settings or GUI, but historically speaking once I start monkeying around with that it invariably results in me needing to reinstall Linux as it perma-jacks something.

Edited November 29, 2014 by gsarducci

[gsarducci]

So, let's go in this direction... Does ANYONE have a working, moderately to heavily modded copy of KSP86_64 0.25 running on Ubuntu 14.04, running Unity GUI, with an AMD card running the open source drivers?

[vrothenberg]

Does anyone know how to utilize more than 4 GB of RAM for 0.25 64 bit on Ubuntu? I have a ton of mods and during loading whenever the KSP.x86_64 process hits 4.0 GiB it just hangs indefinitely. I've tried using the launch options such as "LC_ALL=C %command%_64" in Steam to make sure 64 bit was selected. Also tried launching KSP through the bash script already mentioned in the original post. All to no avail.

It's a strange problem because I'm fairly certain I could utilize more than 4 GB when playing 0.24.2 and I definitely have enough memory out of the 16 GBs available.

[steve_v]

Does anyone know how to utilize more than 4 GB of RAM for 0.25 64 bit on Ubuntu?

Nothing special required AFAIK, I'm running at ~6.5GB. Sure it's not a mod? Anything in your logs?

[Maars]

same here, i'm running around 5gig on Ubuntu 14.4 and it's fine... apart from having a reduced framerate when the GUI is on. btw - anyone have any ideas as to why when i turn off the GUI with F2, i get at least 30% smoother and faster framerate?

[ChaosNicro]

Hey there,

I'm using the latest SUSE and would like modded, I have been experiencing a strange phenomenon though.

When launching with about 20 mods (two of them part packs) the process manager shows KSP using 1,3GB of RAM.

On the memory manager I can see it taking more than 3GB throughout startup and staying there. (dropping me into swap if I try to install more.)

4GB are free on my system for use.

I'm running the standalone 64-bit linux version.

Active texture management is installed.

Thanks in advance for any help,

Nicro

[gsarducci]

Nothing special required AFAIK, I'm running at ~6.5GB. Sure it's not a mod? Anything in your logs?

Oh? What video card do you have?

[lordmuffin]

[Exception]: NullReferenceException: Object reference not set to an instance of an object

Sometimes when I switch back from a craft back to KSC, it gives me this and doesn't let me click on any buildings.