Home Wiki > SDB:Testing s2ram with live media
Sign up | Login

SDB:Testing s2ram with live media

tagline: From openSUSE

This article describes how you can test s2ram on a machine without installing anything, just by using the openSUSE 10.2 Live DVD. The article is based on a suggestion by Sitsofe Wheeler on the suspend-devel mailinglist.

How to do it

Boot into a text console

Boot from the openSUSE live media. At the graphical boot menu, boot to runlevel 1 by highlighting either the GNOME or the KDE option then typing 1 followed by the return key.


This should eventually put you at a text console which you can log into. From here you can do console testing just like boot with init=/bin/bash as described in the s2ram page.

Start with s2ram -f and proceed through the list as follow until you find one that works:

s2ram -f -a 3
s2ram -f -a 2
s2ram -f -a 1
s2ram -f -p -m
s2ram -f -p -s
s2ram -f -m
s2ram -f -s
s2ram -f -p
s2ram -f -a 1 -m
s2ram -f -a 1 -s

If none of those combinations work, start again but add the "-v" switch. More information can be found in the s2ram page.

Testing X

On openSUSE 11.2 Starting minimal X from the LiveCD seems to be broken. The X server hangs after Xterm is being brought up. If you experience the problem, try testing it in normal X session or use another openSUSE version instead.

For doing (open source driver) X testing, boot to the console as explained above and then run

SaX2 -r

to create a /etc/X11/xorg.conf.

You can then use


to get an X with a simple xterm on it.


From the xterm you got now, you can test suspend from X as described in the s2ram page, using the same list of commands as listed above.


This is not as minimal an environment as init=/bin/sh but it isn't too bad as there is still a lot that isn't loaded (it also stops the boot process quicker than a regular live CD boot). Please also note that while this environment may work without problem a regular boot may still go on to lock the machine up on suspend due to bugs in other modules (e.g. the tg3 network card driver would not be loaded in the above tests). But these are usually not s2ram bugs, but driver bugs that need to be reported and fixed in the kernel anyway.