[TuxOnIce-users] Strange hibernate/resume behaviour in Fedora 17

Aaron Sloman A.Sloman at cs.bham.ac.uk
Wed Oct 24 00:32:55 UTC 2012


Using tuxonice 3.6.2-4_1.cubbi_tuxonice.fc17.i686 (after some help from
Matthias Hensler) I now at last have hibernate/resume working apparently
very reliably, but only with 'UseTuxOnIce no" in hibernate.conf.

I am posting this in the hope that my evidence will allow someone to
finally fix resume from hibernate for my hardware. There's also a minor
problem that tuxonice kernels take a long time to recognise my SD
card-reader after boot or resume, unlike ordinary fedora kernels, but
that's a minor problem.


I've used tuxonice and its precursor for many years to allow me to
preserve state on laptop and desktop. However in June 2010, I started
using a Dell Latitude E6410, laptop computer with intel core i5 (4-cpus)
and integrated intel graphics.

 From the start I had trouble with the graphics (as did many others).
After various partial solutions I managed to get most aspects of linux
working in fedora 15, from early 2011.

But tuxonice hibernate did not work. Sometimes hibernation would not
complete, but if it did complete, resume did not work: rebooting instead
of resuming. So, after experimenting in vain with removing modules, I
stopped using tuxonice since standard fedora kernels seemed a bit more
reliable for me.

In 2012, after I had converted to Fedora 16, hibernate was made to work
reliably: the earlier hibernate failures were apparently connected with
use of multi-threading in the compress phase. This was fixed by  Bojan
Smojver (in Kernel 3.3.1-3.fc16.i686 I think).

But resume was still broken: sometimes it succeeded and sometimes not.
Eventually I found that it would resume reliably if I added a boot
parameter in grub.cfg, for resume only: acpi=off.

I switched to Fedora 17 in August, hoping for improvement, but resume
still failed without acpi=off.

Later I found that the more lightweight boot option, maxcpus=1, instead
of acpi=off, allowed resume after hibernate to work totally reliably
both on the laptop running F17 with various kernels, and also on my
desktop PC (also Intel core i5 with intel graphics, using kernel
3.3.7-1.fc16.i686) running F16.
'uptime' on the PC now gives: 'up 137 days', which includes far more
hibernate/resume cycles than days.

However using that mechanism required me to make an edited copy of
grub.cfg after every kernel update, and to use a special script to swap
versions of grub.cfg before and after invoking pm-hibernate, as
described here:


So I set up this bugreport:

    Why do I need maxcpus=1 to resume from pm-hibernate in 32-bit Fedora 16
    on Viglen Desktop PC, Fedora 17 on Dell E6410 laptop, both with
    intel core i5 cpu, intel graphic

As described there, with help from Bojan Smojver I managed to falsify a
hunch that the bug was related to multi-threading during decompression,
since forcing use of a single thread during decompression did not stop
resume randomly crashing after expansion of saved image.

I then thought I should again try the latest version of tuxonice, in
case the resume bug had been fixed for tuxonice. So I did some tests
(after Matthias Hensler had installed a bug-fix for dracut-tuxonice to
enable it to cope with UUID= formats for root partition in grub.cfg)
but again I found that hibernate worked perfectly, but resume never
completed, using  hibernate-tuxonice, and this kernel

I tried using pm-hibernate with that kernel: it hibernated, but would
not resume.

So I tried going back to maxcpus=1, still required for the non-tuxonice
kernel 3.6.2-4.fc17.i686 to resume reliably from pm-hibernate.

However, inserting that in grub.cfg for resume did not allow resume from
hibernate to complete.

Solution (sort of):

I then tried editing /etc/conf/tuxonice.config and found that inserting
'UseTuxOnIce no' worked!

I lost the nice tuxonice semi-graphical interface and instead had the
normal printout of percentages during compression and decompression, but
resume seems to work reliably using that mixture.

This suggests that some relatively minor, though possibly obscure change
to the resume code in hibernate-tuxonice could make resume work normally
without setting 'UseTuxOnIce no'.

I now seem to have a totally usable version of hibernate working on the
Dell E6410, without requiring me to edit grub.cfg for booting after
hibernate. It requires one edit in hibernate.conf, after installation of

But it would be better if the system could be fixed to work properly
with 'hibernate' and the normal defaults.

Perhaps someone reading this will be able to do it?


I am grateful to Matthias Hensler for help provided so far (and of
course to Nigel and others involved).

The kernel and tuxonice tools I am now using are all on Matthias'
repository for Fedora users:


Aaron Sloman

More information about the TuxOnIce-users mailing list