hibernate kit for TC

[netnomad]

that would be really a great piece of work that you could do!
especially the usbstick-configuration:
you have to know that i poweruse multibootiso-usbsticks that run on almost every kind of hardware.
it's so easy to be mobile and stay connected...
it's very lean but highly extendable... as you know, tinycore provides the best environment we can expect.
the only thing i really need is your hibernate stuff,
so you will have a heavy tester and delighted user, but for me the usbstick configuration is my world,
easy to clone and copy, easy to optimize and analyze, lean and clean.

[dentonlt]

USB Stick boot/hibernate/resume testing: So far, not so good - it "almost" works on my setup.

I've re-discovered that the resume binary -requires- a linux swap partition.

If I boot from USB (sdb1) but store my hibernate image on my hard drive (sda3), resume works fine (TC boots from sdb1, finds the image on sda3). I don't think that's all that useful, though ...

I'm trying to get a pure USB hibernate going. Now I'm using something like:
- hibernate patch 4.0.1
- grub2
- 1gb USB, 2 partitions (~ 500mb EXT4 + ~ 500MB linux swap)

I've done 15 or so tests with various kernel args, and nothing seems to work. Many successful hibernates (that's the easy part), but only one good resume. Unfortunately, that happened when I told the resume binary to use a UUID; the binary choked on boot and then asked for a device path (/dev/sdb2). Then it loaded the image fine (whoo hoo!). I can't replicate that without forcing the binary to err and ask for input, though.

Currently on:
- suspend conf: resume device = /dev/sdb2
- kernel args: resume=sdb2, tce=sdb1, waitusb= a long time

In short, it doesn't work yet ... Still working. I don't think I'll be able to finish this up today - other work to be doing. I'd say probability is better than 50%, though, depending up on the hardware.

[dentonlt]

Ok - I'm barking up the wrong tree.

inittab runs the resume binary before tc-config, so kernel args are irrelevant. I think the problem is that the USB isn't having enough time to wake up. I'll have to wrap the resume binary in a script: wait for the USB (either parse the kernel args or just wait a bit), and then run the binary.

Gotta try it later. Let me know if you get ambitious and do it yourself.
DLT

[dentonlt]

Good news - I've got a working USB stick that hibernates to itself!

First, I'll warn that this may eat everything you own ... so be careful.

In addition to all the normal hibernate stuff, this requires a USB Stick with two partitions - one must be a substantial linux-swap for the hibernate image.

To avoid the USB wait problem, I use a script to wait for the resume device (poll blkid). It should break if the device doesn't showup within the waitusb time (so ... 5 seconds for waitusb=5, etc.).

Other problems: the hibernate image will probably get destroyed if another OS/Distro allocates a swap file on the same partition as the hibernate image. I have no idea how to get around that one.

This works for me on base/norestore 4.0.1. I've not yet tested with extensions, or with other mounted devices. If you're going to use this (anyone!), be careful.

DLT

[ 20111015 EDIT: I suggest against using this one - get TC 4.0.2 and use the 4.0.2 patch. This fixes an error that allows an infinite loop while waiting for the hibernate/resume/swap device ]

[netnomad]

wow, unbelievable how fast you develop, keep on hacking...

first, could you short explain, what i should do with your patch!
i don't care to test, cause i work with automated backups and i like to archive every single step, perhaps there will be sometimes someone who will package rsnapshot (apple's time machine is just a fancy rsnapshot in a trendy wrapper).

this usbwait is known, the prefered way to mount should be per label.

the swap that stores the hibernated image is usually not protected:
i like to install different versions and flavors on several partitions of a hdd and use the same swap,
and i can confirm your expectation and probably there is no easy solution to protect the last resume-image.
but i noticed that my bios is locked while there is a resume-image in my encrypted swap,
that means i'm not able to enter the bios-configuration while there is a resume-image stored.

it would be kind of you if you give me some hints how to use your patch.
thank you for your help.

[dentonlt]

If you'd like to try it out
- get a blank/free USB stick (~ 1gb should be more than adequate)
- get gparted from the repository. BEWARE WITH GPARTED - don't partition the wrong drive! On a 1gb USB I used 500mb ext4, 500mb linux swap
- install grub2 onto your USB stick - grub2 extension in the repository. Again, BE CAREFUL!
- download the hibernate patch and follow the README instructions. You'll replace the stock tinycore.gz with the patched tinycore-hibernate.gz.
- make sure your grub.cfg uses the right initrd (tinycore-hibernate.gz)
- boot your usb stick
- tce-load suspend.tcz (and all its deps)
- sudo s2disk to hibernate - that should power down. Boot to see if the resume works.

Hope all this helps - it's a fairly long process, but it worked here.
Not fast at the "hacking", I'm afraid - I just had some time to work yesterday.

[netnomad]

hi dentonit,

i downloaded you script and made some experiences...

first, i think your script is optimized for persistence installations...so in mount mode some problems occur.
i use mount mode: tcz/install, that means the packages are mounted-loop under /tmp/tcloop.
f.e. my suspend package is installed under /tmp/tcloop/suspend and all the "real" destinations are just links!
that means that /usr/local/lib/suspend/resume is just a link
that points to /tmp/tcloop/suspend/usr/local/lib/suspend/resume!
so it doesn't work to copy /usr/local/lib/suspend/resume to somewhere, in this case a real file can only be copied,
if you take the /tmp/tcloop/suspend/usr/local/lib/suspend/resume.

as described in the readme.txt, i created a directory that contains the different compilation files.
some of your scripts need a ./ to work, perhaps for the reason that this directory is not in the predefined paths.
so i have to correct some script-command with a leasing ./.

my main problem is that i didn't find the file resume.sh, i found resume, but resume.sh wasn't found by the script.

in the moment i try to find a configuration that resumes over a device-name, f.e. /dev/sdb4,
but i would prefer to use UUID.
i tried to label my swap-file, but i guess that tune2fs cannot label a swap file,
can anyone confirm this?

i will search further but will appreciate every help from your side.
thank you for your help.

[cast-fish]

------------------------------------------------------------------------------------------

Your hibernation attempts take a few steps...... and also need the suspend.tcz extension.

Is there any chance that you can make your patch into a .tcz extension for the TCL 4.0.1 app store?

AS it stands right now.....suspend.tcz....does not work for Hibernation. (infact, the info mentions that it was not tested for hibernation....meaning it doesn't work!...?..)
As it's name suggests....it's for "suspend" and not for "hibernation". So that figures.

Thanks

V.

[cast-fish]

on the subject of suspend...

my laptops all behave different....

they tend to NOT like particular pen drives for suspend...but certain other pens will work fine.

Also the suspend scenarios are weird.

If i send machine "A" into suspend it's a success....and all
things power off. Then about 5 minutes later the pen drive will "light up".
Then i try to resume out of suspend, sometimes it works....sometimes not.

Also with laptop "A" i can't suspend TWICE in a row.....it has only ever done ONE correct recovery
from suspend....

When i say "correct". I mean it wakes up to the tcl desktop and all drive labeling and mounts
are correct. It's a usable system.

The laptop "B" is totally fine with suspend...it works all the time because it's using /tce on
a hard drive and swap on a hard drive. It will suspend and resume numerous times no problem.

Conclusion?.....success with suspend can be random. Certain pen drives may or may not
work with certain laptops and suspend.  The laptop also plays a part. They also behave
different with regard to suspend.

V.

[dentonlt]

netnomad: I really should have tested that latest script with base/norestore before posting. Sorry about that. You're right, I at least needed to add a couple of ./ for the scripts called by patch-hibernate. I'll "patch" that and repost!

i use mount mode: tcz/install, that means the packages are mounted-loop under /tmp/tcloop.
f.e. my suspend package is installed under /tmp/tcloop/suspend and all the "real" destinations are just links!
that means that /usr/local/lib/suspend/resume is just a link
that points to /tmp/tcloop/suspend/usr/local/lib/suspend/resume!
so it doesn't work to copy /usr/local/lib/suspend/resume to somewhere, in this case a real file can only be copied,
if you take the /tmp/tcloop/suspend/usr/local/lib/suspend/resume.

Re that one ... I don't have this problem (!). My suspend extension is installed the same way (usr/local/lib/suspend/resume is a link), but I get the actual binary when I cp the link from /usr/... . I -did- test that one on base/norestore, so I'm certain it should work. Are you using the coreutils extension, or maybe have you changed .ashrc?? Those are the only possible differences I can think of.

I share this problem, though:

in the moment i try to find a configuration that resumes over a device-name, f.e. /dev/sdb4,
but i would prefer to use UUID.

AFAIK, uswsusp (all of the binaries in suspend.tcz) operates on /dev/ entries, not on UUIDs. I haven't browsed the code, but I don't think suspend or hibernate/resume to UUID is going to happen without major surgery.

HTH! In short, were you able to get hibernate going at all??

[dentonlt]

Hi, castfish -

Your hibernation attempts take a few steps...... and also need the suspend.tcz extension.

Yep - Need the uswsusp binaries. Kudos to juanito for that package.

Is there any chance that you can make your patch into a .tcz extension for the TCL 4.0.1 app store?

AS it stands right now.....suspend.tcz....does not work for Hibernation. (infact, the info mentions that it was not tested for hibernation....meaning it doesn't work!...?..)

These kind of go together: I probably won't submit a "hibernate" extension because an extension can't really provide hibernation. Currently, the stock startup script TC (/etc/init.d/tc-config) does not support hibernation, and there isn't a resume binary in tinycore.gz. An extension can't put them there - you have to patch the former and unpack/edit/pack the latter.

Conclusion?.....success with suspend can be random. Certain pen drives may or may not
work with certain laptops and suspend.  The laptop also plays a part. They also behave
different with regard to suspend.

I think that applies to hibernation, too. I feel pretty fortunate - stock TC + suspend extension works well for me. After patching, stock + hibernate works, too, including the wakeup alarm! Like many things, it didn't all work right out of the box, though - it took some experimenting.

[cast-fish]

Hello,

oh right...i see....

so one would need to apply your patch as per the instructions in this thread.

My earlier comments about "suspend" forgot to mention that laptop "a" lacks
a hard drive....so tcl 4.0.1 is on a pen drive and the swap partition is on the same
pen.

Laptop "b" is a CD boot of tc 4.0.1 and uses a hard drive for /tce and for the swap partition....

so ye....perhaps if both laptops were hard drives all the way then suspend would be fine on both

i did try "hibernate" via the "suspend.tcz" but i only over got it to create the hibernate image to a pen drive.....it never woke up from hibernate.

I never tried "hibernate" with the hard drive laptop and "suspend.tcz"

V.

[dentonlt]

Updated to 4.0.2. Fixes:
* check args to avoid infinite loop in resume.sh [argh ...]
* support tce-load from patch script
* patch script checks to see suspend and advcomp extensions are loaded

Hibernate-to-USB is still not fully tested, although it works on my own hardware.

[tinypoodle]

i tried to label my swap-file, but i guess that tune2fs cannot label a swap file,
can anyone confirm this?

You need to set the

Code: [Select]

resume offset = <value>parameter, where <value> can be obtained with

Code: [Select]

swap-offset <file_name>

[gerald_clark]

~$ mkswap
BusyBox v1.20.2 (2012-08-07 01:31:01 UTC) multi-call binary.

Usage: mkswap [-L LBL] BLOCKDEV [KBYTES]

Prepare BLOCKDEV to be used as swap partition

        -L LBL  Label