S2RAM On Version 6.1?

[revco]

Hey all,

 

So a couple months ago, I took the plunge and upgraded my 4.7 system all the way to 6.1.4, and now 6.1.6.  All went well, I did a "clean" migration to avoid problems and most everything is working well.  Going back just simply isn't an option as I now want 2TB+ drive support and the GUI improvements.

 

My machine has had problems with traditional S3 sleeping where the system would respond to WOL, but video wouldn't come back and network would die shortly after WOL.  I was able to get my 4.7 box to sleep and return properly with S2RAM, so this weekend I've been trying to get it working in 6.1.  I've got all the script components working properly, which leverage installed bwm-ng and libx86 packages, but I believe my problem is lower than that.  I can't even manually call S2RAM, which the automated script I'm using also substantiates this.  When I execute S2RAM I get:

 

root@gaia:/boot# s2ram -h

-bash: ./s2ram: cannot execute binary file

 

I don't recall running into this issue on the 4.x install, but I also admit it's been quite awhile.  I've checked the usual suspects, the file is executable, libx86 v1.1 installs successfully (both on boot or manually), re-downloaded S2RAM twice from two sources, tried running it with ./ and many other things.

 

My best guess at this point, after some rather extensive research, is that this may be a 32bit vs. 64bit issue.  My S2RAM file was compiled on/for the 32bit version...I didn't compile it, it's just what I found on the forums here.  My understanding is that a 64bit OS "should" be able to execute 32bit applications, but maybe not in this case?

 

root@gaia:/boot# uname -a

Linux gaia 4.1.13-unRAID #1 SMP PREEMPT Fri Nov 13 20:26:59 PST 2015 x86_64 AMD Sempron 145 Processor AuthenticAMD GNU/Linux

root@gaia:/boot# file s2ram

s2ram: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

root@gaia:/boot# ldd -r s2ram

        not a dynamic executable

 

I've also read there's some differences in sleep behavior introduced in 6.x, but haven't been able to positively identify what these are and don't know why that would result in the above error.  I feel like I've entirely exhausted my Google-fu and have re-read every single document I can find with no references to my problem.

 

For giggles, I did try using the S3 plugin from Dynamix, but alas my problems above still present themselves.  I'd rather avoid a major hardware swapout at this point, the system has been rock stable for many years now.  I *can* get the Dynamix plugin to work using shutdown, but I prefer the faster sleep mode revival.  If I can't get this working, that's probably the route I'll go as it's important for me to save the power.

 

Has anyone gotten S2RAM working in 6.1.x?  Am I missing something stupid?  Appreciate any insight you might be able to provide.

 

[CHBMB]

I think you've hit the nail on the head with trying to run 32bit on a 64bit system...

 

I don't fully understand the workings behind it, but on Slackware you need 64bit versions.

[revco]

I've been doing a little more digging and I think this has to do with where Slackware 14.1 references the libraries that are installed.  According to the link below, /lib64 and /usr/lib64 are the default places where Slackware looks for libraries.  Installing the "old" 32 bit version of libx86 puts it into /usr/lib, so I don't believe the library is getting found properly.  There's a fair bit of information on making Slackware multi-library capable, which I'll keep studying.  In the meantime, if anyone has a fix or further helpful info, I'd appreciate it.

 

root@gaia:/usr/lib# ls -l

total 8

lrwxrwxrwx 1 root root  11 Jan 10 12:51 libx86.so -> libx86.so.1*

-rwxr-xr-x 1 root root 7416 Nov 30  2008 libx86.so.1*

 

 

http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

 

 

[itimpi]

UnEAID v6 does not include 32-bit compatibility so it cannot run 32-bit applications.  With v6 all binaries must be 64-bit versions.

[revco]

Well, unfortunately, simply turning up libx86's 64bit version wasn't enough to get S2RAM working.  I was able to find "libx86-1.1-x86_64-1.txz" in the Slackware repository, but still no dice even with a 64-bit enabled x86 library.  I think fundamentally, it comes down s2ram being 32 bit, as shown in my file output above.

 

Per the Alien link I posed above about 32/64bit libraries, I tried that path and got all the libraries converted over to 32/64bit, but that still didn't allow me to execute s2ram.  This also broke a few things in Unraid as well, was getting undefined errors all over the web interface and who knows what else.  (Didn't keep it around long enough to figure out what all broke.)  Would have been nice 'cause I figured I could run all the commands to rebuild the libraries from "go" on boot, but alas, that's not a viable path.

 

I did go so far as to try and recompile the suspend application (root application for s2ram) and ran into a host of troubles there.  I haven't been able to determine if it would be truly impossible to compile a 64bit version of s2ram at this point, but the suspend project is no longer supported and clearly ended in the 32 bit era.  A few things I've read indicate that it might not be possible.

 

I may give it another go at some point, but at this point I think I just need to be happy with automatic shutdowns and thankful my machine will WOL from that state.  Of course, if anyone has other ideas, I'd be really happy to hear about them.

[BRiT]

The unraid kernel does not support 32bit libraries. No amount of what you do will work, unless you recompile the unraid linux kernel too once you enable 32bit options.

 

You will have an easier time getting the source of s2ram and compiling it under 64bit gcc.