Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
That was just today, though. Yesterday I did an install and did not receive such errors. Identical harware, different distribution of linux. This is despite entering in the same commands to pull steam from the debian repositories for non-commercial binaries.
I also downloaded the installer off the steampowered.com website, but that did not help. And yes I also installed the i386 32 bit stuff prior to trying to even install steam, let alone launch it.
I had my issues about 27 minutes after the OP posted his. Well, actually, I searched here 27 minutes after he posted. I had been trying to figure out why it didn't work for a while prior to that. I am not sure when it started, but it was within 24 hours prior to the OP posting his issue, since the same installers worked fine (for me at least) yesterday.
It doesnt seem to be very widespread, as I've noticed little other discussion about similar difficulties elsewhere.
As noted, the day before I had success on a different install of debian 10.1 (off a non-commercial firmware live CD no less, rather than the full installer iso and commercial support iso distribution packages for disk based installs). The live cd actually worked better for a number of things to start, but the full install worked better (except for steam) once most other pecularities were addressed.
It will be some time before I can get back at that machine (not today) so if anyone else has the chance to try that also is having the issue... don't wait on me! I might not reply back about success or fail until a day or two has passed, but do intend to reply back with my results.
Thank you! I ran that code and launched Steam again. Steam successfully updated itself, I changed the default library back to my /game volume, and it's properly showing most of my games again. I think the missing ones were Proton games, but I'll toggle that back on again too.
Thank you!
The direct installation from the appropriate media ended up having all sorts of unexpected issues (like this one).
Uh ultimately I torched both scenarios and opted to give Mint 19.2 a try. That effort is ongoing--most games do not even launch, yet others like serious sam fusion 2017 work beyond my expectations (doom 2016 and portal 2, as a counter example, don't even give errors. they just won't launch)..
but these issues may be better suited for some other post.
Most importantly, the errors never came up again after I forced a reinstall.
I think it may be due to the AMDGPU-Pro drivers as they relate to debian and the order in which they were installed (in my case) along with steam, but I'm really not sure.
They are not better for gaming than the completely opensource AMDGPU version that comes builtin on the system (inside "Mesa" if you're curious)...
With a recent AMD card and a recent linux distro, once the OS is installed, you need do nothing more, except maybe:
1- follow this guide to fetch a newer version of Mesa:
https://github.com/ValveSoftware/Proton/wiki/Requirements#amdintel
2- open the Update Manager, find a "Linux Kernel" submenu, install the latest version available at the 5.0 branch and reboot
The PRO version is only better for non-gaming parallel processing tasks like running OpenCL, but it actually has worse performance and a few extra quirks on games, besides being prone to issues while installing (as you likely noticed now).
If you have installed the Pro version from AMD's website every time until now, this is very likely what caused your weird troubles.
It's hard to break the Windows habits, but as a general advice about Linux Mint for non-experts (mostly applicable to other linux distros):
- get *everything* from the repos (via "sudo apt install ..." or via the "Software Manager". This makes installing stuff safer and easier
- get updates via the "Updates Manager" or via "sudo apt update" then "sudo apt upgrade"
- get extra drivers via "Driver Manager" and if they are not listed you probably don't need any (true at least for GPUs)
The card is not recent. I have nothing newer; I found an older ATI 1950XTX worked better across all platforms than the HD5450, HD 6550, R7-250Xes I have tried. Finally I freed up the R9-290 and found that it worked great the first time but never again after that via that debian live CD install-to-disk effort. (I didnt want to run a "permanent" OS off a live CD install, and so... my debacle).
The live CD install of debian 10.1 ran everything gaming related just fine, but uh had other problems unrelated to steam, so I dual booted and set up a proper install of debian off of the non-open/custom firmware distribution.
That guy wouldn't even install steam without the library errors. It didn't matter what software I was using for the card.
I edited a lot out of my reply; but for now... I reinstalled debian from the DVD again and chose the cinnamon desktop environment. I am now working through the system customizations prior to the video card, but hope to get at that this weekend.
I appreciate the help, though, even if I am slow to get to using it.
Incidentally, I chose the pro drivers because I want to see the differences. I'm not going to learn much for myself if I don't break it, and if I just trust wizards all the time... well.. I won't really know what the wizards are doing. I'll read the books so I can cast the spells, so to speak, but I also want to find out in some cases if the paint really is wet no matter what the sign says.
I ended up having to re-install python 2.7.1 and then changing each game's specific proton package being used.
That also included games that otherwise didn't even come with the suggestion that Valve recommends this or that version of Proton -- games that worked OK off the Live DVD installed OS that didn't have Proton indicated as being in use required this as well.
But... after doing so, and even after setting the game preferences back to not forcing a versoin of Proton to use, those same games worked again.
They often downloaded pretty large amounts of content despite being installed already; I am not sure what the updates specifically included, but something additional was needed after I changed the proton around.
In the end, I was able to get the Doom (2016) game working and was able to run at 2560x1440 with everything set to ultra -- except for the shadows. Setting the shadows to ultra dropped performance from like 60-75fps to 6fps. Setting shadows to high bumped it right back up to 60-75fps.
This surprises me, because I had played this game on Windows with two of these R9-290s in crossfire and was getting the same performance. In this system, I just have one of those cards. I did, however, had shadows set to ultra in the system with the r9-290s in crossfire. That was windows 7, though (editing this to comment that I had overclocked the chip by 500mhz more this time around, so that likely contributed to some of the performance seen if not all due to the gpu firmware/drivers)
I am going to guess (since I haven't checked) that the live DVD included some of the programming environments as part of the generic install; specifically, missing dependencies that were silently failing that steam/proton needed in one way or another.
Installing games with those dependncies just worked; installing games without them had them fail without so much as an error. They just closed theri window and never even launched (not only Doom, but much more modestly demanding games, like FEZ or Monaco).
Now I just have to get a modern disk imaging program; my previous collection of tools appears to have aged itself into obsolecence; they don't recognize the partition types and tried to use DD to make the images... it'd take a long time... but anyway I can figure out what I want to do about that on my own; for now I'll just use timeshift to snapshot my recent changes until I settle on something external to create those backups.
Thanks for your help, even if you didn't directly participate too much ;)
Set proton to 4.11-6, click ok!
None of the quoted models has amdgpu support except r9-290 which has experimental support (off by default) but IIRC many have a hard time getting it to work stably. (there are kernel boot parameters to enable amdgpu on it easily)
Which model was the gpu you were originally testing? Was it one of the r9-290s or a newer card?
That is weird if it happened under Linux Mint as I'm sure needed firmware should be there, not 100% sure about Debian as I don't ever use it myself.
Once I bumped into an issue where firmware location for radeon and amdgpu used to be the same and became different on newer kernel versions...
Check if python3 is installed... it is a requirement for proton and afaik it should be there but better be sure this isn't an issue
Each person has their own pace and style for learning, so I respect that! Personally I'd get a stable system doing things the easy way first then make a backup and then poke around bit by bit after getting the daily routine stuff sorted out.
Also even via terminal you should try to stick by default to stuff that respects a distro's repositories, like "sudo apt update", "sudo apt upgrade", "sudo apt install xxxxxx" and "ubuntu-drivers list" which is doing exactly the same as the software, update and driver manager GUI are doing (actually since this is linux, these GUI are just cute frontends to run these very same commands with the right parameters).
It only makes sense to go and fetch stuff outside the repositories if you really *need* a newer version of a package than the one in the repos (but then you should try to find a well-known PPA for that, so it still gets updates like it would from the nornal repos) and when something just isn't available any other way (but be careful with untrusted sources and doubly careful with breaking things in the process).
ps: LM makes even managing PPAs easy via GUI, by using "Software Sources". It helps keep a clear picture of the custom mess we make when adding 3rd party repos (but you really shouldn't need to add many)
afaik Crossfire never worked and still doesn't under Linux... I'd take a wild guess and say the performance drop is likely related to having too little GPU resources like GPU RAM available (in a single card like those) to handle what's needed for "ultra" shadows and maybe it would run into this also on windows... comparing performance over a single working gpu (even if a second one is physically attached, just not in cooperative use) with crossfire is obviously going to get at least some worse results
In *this* particular instance, I've only tried using the R9-290. Funny thing, in my attempts to back up the image after I was at a point where if I messed it up royally I'd be beyond upset (there are only so many hours one wishes to repeat and still call it a positive learning experience...) and I found that... nothing I had could back up the drive.
I had added some complications; I installed an Optane 900p in and set the swap drive to that and altered the swappiness to make it swap less, but when it did--it'd go to the 900p (I set a 10GB partition on it; all of the steam games are there and some 3rd party stuff--the boot drive is just a mechanical drive I had laying around).
All my old tools couldn't read the optane drive when booting externally; none of them could properly read the disk partitions in a manner that let me back them up... except for using DD.
20 hours to backup a 2TB drive with 45GB of actual data, optane not included. I couldn't unselect the default swap parition either; that 68GB automatically made partition (which I haven't cleaned up yet) took 2 hours to backup and it was empty anyway.
I ended up using a new version of clonezilla live and that worked. 20 hours down to somewhat less than an hour; I'd never use DD unless I had to, and I expected that the live CD for debian would at least include methods of recovery that exceeded that. Not so much if images were the goal.
I could end up writing a small novella for you as far as the approach I've had so far, but I'll try to recapitulate somewhat: the live dvds (debian, mint, knoppix) booted up and used the r9-290 without software rendering. The "install" dvds resorted to software rendering after installing (even showing an error at startup prior to the gui initializing).
I also found that HD5450s (i have two) and HD6450s (I also have two) all would fizzle and go black after a few minutes of use. I tried to use them for steam streaming clients; after getting the same firmware working, perfomance would work really well based on the advanced debug/diagnostic info steam's client provides -- as well as actual gameplay from streaming from the pc actually doing the work. I could go at 2560x1440 with no issues--until the screen blanked. I ended up using an old (ancient?) ATI 1950XTX and that had no problems at all; it barely fits in that PC's case, though...
And so... I decided well maybe I should try to get *this* system to play more locally; hence this effort. Plus I want to get it to do a bunch of other stuff besides, and... well, like I said, I could write a novella.
Ultimately, without tweaking, everything ephermal worked great and everything permanent failed in some manner.
Now if I could only find a way to remove that "insert emoji" from the context menus... how bizarre to see that as an option in so many technical configuration menus.
(as to crossire/sli, yes I know it is not supported--it's been a big bummer for me. it's hard to draw a fair comparison between systems when you're used to something you can't have on something "new". At least the optane worked without jumping through hoops, but I did have to use lspci -vv a few times to troubleshoot the amount of pcie lanes it was negotiating at first...)