upgraded kernel from 2.30 to 2.32: resume reboots computer
 

hi forum,

few days ago, I upgraded my debian kernel from 2.30 to 2.6.32-5-686. I always stop my computer with hibernate from console. After powering on, it normally resumed the resume image. Until the upgrade.

Now I first get a grub menu (as I did always), the resume image is recognized, the screen turns black (as resume does) and ..... the computer reboots. I get the grub menu, the console says 'kinit: no resume image, doing normal boot' and the normal boot procedure continues.

I have googled a lot on this issue, but I cannot find a clue which fixes this.

/etc/initramfs-tools/conf.d/resume consists of the lines

# RESUME=/dev/sda3
RESUME='UUID=7800032f-3308-4ff5-8032-abf612d19594'

/etc/default/grub contains the line
GRUB_CMDLINE_LINUX="resume='UUID=7800032f-3308-4ff5-8032-abf612d19594'"

(tried without the single quotes as well, but without result).

The output of fdisk:

$ sudo fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9b5d9b5d

Device Boot Start End Blocks Id System
/dev/sda1 * 1 2612 20980858+ 7 HPFS/NTFS
/dev/sda2 2613 3220 4883760 83 Linux
/dev/sda3 3221 3463 1951897+ 82 Linux swap / Solaris
/dev/sda4 3464 9729 50331645 8e Linux LVM

Looking at /var/log/hibernate.log, I see no strange things:

Starting suspend at Thu Oct 13 08:40:28 CEST 2011
hibernate: [01] Executing CheckLastResume ...
hibernate: [01] Executing CheckRunlevel ...
hibernate: [01] Executing LockFileGet ...
hibernate: [01] Executing NewKernelFileCheck ...
hibernate: [10] Executing EnsureSysfsPowerStateCapable ...
hibernate: [11] Executing XHacksSuspendHook1 ...
hibernate: [59] Executing RemountXFSBootRO ...
hibernate: [89] Executing SaveKernelModprobe ...
hibernate: [91] Executing ModulesUnloadBlacklist ...
hibernate: [91] Executing ModulesUnloadBlacklist ...
hibernate: [95] Executing XHacksSuspendHook2 ...
hibernate: [98] Executing CheckRunlevel ...
hibernate: [99] Executing DoSysfsPowerStateSuspend ...
hibernate: Activating sysfs power state disk ...

dmesg does mention an incident:
[ 2.177346] PM: Starting manual resume from disk
[ 2.177353] PM: Resume from partition 8:3
[ 2.177356] PM: Checking hibernation image.
[ 2.177551] PM: Error -22 checking image file
[ 2.177554] PM: Resume from disk failed.

But this can be a message that is generated during the second boot (after restart that is initiated by resume), I'm not sure.

Does anybody have an idea what I can do to make it work again?

thanks in advance, Ruud

Have you installed any of the recommends? http://packages.debian.org/stable/li...e-2.6.32-5-686

yes, all of them. I upgraded the kernel AND the recommends to the latest version, but that didn't change the behavior.

Once in a while, the resume IS successful. Like tomorrow morning. I am looking for a pattern. Maybe it depends on whether X is running. When I hibernated last time, I closed X before doing that. After that, I tried hibernating with X running (for me the only reason for hibernating). The resume restarted the computer...

regards, Ruud

There are some confusing version numbers in this post. Kernel version 2.30? or 2.6.30 perhaps? (latter seems more likely)
Did you update-initramfs after installing new kernel? Were both kernels stock Debian kernels, or did you build either of them
your self? What xserver are you using? What Debian release are you running? If you add more info, it will be much easier to help.

I've found both of these pages to be helpful, though I'm a bit stymied why the Debian one has stuff on lenny and wheezy, but not squeeze.

http://wiki.debian.org/Suspend
https://wiki.archlinux.org/index.php...bernate-script

Regards,
John

You really need to update move often. The 2.6.30 kernel was released in 2009 and dates back to when squeeze was still in testing. As your upgrade pulled in 2.6.32-5 it's probably safe to assume that your main repo is tracking squeeze rather than testing, but other repos could still be tracking testing, to be sure post the output

upgraded kernel from 2.6.30 to 2.6.32: resume reboots computer
 

hi John and caravel,

thank you for your replies.

John is right with his assumption I meant 2.6.30 and 2.6.32; I changed the thread title.

Did you update-initramfs after installing new kernel? Were both kernels stock Debian kernels, or did you build either of them
your self? What xserver are you using? What Debian release are you running? If you add more info, it will be much easier to help.

I did update-iniramfs. The new kernel (2.6.32) is a stock kernel. Installed it with dselect.
I remember that I older one was a stock kernel, but it may be that I have rebuild it.
xserver (xserver-xorg) is 1:7.3+19.

You really need to update move often. The 2.6.30 kernel was released in 2009 and dates back to when squeeze was still in testing. As your upgrade pulled in 2.6.32-5 it's probably safe to assume that your main repo is tracking squeeze rather than testing, but other repos could still be tracking testing, to be sure post the output

Yes. I do update often, but I select the package manually, to be sure not to be surprised by kernel or xorg updates. They sometimes drive me crazy, leaving me behind with a system that does not work. I can not afford that.

sources.list contains:

I included the first comment line, because I commented that out recently. In other words: they two lines were BOTH active. I have no idea if this introduced its own problems, but this is how it is.

regards, Ruud

Your xorg version dates back to lenny which is now oldstable - so it appears you have a mix of lenny and some out of date squeeze (stable) packages. Depending on when you disabled the testing repo, you could also have pulled in wheezy (testing) packages.

Adding the testing repo was a bad idea from the start as it's resulted in an unstable system - testing and unstable binary repos should almost never be mixed with stable. Your sources are also incomplete as you are lacking the rather important security repo. Tracking the stable repo is also a bad idea, as when a new stable is released your system will try to upgrade itself, as has happened here.

You have a few options, but in all cases you will need to back up you important data as whatever you do at this stage it could go wrong.

1) You can fully upgrade to squeeze, this should sort out most of your problems and even if it doesn't, it's a good starting point. To upgrade properly you will need to read the release notes.

2) A clean reinstall of squeeze

3) Change your sources to track lenny (oldstable) and attempt to downgrade all packages back to Lenny. Not for the faint hearted and no guarantees it will work. (not recommended)

Whatever you decide, your sources need sorting out, e.g.

Substitute all incidences of "squeeze" with "lenny" if you're going to try and downgrade to oldstable.

thanks for the advice. I consider the first option. Reluctantly, because my system is OK now, apart from the hibernate problems.

But I understand I have created a mess and you have right I should start with a good starting point.

If I change my sources.list so that it contains the squeezy entries you mentioned, and do a update, will the testing stuff I installed in the past period be downgraded? Or do I have to do that later on manually?

regards, Ruud

You would only find out about the testing/wheezy stuff once you've tied to upgrade. If you have the squeeze kernel installed and running you need to replace your sources with the one I posted, reboot into the 2.6.32 kernel and

That may complain that packages need to be removed, this is often unavoidable, probably more so in this case, but post up full outputs in code tags when/if it occurs.

Once the upgrade is complete you can try some apt pinning to force every installed wheezy package to downgrade to the squeeze version. From what you've posted, i.e. the xorg version, it looks like most of the system is still at oldstable versions.

hi Caravel,

it took some time to reply. I have changed my sources.list, and in dselect, after upgrading the list I have upgraded the packages in batches so that they are almost all up to date.
In the second batch I have upgraded the xorg-packages, which seemed to resolve the problem I started this thread for (resume works again).
After doing the most of the upgrades, I had a xmodmap problem, which is solved now and an iceweasel problem. Which made replying impossible.

That is fixed now.

I even did an apt-get clean and apt-get update. The first gave no output.
Now is my last question: is it necessary to do the dist-upgrade as well or do you think my dselect actions have made this unnecessary. I don't know what this does and I don't want to create more problems now everything works fine again....

regards, Ruud

dselect is a relic I would advise you to stop using it, you do need to run "apt-get dist-upgrade". If it comes out with some worrying output, just answer no and post it up here.

//edit:
An ncurses based package manager is aptitude - which can also be used from the command line like apt-get

A gtk based package manager for x is synaptic

But, debian should always be upgraded between releases using apt-get.

hi again,

This is the output of the command

This is exactly what I saw in dselect. Do you think I need to take further actions?

regards, Ruud

What is the output of

hi caravel,

it outputs the following:

Thank you for taking all me through this.

regards, Ruud

Post outputs

If those produce no output

Then ignore the libs for now, but try to simulate an upgrade of some of the other kept back packages to see what it spits out

If that doesn't produce anything worrying, remove -s and go ahead and upgrade them.

Then run
If it looks ok go ahead, otherwise post output.

If all is well finally let aptitude have a look at it

Again go ahead with those if it's not trying to remove half of your system. If aptitude wants to autoremove those same few packages you listed there, let it get on with it, but take note of what it's removing.

If after all that you still have held back libs, aptitude install them all.

Once done you will be running the stable release, so there's no reason not to keep up to date. Stable only gets security patches and should not break.