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

Compilation of the applicable log files and setup files.

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

/boot/grub/menu.lst

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.

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?

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.

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.

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

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.

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.

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

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

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.

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: https://wiki.ubuntu.com/

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)

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.

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
    #37867).
  * Map croat console keymap to hr (closes: Malone #43598).
  * Mimic xserver-xorg's logic regarding alternate US layouts for non-Latin
    keymaps.
  * Map et console keymap to ee (closes: Malone #42800).
  * Handle fi-latin1 console keymap the same way as fi (closes: Malone
    #42650).
  * Map mk, nl, ro, and ru console keymaps to the X keymaps by the same
    names.
  * Map gr console keymap to gr, and add it to the list of non-Latin
    keymaps.
  * 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

... 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.
Thanks.

Chiacchiera con i tuoi amici in tempo reale!
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

seems to be a problem for those who dist-upgrade:
https://launchpad.net/distros/ubuntu/+bug/69208

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

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?

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).

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