I'd like to get this fixed to 'do-not-hibernate' before feisty leaves
the door, otherwise we'll be carrying (totally broken) compatibility
code for forever after.
** Summary changed:
- swsusp fails after automatic kernel upgrade
+ use 'do-not-hibernate' NOT 'do-not-suspend' to prevent hibernate f
mdz: yes, that is correct, 'do-not-hibernate' is the issue, suspending
is fine. There are other cases where 'suspend' does not work, but
hibernate does.
--
swsusp fails after automatic kernel upgrade
https://launchpad.net/bugs/14908
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
http
Shouldn't this be do-not-hibernate, or do-not-suspend-to-disk?
suspending to RAM is perfectly OK in this scenario, isn't it?
--
swsusp fails after automatic kernel upgrade
https://launchpad.net/bugs/14908
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/
The postinst now touches: /var/run/do-not-suspend
So anything that needs to know should fail to suspend when this file
exists.
** Changed in: linux-source-2.6.17 (Ubuntu)
Sourcepackagename: linux-source-2.6.17 => kernel-package
Importance: Undecided => Medium
Status: Unconfirmed => Fix
Wouldn't this also be fixed if you guys used pm-utils? mjg59 - I thought
you guys were going to think about switching to pm-utils in feisty - so
we can get this sort of thing common upstream. mdz - have you looked at
the HAL suspend and hibernate failure reporting code from davidz?
--
swsusp fail
Ben, please arrange to have the kernels touch a file or otherwise record
this information in a form which is easy to test for.
Ideally we should display some sort of notification if we decide not to
hibernate, but we don't do that if there isn't swap available etc., so
at least logging it and not
The old kernel isn't automatically uninstalled, is it? Would a better
approach be to make hibernation somehow trigger the use of the old
kernel?
Just a thought, I don't really have any solid idea of how one would
implement it beyond hacking up '/boot/grub/menu.lst'.
--
swsusp fails after automa
On Fri, Oct 20, 2006 at 08:57:21PM -0400, Ben Collins wrote:
> On Sat, 2006-10-21 at 00:07 +, Matt Zimmerman wrote:
> > Ben, please arrange for future kernels to drop a file or such so that we
> > can test its timestamp against the uptime of the system to determine
> > whether the kernel has be
Done. If consensus is that the acpi-support task here should be
powermanagement-interface instead, please change it.
** Changed in: acpi-support (Ubuntu)
Target: None => later
** Changed in: linux-source-2.6.17 (Ubuntu)
Target: None => later
--
swsusp fails after automatic kernel
This is related to bug #36577, worth dup'ing it? That bug is that 'pmi'
should deny hibernation is the same kernel will not be used on next
boot.
--
swsusp fails after automatic kernel upgrade
https://launchpad.net/bugs/14908
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lis
On Sat, 2006-10-21 at 00:07 +, Matt Zimmerman wrote:
> Ben, please arrange for future kernels to drop a file or such so that we
> can test its timestamp against the uptime of the system to determine
> whether the kernel has been upgraded since the last reboot (and refuse
> to hibernate in this
Ben, please arrange for future kernels to drop a file or such so that we
can test its timestamp against the uptime of the system to determine
whether the kernel has been upgraded since the last reboot (and refuse
to hibernate in this case).
** Also affects: linux-source-2.6.17 (Ubuntu)
Importan
Hi,
in order not to slow down the everyday boot process, I would suggest not
to touch a file, but to drop a short shellscript together with a link to
the /etc/rc init script system (or "upstart"-system), which deletes
itself after the first successful reboot.
Otherwise, one would have to always c
13 matches
Mail list logo
