https://wiki.archlinux.org/api.php?action=feedcontributions&user=Grncdr&feedformat=atomArchWiki - User contributions [en]2024-03-28T12:54:53ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=OpenSSH&diff=65905OpenSSH2009-03-29T01:25:52Z<p>Grncdr: /* X11 Forwarding */</p>
<hr />
<div>[[Category:Daemons_and_system_services (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|Русский|SSH_(Русский)}}<br />
{{i18n_entry|English|SSH}}<br />
{{i18n_entry|简体中文|SSH_(简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
= OpenSSH =<br />
<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installing OpenSSH ==<br />
# pacman -Sy openssh<br />
<br />
== Configuring the SSH server ==<br />
To configure you must edit the configuration file:<br />
$ su -c 'nano /etc/ssh/sshd_config'<br />
<br />
You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]). <br />
<br />
Even though the port ssh is running on, could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts.<br />
<br />
===Adjust the configuration===<br />
The configuration file can be found at ''/etc/ssh/ssh_config'' and the basic version looks like this:<br />
<br />
<pre><br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for various options<br />
<br />
# Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc<br />
# EscapeChar ~<br />
</pre><br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
Of course there is also a configuration file for the SSH daemon. It's called ''/etc/ssh/sshd_config'' and looks like this:<br />
<pre><br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#Protocol 2,1<br />
ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh''host''key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh''host''rsa_key<br />
#HostKey /etc/ssh/ssh''host''dsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 768<br />
<br />
# Logging<br />
#obsoletes ~QuietMode and ~FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you don't trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
#ChallengeResponseAuthentication yes<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing,<br />
# and session processing. If this is enabled, PAM authentication will<br />
# be allowed through the ~ChallengeResponseAuthentication mechanism.<br />
# Depending on your PAM configuration, this may bypass the setting of<br />
# PasswordAuthentication, ~PermitEmptyPasswords, and<br />
# "PermitRootLogin without-password". If you just want the PAM account and<br />
# session checks to run without PAM authentication, then enable this but set<br />
# ChallengeResponseAuthentication=no<br />
#UsePAM no<br />
<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression yes<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
<br />
# no default banner path<br />
#Banner /some/path<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server<br />
<br />
</pre><br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
You might want to change some lines so that they look as following:<br />
<pre><br />
Protocol 2<br />
.<br />
.<br />
.<br />
LoginGraceTime 120<br />
.<br />
.<br />
.<br />
PermitRootLogin no # (put yes here if you want root login)<br />
</pre><br />
<br />
You could also uncomment the BANNER option and edit ''/etc/issue'' for a nice welcome message.<br />
<br />
===Allowing others in===<br />
{{Box Note | You have to adjust this file to remotely connect to your machine since the file is empty by default}}<br />
<br />
To let other people ssh to your machine you need to adjust ''/etc/hosts.allow'', add the following:<br />
<br />
<pre><br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
</pre><br />
<br />
Now you should check your ''/etc/hosts.deny'' for the following line and make sure it looks like this:<br />
ALL: ALL: DENY<br />
<br />
That's it. You can SSH out and others should be able to SSH in :).<br />
<br />
To start using the new configuration, restart the daemon:<br />
$ su -c '/etc/rc.d/sshd restart'<br />
<br />
== Managing SSHD Daemon ==<br />
Just add sshd to the "DAEMONS" section of your /etc/[[rc.conf]]:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# /etc/rc.d/sshd {start|stop|restart}<br />
<br />
==Connecting to the server==<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
= Tips and Tricks =<br />
<br />
== Encrypted Socks Tunnel ==<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you don't have to remember your IP-address.<br />
<br />
=== Step 1: Start the Connection ===<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where "user" is your username at the SSH server running at the "host". It will ask for your password, and then you're connected! The "N" flag disables the interactive prompt, and the "D" flag specifies the local port on wich to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your ~/.bashrc file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose "-v" flag, because then you can verify that it's actually connected from that output. Now you just have to execute the "sshtunnel" command :)<br />
<br />
=== Step 2: Configure your Browser (or other programs) ===<br />
<br />
The above step is completely useless if you don't configure your web browser (or other programs) to use this newly created socks tunnel. <br />
<br />
* For Firefox: ''Edit -> Preferences -> Advanced -> Network -> Connection -> Setting'':<br />
: Check the "Manual proxy configuration" radio button, and enter "localhost" in the "SOCKS host" text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
: Make sure you select SOCKS4 as the protocol to use. This procedure will not work for SOCKS5.<br />
<br />
Enjoy your secure tunnel!<br />
<br />
== X11 Forwarding ==<br />
<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client.<br />
<br />
Install xorg-xauth on the server:<br />
# pacman -Sy xorg-xauth<br />
<br />
* Enable the ''X11Forwarding'' option in ''sshd_config'' on the server.<br />
* Enable the ''ForwardX11'' option in ''ssh_config'' on the client.<br />
<br />
''In order to have this work with an Ubuntu server on my machine I needed to install xorg-xauth as well as enable ForwardX11Trusted in ssh_config on the (Arch) client''<br />
<br />
== Mounting a Remote Filesystem with SSHFS ==<br />
<br />
Install sshfs<br />
# pacman -Sy sshfs<br />
<br />
Add the user that we want to give the permission to mount SSH folders to the fuse group <br />
<br />
# gpasswd -a USER fuse<br />
<br />
Load the fuse module (in /etc/rc.conf for example)<br />
<br />
And then, after logging in, we can try to mount a remote folder using sshfs:<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SCP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the /etc/fstab table. This way is can be automatically mounted upon system boot or mounted manually (if noauto option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto 0 0<br />
<br />
= Links & References =<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[[Using SSH Keys]]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]</div>Grncdrhttps://wiki.archlinux.org/index.php?title=Acpid&diff=65228Acpid2009-03-18T05:36:56Z<p>Grncdr: /* Getting user name of the current display */ I added tail -n1 because I was getting a line for every terminal I had open</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Summary ==<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering ACPI events. These events are triggered by certain actions, such as:<br />
* Pressing the Power button<br />
* Pressing the Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
acpid can be used by itself, or combined with a more robust system such as [[Pm-utils]] and [[Cpufrequtils]] to provide a more complete power management solution.<br />
<br />
== Installation ==<br />
The acpid package is available from the official repositories:<br />
# pacman -S acpid<br />
Edit <tt>/etc/rc.conf</tt> as root and add '''acpid''' to the DAEMONS array, for example:<br />
DAEMONS=(syslog-ng '''@acpid''' @alsa @crond ... )<br />
'''Note:''' If you already have '''hal''' specified in your DAEMONS, there is no need to add '''acpid'''. HAL will automatically detect and load the acpid daemon.<br />
<br />
== Configuration ==<br />
acpid comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in ''/etc/acpi/handler.sh'', which is executed after any ACPI events are detected (as determined by ''/etc/acpi/events/anything'').<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep Button is pressed, acpid runs the command ''echo -n mem >/sys/power/state'' which ''should'' place the computer into a sleep (suspend) state:<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or Fn shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
Now press the Power button and/or Sleep button (e.g. Fn+Esc) on your machine. The result should look something this:<br />
Aug 29 17:18:31 dublin logger: ACPI action undefined: PBTN<br />
Aug 29 17:18:33 dublin logger: ACPI action undefined: SBTN<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default ''/etc/acpi/handler.sh''. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the ''handler.sh'' file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
By default, all ACPI events are passed through the ''/etc/acpi/handler.sh'' script. This is due to the ruleset outlined in ''/etc/acpi/events/anything'':<br />
<pre><br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
</pre><br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create and edit the file: ''/etc/acpi/events/sleep-button''. Add the following:<br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
<br />
Now create and edit the file: ''/etc/acpi/actions/sleep-button.sh''. Add:<br />
<pre><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</pre><br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
== Tips & Tricks ==<br />
=== Extending acpid with pm-utils ===<br />
Although <tt>acpid</tt> can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[Pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, <tt>pm-suspend</tt> and <tt>pm-hibernate</tt>, both of which can be inserted as events into acpid. For more information, check the [[Pm-utils]] wiki.<br />
<br />
=== Sample Events ===<br />
The following are samples of events that can be dropped into the existing <tt>/etc/acpi/handler.sh</tt> script. '''Bolded''' text indicates modifications or additions to the default script. As noted above, your event labels may differ so some tweaking may be necessary.<br />
<br />
Activate Xscreensaver upon lid closure:<br />
button/lid)<br />
#echo "LID switched!">/dev/tty5<br />
'''''/usr/bin/xscreensaver-command -lock'''''<br />
;;<br />
<br />
Execute <tt>pm-suspend</tt> (from [[Pm-utils]]) when the Sleep button is pressed:<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
'''''#echo -n mem >/sys/power/state'''''<br />
'''''/usr/sbin/pm-suspend'''''<br />
;;<br />
<br />
=== Laptop Monitor Power Off ===<br />
From "AM088" on the gentoo wiki comes this little gem. Add this to the bottom of your /etc/acpi/actions/lm_lid.sh file (requires laptop-mode-tools package). This will do nothing but turn your monitor off when you close the lid:<br />
<pre> <br />
if grep -q open /proc/acpi/button/lid/LID/state<br />
then<br />
XAUTHORITY="$( ps -C xinit f|sed 's/.*-auth \(.*\)serverauth.*/\1Xauthority/p' )" /usr/bin/xset -display :0.0 dpms force on<br />
else<br />
XAUTHORITY="$( ps -C xinit f| sed -n 's/.*-auth \(.*\)serverauth.*/\1Xauthority/p' )" /usr/bin/xset -display :0.0 dpms force off<br />
fi<br />
</pre><br />
<br />
=== Getting user name of the current display ===<br />
You can use the function <tt>getuser</tt> to acquire the user of the current display:<br />
<code><br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
</code><br />
This function can be used for example, when you press the power button and want to shutdown KDE properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
== More Resources ==<br />
*http://acpid.sourceforge.net/ - acpid homepage<br />
*http://www.capaman.8m.com/acpid.html - acpid mini-howto</div>Grncdrhttps://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=65178Suspending to RAM with hibernate-script2009-03-17T05:34:36Z<p>Grncdr: /* Different Methods of Suspending to RAM */ tweaking some grammar things</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
====Overview====<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
====Different Methods of Suspending to RAM====<br />
There is an application, called s2ram, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use s2ram to suspend to ram "out of the box". Non-whitelisted laptops need to try different command line options of s2ram in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
===s2ram===<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
=====Testing=====<br />
After installing the uswsusp package, check to see whether s2ram recognizes your machine:<br />
<br />
# s2ram -n<br />
<br />
If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:<br />
<br />
# s2ram<br />
<br />
Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.<br />
<br />
If s2ram doesn't match your machine to an entry in it's whitelist it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f. You may also have to try the different "tricks" offered by s2ram. Run s2ram -h to get a list of the possible options:<br />
<br />
# s2ram -h<br />
The following options are only available with --force:<br />
--vbe_save save VBE state before suspending and restore after resume.<br />
--vbe_post VBE POST the graphics card after resume.<br />
--vbe_mode get VBE mode before suspend and set it after resume.<br />
--radeontool turn off the backlight on radeons before suspending.<br />
--pci_save save the PCI config space for the VGA card.<br />
--acpi_sleep <acpi_sleep> set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.<br />
<br />
Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.<br />
<br />
=====Whitelisting=====<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report your identification strings and any tricks required to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].</div>Grncdrhttps://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=65177Suspending to RAM with hibernate-script2009-03-17T05:31:10Z<p>Grncdr: added information on customizing s2ram from ABS, structured the article and rewrote large parts of the s2ram section</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
====Overview====<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
====Different Methods of Suspending to RAM====<br />
There is nowadays an application, called s2ram, which contains a list of existent laptop models and, according to what has been reported by other owners of these laptops, try to do the right things for that specific laptops: these laptops are 'whitelisted'. The whitelisted laptops can thus use successfully s2ram to suspend to ram. On the contrary, the non-whitelisted laptops need to try all the different command line options of s2ram in order to determine - by trial and error - the appropriate combination. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
===s2ram===<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
=====Testing=====<br />
After installing the uswsusp package, check to see whether s2ram recognizes your machine:<br />
<br />
# s2ram -n<br />
<br />
If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:<br />
<br />
# s2ram<br />
<br />
Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.<br />
<br />
If s2ram doesn't match your machine to an entry in it's whitelist it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f. You may also have to try the different "tricks" offered by s2ram. Run s2ram -h to get a list of the possible options:<br />
<br />
# s2ram -h<br />
The following options are only available with --force:<br />
--vbe_save save VBE state before suspending and restore after resume.<br />
--vbe_post VBE POST the graphics card after resume.<br />
--vbe_mode get VBE mode before suspend and set it after resume.<br />
--radeontool turn off the backlight on radeons before suspending.<br />
--pci_save save the PCI config space for the VGA card.<br />
--acpi_sleep <acpi_sleep> set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.<br />
<br />
Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.<br />
<br />
=====Whitelisting=====<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report your identification strings and any tricks required to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].</div>Grncdrhttps://wiki.archlinux.org/index.php?title=Suspending_to_RAM_with_hibernate-script&diff=65176Suspending to RAM with hibernate-script2009-03-17T04:48:01Z<p>Grncdr: /* s2ram */ Updated the section on whitelisting your machine to reflect the fact that uswsusp is now in the repos</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine.<br />
Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.<br />
<br />
There is nowadays an application, called s2ram, which contains a list of existent laptop models and, according to what has been reported by other owners of these laptops, try to do the right things for that specific laptops: these laptops are 'whitelisted'. The whitelisted laptops can thus use successfully s2ram to suspend to ram. On the contrary, the non-whitelisted laptops need to try all the different command line options of s2ram in order to determine - by trial and error - the appropriate combination. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.<br />
<br />
However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish [[Suspend to Disk]] , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.<br />
<br />
Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.<br />
<br />
=s2ram=<br />
<br />
The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to [[Suspend to Disk]] . You can find uswsusp in the community repositories.<br />
<br />
Install the package uswsusp. Then try if s2ram works out of the box for your machine:<br />
<br />
# s2ram<br />
<br />
If your machine tries to suspend, then your machine is already whitelisted. You SHOULD be able to suspend and resume properly. Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the next section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the suspend-devel@lists.sourceforge.net, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings, which you can print also with s2ram -i.<br />
<br />
On the contrary, it may happen that s2ram simply refuses to work, telling that your machine is not yet known (''i.e.'' whitelisted) and giving some general purpose identification strings of your machine. In this case, you should try yourself the different tricks provided by s2ram, associating it with the -f (--force) option, which tells s2ram to force the suspension even if your machine is not yet whitelisted. In the best case, s2ram -f is enough: this means that your machine does not require any trick to accomplish a proper suspension cycle. <br />
<br />
In this case (and also in the following cases where one or more tricks are on the contrary required), it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. <br />
<br />
Anyway, if s2ram -f works nice everywhere, then you should do two things: the first allows you to solve your problem for yourself adding your machine to the whitelist in your local s2ram. The other lets the developers of s2ram know that you machine works and whitelist it in the next release of s2ram.<br />
<br />
To add your machine to the local whitelist for s2ram, you need to customize the package from [[ABS]]. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c<br />
<br />
You will see something like this: <br />
<br />
struct machine_entry whitelist[] = {<br />
{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE },<br />
/* Michael Wagner <michael-wagner@gmx.de> */<br />
{ "4MBOL&S", "7521 *", "REV. A0", "", 0 },<br />
/* Alexander Wirt */<br />
...<br />
<br />
Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:<br />
<br />
# s2ram -i<br />
<br />
E.g.:<br />
<br />
sys_vendor = "Acer, inc."<br />
sys_product = "Aspire 1640 "<br />
sys_version = "Not Applicable"<br />
bios_version = "3A05"<br />
<br />
Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine. In this case no tricks were required, so it should be set to 0.<br />
<br />
Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e is prevents makepkg from overwriting your customized whitelist.c). Now your machine should suspend and resume properly with a plain:<br />
<br />
# s2ram<br />
<br />
You can now report you identification strings to the suspend-devel@lists.sourceforge.net mailing list. Please specify always that everything works both from X and from the plain console.<br />
<br />
If on the contrary something goes wrong with s2ram -f either from X or from the console, then some trick is needed. The following command displays a list of the available tricks with the corresponding command line options for s2ram:<br />
<br />
# s2ram -h <br />
<br />
As you can see:<br />
<br />
The following options are only available with --force:<br />
--vbe_save save VBE state before suspending and restore after resume.<br />
--vbe_post VBE POST the graphics card after resume.<br />
--vbe_mode get VBE mode before suspend and set it after resume.<br />
--radeontool turn off the backlight on radeons before suspending.<br />
--pci_save save the PCI config space for the VGA card.<br />
--acpi_sleep <acpi_sleep> set the acpi_sleep parameter before suspend<br />
1=s3_bios, 2=s3_mode, 3=both<br />
<br />
You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you try a working combination, try to reduce it (that is try to see if one of the option is redundant). Always verify that the combination works both from X and from the plain console.<br />
<br />
When you have identified the shortest working combination of options, you should modify accordingly the whitelist.c.diff. Now you should fill also the fifth field with the right tricks separated by |. You can see the strings for the tricks in the whitelist.c.diff itself. Finally report the working combination, together with the identifying strings, to the suspend-devel@list.sourceforge.net mailing list.<br />
<br />
There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it. <br />
<br />
If your problems go away, you should add the NOFB trick in the whitelist.c.diff and report this to the named mailing list.<br />
<br />
Finally, it may happen that no trick lets s2ram works. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script and discussed in the next section of this article.<br />
<br />
For additional documentation about s2ram, look at the<br />
[http://en.opensuse.org/S2ram opensuse page] (but note that some minor aspects are distro-specific).<br />
<br />
=The hibernate-script and suspension to ram=<br />
<br />
The hibernate-script, developed in the field of the tuxonice project for [[Suspend to Disk]], can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.<br />
<br />
You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:<br />
<br />
# hibernate<br />
<br />
Just put the following as the first uncommented line:<br />
<br />
TryMethod ususpend-ram.conf<br />
<br />
However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-ram.conf<br />
<br />
Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.<br />
<br />
The hibernate-script options are exhaustively described in the man page hibernate.conf.<br />
<br />
First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.<br />
<br />
If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed.<br />
<br />
May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:<br />
<br />
The relevant block of options is the following:<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:<br />
<br />
EnableVbetool yes<br />
RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
<br />
Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:<br />
<br />
# vbetool vbestate save > /var/lib/vbetool/vbestate<br />
<br />
The second peculiar trick (very often required!) is to uncomment the following line:<br />
<br />
SwitchToTextMode yes<br />
<br />
The script will switch from X to console before suspension and back to X after a successful resuming.<br />
<br />
Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.<br />
<br />
The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.<br />
<br />
=s2both=<br />
You can also suspend your machine both to disk and to ram. This is documented in [[Suspend to Disk#Combining suspend to disk with suspend to RAM|a specific section of the wiki page about suspension to disk]].</div>Grncdr