Ubuntu 8.04 Hardy Heron Hibernate/Resume on Dell Studio 1735

Used:


  • uname -r - to verify kernel version

  • sudo fdisk -l - to check all partitions

  • mount - to see what was mounted

  • more /etc/fstab - to get filesystem and mount points

  • ls /dev/disk/by-uuid -alh - to get a list of UUIDs



Edited /boot/grub/menu.lst per instructions below

Got Hibernate/Resume working using:

zcat Says:
September 14th, 2008 at 4:32 pm

What I did was three things to get hibernate to work with Ubuntu Hardy 2.6.24.21 ...
1. change platform to shutdown
>sudo gedit /usr/lib/pm-utils/functions
change from “platform” to “shutdown”

2. whitelist ptyq4
>sudo gedit /etc/default/acpi-support:
# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES=”em8300 yenta_socket”
#
# Note that network cards and USB controllers will automatically be unloaded
# unless they’re listed in MODULES_WHITELIST
MODULES=”ptyq4″

3. Changes grub to point to swap on resume
>sudo gedit /boot/grub/menu.lst
UUID (for your swap partition) and nosplash making it look like this:
title Ubuntu 8.04.1, kernel 2.6.24-21-generic
root (hd0,4)
kernel /boot/vmlinuz-2.6.24-21-generic root=UUID=5d6b95b0-19cb-4753-856f-663838a2bc6d ro quiet nosplash resume=UUID=fb7c67e6-ac30-42f7-8df5-cf127eab9013
initrd /boot/initrd.img-2.6.24-21-generic
quiet



And followed:


Re: Hardy - Hibernate Restarting?
Check your /boot/grub/menu.lst - do you have kernel lines like this?

Code:

kernel /boot/vmlinuz-2.6.24-19-386 root=UUID=d5e0406e-f8c8-4a5a-aa0b-dcaa24495422 ro quiet nosplash resume=UUID=971efceb-6ef7-46c3-8b17-6aedffd70a25

It seems that you need resume= to make resume from hibernate work in Hardy. This tells the kernel where the saved image is, and the UUID= tells it to look in your swap partition. The UUID of your swap partition should be listed in your /etc/fstab. If not, I think you can use resume=/dev/$your_swap_partition

The resume= was missing after my upgrade from Dapper. To fix...

* Become root with
Code:

sudo -s

* Backup your /boot/grub/menu.lst in case you screw it up

* Get the UUID of your swap partition from /etc/fstab or by looking at the target of the symlinks in /dev/disk/by-uuid/
* Open /boot/grub/menu.lst in your favourite editor
* Find the line
Code:

## ## Start Default Options ##

then look for a following
Code:

# defoptions= .....

line.
* Edit that to look like
Code:

# defoptions=quiet nosplash resume=UUID=the-hex-uuid-of-your-swap

Note the leading hash - see the explanation and warnings in menu.lst.
* Save the file and quit the editor
* Run
Code:

update-grub

If you get any complaints from it, check that you've changed only the # defoptions line.
* Check that update-grub has added resume=... options to all "kernel" lines in menu.lst
* Exit your root shell with
Code:

exit

* Hibernate your computer
* Wait 10 seconds (or a day, or a week, or ...) and restart your computer
* Hopefully you will see a boot message like
"kinit: trying to resume from...", and after the disk stops spinning (and maybe some strange colours and patterns on your screen) you should have a resumed session (in my case, KDE locks the screen and I type my password to unlock).


The following links are other things I tried which didn't work before doing the above which worked like a charm:

Tried this, but it didn't work
Also tried this and it also didn't work

Comments

Post a Comment

Popular posts from this blog

Sites, Newsletters, and Blogs

BLOGS Java.net Weblogs Martin Fowler's blog Paul Graham Ruminations of a Programmer Form Follows Function Newsletters Core Java Tech Tips Enterprise Java Tech Tips JavaSpecialists.EU TheServerSide.com Sites Java.net Today Hot Java Sites CSS Zen Garden Evernote Hacker News Pragmatic Programmer
Read more

Oracle JDBC ReadTimeout QueryTimeout

If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection. If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL  which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table  or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE. If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will atte...
Read more

Locks held on Oracle for hours after sessions abnormally terminated by node failure

If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc. This was easily reproduced by creating a  process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...
Read more