No /etc/mkinitramfs/conf.d/resume after ubiquity installation

Bug #42299 reported by Ryan Hurley
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Adam Conrad
ubiquity (Ubuntu)
Fix Released
Colin Watson
update-manager (Ubuntu)

Bug Description

EDIT: I almost forgot to mention, I'm running a clean, up-to-date install of Dapper Beta2 installed from the disk last night. acpi version is 0.09

In trying to get Hibernation to work on my laptop, (Compaq Presario v2402us) I have discovered that hibernating corrupts my swap partition.

I have verified this using gparted on the live disk- before attempting to hibernate, the swap partition is on /dev/hda2, and recognized by both my normal Ubuntu system and the live disk. But, after a hibernation attempt, (which fails- more on that in a second) neither the normal system or the live disk can see /dev/hda2 as anything more than "unknown."
In my system, "sudo swapon -a" returns:
swapon: /dev/hda2: Invalid argument

To get my swap partition back, I need to reformat it wth the live CD partitioner.

Specifically, when I press the "Hibernate" key In "System -> Log out," the computer shuts down as if hibernation is going to work. The screen blanks, and after 30-45 seconds of continuous HDD usage, the computer powers down as well. But, when it starts up again, it starts up without even mentioning hibernation- no errors, nothing at all. When the normal system is reached, swap space cannot be accessed, and /dev/hda2 is corrupted.

Attached to this bug are my Syslog, /etc/default/acpi-support, and /var/log/acpid files in the Logs.bz2 file.

Revision history for this message
Ryan Hurley (aeromechie) wrote : Logs.bz2

Compilation of the applicable log files and setup files.

description: updated
Revision history for this message
Nick_Hill (nick-nickhill) wrote : Re: Hibernating corrupts swap partition

I am having a similar problem with a desktop machine. I resolved the problem by appending resume=/dev/hda5 to the kernel boot line in


Your swap partition may not be /dev/hda5. Change it to whatever your swap partition is. You can find out by looking in /etc/fstab.

The entry appears to be missing on both a clean install and on installing a new kernel.

I suppose this is a problem with the kernel package for omitting this boot line entry.

Changed in acpi-support:
status: Unconfirmed → Confirmed
Revision history for this message
Matthew Garrett (mjg59) wrote :

Colin, this is a duplicate but I'm afraid I can't find the original (ubiquity installs not generating the correct resume line in initramfs-tools). Can you close if this is already fixed?

Revision history for this message
Nick_Hill (nick-nickhill) wrote :

More specifically, the hibernate function works by writing a memory image to the swap partition. When the kernel boots, if there is a resume= entry in the boot arguments, the kernel loads the memory image, then restores the swap partition status.

Because the resume=<device> entry is missing, the kernel does not see the hibernation data. As the swapfile no longer has the correct signature, the swap partition will never be used again (Unless you do mkswap device (eg mkswap /dev/hda5))

I will re-assign this as major as it both undermines system functionality by permanently disabling swapfile, could cause data loss through suspended programs data never being written, and has an environmental impact as the hibernate function can enable the user to turn the computer off where otherwise it must be left turned on.

Revision history for this message
Matthew Garrett (mjg59) wrote :

No, the lack of resume= is not the problem - that's handled by the initramfs. The bug is that the initramfs config is not being written on install. I also believe it to be fixed, but can't confirm that right now.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Could the reason be that the (already existing) swap partition is busy during the installation, see bug #42159 ?

Revision history for this message
Nick_Hill (nick-nickhill) wrote :

No, in this instance, the swap partition is perfectly usable until the user first tries hibernating.

Because the machine is never taken out of hibernation (the machine boots normally next time (after fsck) instead of coming out of hibernation) the swap partition forever has the hibernation image in it.

This specific symptom is fixed by appending resume=<swap partition> to the kernel boot line.

Revision history for this message
Nick_Hill (nick-nickhill) wrote :

Given that a machine can have multiple swap partitions and files, it is important to know that the machine will try to resume from the same swap partition or file where the hibernation image was saved.

It is therefore advisable that the same code / interface which informs the hibernation mechanism where to save the image to also determines where the kernel resumes from. I am not sure whether the current implementation does this. Maybe something for the longer term.

Given that in kernel 2.6 there is no performance penalty using swap files as opposed to swap partitions (according to Ted Ts'o), any possible hibernation dependency on a swap partition should be cut.

In the longer term, we therefore need a more flexible approach to informing the booting kernel whether it is coming out of hibernation, and where it can find the hibernation image.

Perhaps a module associated with init should be involved in this.
1) Before hibernation, signal init to return a location where the hibernation mechanism should write the hibernation data. Init can make it's own arrangements. location passed to hibernation mechanism, and control passed to hibernation mechanism.
2) At boot, init checks file system flags or whatever to determine whether it is waking from hibernation. if so, passes the location of the hibernation data to the hibernation mechanism. Passes control to hibernation mechanism.
3) After wake from hibernation, hibernation code signals init that system woken from hibernation. Init can then run scripts to restore stateful hardware and remove any flags init uses to determine that it is to wake from hibernation.

This system has several advantages:
1) No swap file or partition necessary
2) Flexibility- separate hibernation files can be used if necessary. Init can make any necessary decision how to handle the hibernation request.
3) Can eliminate uncertainty when using multiple swap partitions and files.
4) Removes dependency on kernel boot arguments. Prevents system brakage when swap partitions are re-assigned and removes need to tightly integrate boot managers lilo/ grub with hibernation system.

Makes system slightly more complex; Init will need additional configuration parameters to determine how and where hibernation occurs.

Revision history for this message
Matt Zimmerman (mdz) wrote :

Please don't use this bug report to discuss proposals for changing how hibernation works, but only the problem at hand.

Revision history for this message
Matt Zimmerman (mdz) wrote :

Just confirmed in a fresh ubiquity install on amd64; no /etc/mkinitramfs/conf.d/resume was written.

As I noted in bug #40609, my guess is that swap isn't activated at the point where initramfs-tools.postinst runs.

However, it seems more robust to write this out when mkinitramfs is run, rather than only once on initial installation of initramfs-tools, so I'm opening a task on initramfs-tools as well.

Changed in initramfs-tools:
assignee: nobody → adconrad
Revision history for this message
Paul Sladen (sladen) wrote :

Nick: you clearly have various useful ideas about hibernation; although these don't solve the issue at hand; could you add them to a wiki page at:

Revision history for this message
Adam Conrad (adconrad) wrote :

Trying to guess what the correct swap partition is during every invocation of mkinitramfs is madness, IMO. We make this a conffile intentionally so that users can muck with it as they see fit, if they have multiple swaps or want to do something else insane that we've not thought of.

AFAIK, d-i writes this value out to match the swap that it initialised during the install, and ubiquity should be doing the same. After the install, I really don't think we should be touching it.

(Of course, the comments above about it being dynamically figured out during suspend/resume are things mjg59 and I have discussed, but that's a bit byeond the scope of this particular bug, and too hand-wavy for dapper)

Revision history for this message
Colin Watson (cjwatson) wrote :

I've fixed the Ubiquity side of this in my bzr branch.

I agree with Adam on robustness of mkinitramfs swap configuration; I'd have no objections at all if the initramfs-tools side of this bug were rejected.

Changed in ubiquity:
assignee: nobody → kamion
status: Confirmed → Fix Committed
Revision history for this message
Colin Watson (cjwatson) wrote :

ubiquity (0.99.77) dapper; urgency=low

  * Run hw-detect to set up /etc/modules properly (closes: Malone #40826).
  * Mimic base-installer's logic to configure initramfs-tools with an
    appropriate resume partition (closes: Malone #42299).
  * Fix logging in apply_keyboard.
  * Handle trfu/trqu console keymaps the same way as trf/trq (closes: Malone
  * Map croat console keymap to hr (closes: Malone #43598).
  * Mimic xserver-xorg's logic regarding alternate US layouts for non-Latin
  * Map et console keymap to ee (closes: Malone #42800).
  * Handle fi-latin1 console keymap the same way as fi (closes: Malone
  * Map mk, nl, ro, and ru console keymaps to the X keymaps by the same
  * Map gr console keymap to gr, and add it to the list of non-Latin
  * Change sr-cy console keymap to map to cs, not sr, following
    xkeyboard-config changes. Add this to the list of non-Latin keymaps.
  * Automatic update of included source packages: hw-detect 1.32ubuntu6.

 -- Colin Watson <email address hidden> Mon, 8 May 2006 17:39:19 +0100

Changed in ubiquity:
status: Fix Committed → Fix Released
Revision history for this message
sittisal (sittisal) wrote : Sorry for the list...but Help

... but i still recive the acpi-support bugmail. I
disabled it from launchpad but i still receive the
merssages. I've to unsubscrive because i'm changing
the e-mail address.
Sorry for this annoying message.

Chiacchiera con i tuoi amici in tempo reale!*

Revision history for this message
towsonu2003 (towsonu2003) wrote :

seems to be a problem for those who dist-upgrade:

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Marking initramfs-tools part of the bug as rejected based on Colin's comments, #13.

Changed in initramfs-tools:
status: Unconfirmed → Rejected
Revision history for this message
Peter Whittaker (pwwnow) wrote :

This report has been filed against three components: ubiquity, which has status fix released; initramfs-tools, which has status rejected (refer to previous comment); and update-manager. If we can close update-manager (status rejected), then this bug will be hidden, which is what I believe we want.

Any objections?

Changed in update-manager:
assignee: nobody → pwwnow
status: Unconfirmed → Needs Info
Revision history for this message
Peter Whittaker (pwwnow) wrote :

Marking update-manager "affects" as rejected to hide this report from searches, based on fix being released in Ubiquity and no objections (refer to previous comment).

Changed in update-manager:
assignee: pwwnow → nobody
status: Needs Info → Rejected
Changed in initramfs-tools (Ubuntu):
status: Invalid → New
Revision history for this message
Phillip Susi (psusi) wrote :

Please don't reopen ancient bugs without giving a reason.

Changed in initramfs-tools (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.