Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume

[Mantas Kriaučiūnas]

There are a variety of circumstances which can cause the swap partition UUID to get out of sync with the system configuration, for example:

1. User edits /etc/fstab to specify a different swap partition, either by UUID or by hardcoding the device path
2. User reinitializes their swap partition with a new UUID using mkswap
3. User repartitions their disk and thereby reinitializes the swap partition with a new UUID

If this happens, the system will fail to resume from hibernation because it continues to look for the swap partition as specified in /etc/initramfs-tools/conf.d/resume. Not finding this device, it will continue with normal system startup, as if no hibernation had taken place.

It would be better if the system were more robust in the face of such changes.

[Mantas Kriaučiūnas (mantas)]

This bug couses not working resuming in Baltix GNU/Linux distro, so it should be fixed ASAP in Baltix, at least by adding "dpkg-reconfigure initramfs-tools" in ubuntu-express installer in Baltix 1.4 version. Then I should assign this bug to Baltix "dapper" branch.

[gmlion (gm-l)]

Is the bug still present in newer Ubuntu releases?

[Id2ndR (id2ndr)]

I think it's linked to bug #66637. I still can't resume from hibernation because UUID change each time I reboot my computer. But this was working on edgy (with UUID too !).
/etc/mkinitramfs/conf.d/resume may have changed to /etc/initramfs-tools/conf.d/resume
So I think the bug is still present on feisty.

[Id2ndR (id2ndr)]

I just tried the method described at <https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637/comments/23> and that was working very well for me.

Description of this bug seems to be more a "feature request" than a bug. The bug itself should be #66637.

[Mircea Deaconu (mirceade)]

Yes, this is related to bug #66637. I think this should be set a high priority since it breaks updates (an existing edgy swap partition is not automatically recognized after an update).

[Mircea Deaconu (mirceade)]

I meant "upgrade" not "update".

[Mantas Kriaučiūnas (mantas)]

This bug still presents in latest Ubuntu release (7.10 "Gutsy) - swap partition with hibernation data still isn't detected automatically in initrd :(
If there are a problem with restoring from hibernate Windows operating system displays a menu:
1. "Try to restore from hibernation"
2. "Erase hibernation data and do clean boot"

I think Ubuntu should behave similar.

[Matt Zimmerman (mdz)]

Similar reports can be found at:

http://ubuntuforums.org/archive/index.php/t-456992.html
http://turbulentsky.com/resume-from-hibernate-failed-on-ubuntu.html

[Matt Zimmerman (mdz)]

Another report: https://bugs.edge.launchpad.net/ubuntu/+source/hal/+bug/68258/comments/29

[Matt Zimmerman (mdz)]

Another report: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/361852/comments/30

[Scott James Remnant (Canonical) (canonical-scott)]

This is the kind of bug that cheerfully goes away when we switch to using swap files by default instead of swap partitions, since we save the location of the file when we go down rather than hardcoding it in the boot loader configuration.

[Robbie Williamson (robbiew)]

With plans to migrate to swap files in Karmic, will we still even have this problem?

[Colin Watson (cjwatson)]

Swap partitions will still be supported (upgrades, if nothing else), but
it will become progressively less important.

[Robbie Williamson (robbiew)]

So should we consider putting a fix into Karmic for this situation?

[Paulus (donmatteo)]

This bit me again today. After re-creating the swap partition, waking up from hibernation stops working. I also didn't find a way to update /etc/initramfs-tools/conf.d/resume automatically. At least it's not easily discoverable.

Naturally switching to a swap file would be the favored solution. But for the time being, some other solution should be found.

[Teo (teo1978)]

Hi,

I think I'm experiencing this bug (in 10.04) but I'm not sure the cause is the same.

My laptop went to automatically hibernation because the battery was critically low. It is set to HIBERNATE when battery is critically low, I can see it in the Power Management preferences.

So when I connected it to power and turned it on, it booted AS IF it had been simply shut down. I got no error dialog (I guess there may be error messages in the logs but I am a newbie and don't know where to look for them), it just did a clean boot, and I lost all my unsaved data.

I have a swap partition, but I didn't (intentionally at least) do anything "weird" related to partitions. I simply "used" the system (wrote mails, surfed the web and the like). If something changed anything on the swap partition, it wasn't me.

Is there a way I can check some log file or something to see whether this was related to the issue described here?

I then tried to manually hibernate and resume just to test, I did it twice and the results were:

1) First time I tried to hibernate, and the system HANGED on a black screen with a text cursor on the upper-left corner. No messages, no disk activity, nothing, just stuck. I had to manually turn off the computer by holding the power button.
Obviously at the next boot it didn't resume. It did a clean boot.

2) Second time I could hibernate and resume SUCCESFULLY.

However I can't trust hibernation.

This issue's importance should be raised to CRITICAL as it can cause disastrous DATA LOSS/CORRUPTION

[Tian Bai (tianbai-org)]

+1

I was also bit by this bug these days. The fact that the swap works well makes it very deceptive. I checked BIOS, Grub, Kernel problems, etc. If the rule of "Don't repeat yourself" cannot be obeyed here, a auto-sync mechanism should be put in place.

To those who were trying to resolve the issue: don't forget to run "update-initramfs -k all -u" after updating /etc/initramfs-tools/conf.d/resume with the correct UUID.

[Duncan Clough (duncan-clough)]

I just came across this problem in Maverick.

I adjusted some of the partitions of my hard drive to create bigger swap partition (so hibernate would work all the time) and in the process had to recreate the swap partition. After rebooting with the adjusted partitions hibernation no longer worked - the computer just started up normally instead of resuming from hibernation.

As suggested in comment #4, following the steps at <https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637/comments/23> fixes the problem.

[A Dasgupta (adg)]

See my detailed postings regarding this issue in:

  https://bugs.launchpad.net/initramfs-tools/+bug/923326

.

[Pranav Amrute (chemicalsequence)]

I installed hibernate & next time I reboot my PC with 12.04 LTS it failed to resume. The issue is critical & could be fatal. Please check out my query thread in forums http://ubuntuforums.org/showthread.php?t=1970589

[Dimitri John Ledkov (xnox)]

In 12.04 LTS, hibernate (suspend to disk) has been disabled by default, as it was found to be unreliable, very slow and confusing to have two suspend modes. See bug 812394 for details. If you want to re-enable it, please follow https://help.ubuntu.com/12.04/ubuntu-help/power-hibernate.html

[papukaija (papukaija)]

@Pranov: Please open a new bug for your issue as this one doesn't occur from sowtware changes (eg updating to 12.04).
@Dmitrijs Wrong bug?

[Dimitri John Ledkov (xnox)]

@papukaija in my comment 21, I was trying to suggest @Pranav that 'upgrading to 12.04' disables hibernate. But reading back 'I installed hibernate' suggests that Pranav did re-enable hibernate.

@Pranav: yes, file a new bug I guess.

[Martin Pitt (pitti)]

This is actually still an issue. ubiquity still writes a wrong UUID into /etc/initramfs-tools/conf.d/resume, which causes a 5 second boot delay from the /usr/share/initramfs-tools/scripts/local-premount/resume script as it waits for a swap partition which doesn't exist. I think this comes from ubiquity's ./scripts/plugininstall.py. This is confirmed on at least two saucy computers, one of which was installed from scratch with beta1.

[Martin Pitt (pitti)]

Some speculation: Could it be that ubiquity calls mkswap multiple times, or tries to determine the UUID before calling mkswap?

[Jean-Baptiste Lallement (jibel)]

Here is a bootchart that shows a 5s delay on wait-for-root waiting for a non-existent swap partition.

[Martin Pitt (pitti)]

Would it not be better if we wrote/updated conf.d/resume during update-initramfs, so that it adjusts the initramfs' UUID even if the admin changes the swap partitions? In that script we could also remove conf.d/resume if we detect cryptswap, as resuming from hibernation won't work with cryptswap anyway AFAIK?

[maximilian attems (maks-debian)]

On Mon, Sep 09, 2013 at 09:09:17PM -0000, Martin Pitt wrote:
> Would it not be better if we wrote/updated conf.d/resume during update-
> initramfs, so that it adjusts the initramfs' UUID even if the admin
> changes the swap partitions? In that script we could also remove
> conf.d/resume if we detect cryptswap, as resuming from hibernation won't
> work with cryptswap anyway AFAIK?

It should just be a hook so that update-initramfs calls it everytime
and not a postinstall script that runs only once on install.
Will propose hook script in next 24h.

A bit nasty is the upgrade scenario, but it should not write into /etc,
as it would just write into the initramfs.

Best,

--
maks

[Martin Pitt (pitti)]

> A bit nasty is the upgrade scenario, but it should not write into /etc, as it would just write into the initramfs.

I agree. I think *if* /etc/initramfs-tools/conf.d/resume exists and is valid, it should copy that into the initramfs, otherwise dynamically create one based on the existing swap partition(s) using the ubiquity logic. Then we should drop that code from ubiquity at least for the case when there's only one swap partition. For multiple ones we need to ensure that ubiquity actually writes a valid one. But hibernation has been disabled from the UI many releases ago anyway, so maybe it could just stop being concerned about configuring this altogether?

[maximilian attems (maks-debian)]

On Wed, Sep 11, 2013 at 01:38:26AM -0000, Martin Pitt wrote:
> > A bit nasty is the upgrade scenario, but it should not write into
> /etc, as it would just write into the initramfs.
>
> I agree. I think *if* /etc/initramfs-tools/conf.d/resume exists and is
> valid, it should copy that into the initramfs.

Most of the times initramfs-tools generated that crap config file.

It might be easier to just forget about it, but you have a point
that in the meantime it might be admin set and hence should be checked.

> otherwise dynamically create one based on the existing swap partition(s)
> using the ubiquity logic.

No idea what ubiquity does and what logic you point too, afaik that
config file was allways in Debian written by initramfs-tools preinst.

Could you point to the relevant ubiquity code, please.

[maximilian attems (maks-debian)]

On Wed, Sep 11, 2013 at 01:38:26AM -0000, Martin Pitt wrote:
>
> I agree. I think *if* /etc/initramfs-tools/conf.d/resume exists and is
> valid, it should copy that into the initramfs,

ok on second thought this is easy and right, fixed in initramfs-tools.git
maks/swap branch with 3 commits (might land soonish in master)

> otherwise dynamically create one based on the existing swap partition(s)
> using the ubiquity logic.

this I still don't know? (:

[Dimitri John Ledkov (xnox)]

As ubiquity is using live-cd / preinstalled, initramfs-tools preinst is not run.
Ubiquity simply parses /proc/swaps, finds largest partition and writes out /etc/initramfs-tools/conf.d/resume.
http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py#L835

Thus in install/upgrade/reinstall cases with ubiquity it should all just work correctly. But indeed if one manually modifies/recreates swap partition one must at the moment do the following:
1) adjust /etc/fstab with new UUID
2) adjust /etc/initramfs-tools/conf.d/resume with new UUID
3) update-initramfs -k all -u

[Martin Pitt (pitti)]

Hey Maximilian,

maximilian attems [2013-09-11 7:57 -0000]:
> > otherwise dynamically create one based on the existing swap partition(s)
> > using the ubiquity logic.
>
> No idea what ubiquity does and what logic you point too, afaik that
> config file was allways in Debian written by initramfs-tools preinst.

Our live filesystems are built in a chroot, and don't contain a
pre-made resume file, so the preinst's "am I in a chroot" logic works.

> Could you point to the relevant ubiquity code, please.

That's

  http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py#L883

maximilian attems [2013-09-11 9:56 -0000]:
> On Wed, Sep 11, 2013 at 01:38:26AM -0000, Martin Pitt wrote:
> >
> > I agree. I think *if* /etc/initramfs-tools/conf.d/resume exists and is
> > valid, it should copy that into the initramfs,
>
> ok on second thought this is easy and right, fixed in initramfs-tools.git
> maks/swap branch with 3 commits (might land soonish in master)

Cheers, these look nice. That will avoid the pointless 5 s waiting
during boot. The only issue now is that you can't choose to entirely
disable hibernation by creating an empty file or having no file at
all; not sure how much of an issue that is. Perhaps if the file exists
and is empty that shold indicate "disable resume", and if the file
doesn't exist, "automatic resume"?

[maximilian attems (maks-debian)]

Hey Martin,

On Wed, Sep 11, 2013 at 11:08:14AM -0000, Martin Pitt wrote:
>
> Cheers, these look nice. That will avoid the pointless 5 s waiting
> during boot.

Thanks for the review, will add this info!

> The only issue now is that you can't choose to entirely
> disable hibernation by creating an empty file or having no file at
> all; not sure how much of an issue that is. Perhaps if the file exists
> and is empty that shold indicate "disable resume", and if the file
> doesn't exist, "automatic resume"?

There is the bootparam "noresume", if you add that to your bootloader
command line no resume is attempted. It overrides any RESUME setting.

I'd assume empty RESUME files could only be created by mistake,
whereas the noresume params exists since looong and is also the
corresponding linux parameter (when no initramfs is at play).

Best,

--
maks

[maximilian attems (maks-debian)]

On Wed, Sep 11, 2013 at 10:52:28AM -0000, Dmitrijs Ledkovs wrote:
> As ubiquity is using live-cd / preinstalled, initramfs-tools preinst is not run.
> Ubiquity simply parses /proc/swaps, finds largest partition and writes out /etc/initramfs-tools/conf.d/resume.
> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py#L835

Thank you for this valuable input, refixed to follow the logic of the
largest partition! (Still hiding in maks/swap but expect it to hit master
by tommorrow)

> Thus in install/upgrade/reinstall cases with ubiquity it should all just work correctly. But indeed if one manually modifies/recreates swap partition one must at the moment do the following:
> 1) adjust /etc/fstab with new UUID
> 2) adjust /etc/initramfs-tools/conf.d/resume with new UUID
> 3) update-initramfs -k all -u

With fixed initramfs-tools 2) is no longer necessary and 3) will happen
anyway sooner or later in the sense that newer initramfs get generated
and updated (of course not all of them :).

[Uriel Tunn (u2n)]

Pesky bug has been around since 2006 and it's still here!

Workaround in post 35 (https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/50437/comments/35) is not difficult to find -- and it's always refreshing to learn something more about the system -- but until a real fix can be applied, just a small note in fstab would do:

"If swap is edited manually, /etc/initramfs-tools/conf.d/resume must be updated with the same UUID, then: sudo update-initramfs -u"

[Rarylson Freitas (rarylson)]

The workaround in post 35 (https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/50437/comments/35) works, but there's a more simple workaround to get the same result:

1) Update your /etc/fstab with your new SWAP partition (or partitions);
2) /var/lib/dpkg/info/initramfs-tools.preinst install
3) update-initramfs -k all -u

The only improvement is in step 2. The proposed command automatically updates the UUID of the RESUME var.

[Andy Whitcroft (apw)]

This should have been fixed by the commit below:

  commit fef37d599aae9f2f3fc6808b46e901a7a4267c76
  Author: maximilian attems <email address hidden>
  Date: Wed Sep 11 00:40:10 2013 +0200

    hooks: Add resume hook instead of hardcoding RESUME once on preinst

This was part of debian v0.114 and therefore part of v0.120ubuntu1.