Hi there! Today I upgraded my system and it happened that the kernel was upgraded as well, from /var/log/dpkg.log: 2010-09-16 09:28:54 upgrade linux-image-2.6.32-5-amd64 2.6.32-21 2.6.32-22 And now pm-hibernate does not want to suspend anymore, because from /var/log/pm-suspend.log (implemented to solve #457515): Thu Sep 16 18:17:29 CEST 2010: Running hooks for hibernate. /usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate:kernel \ update inhibits hibernate (/var/run/do-not-hibernate present) Returned exit code 1. However, I am running another kernel (2.6.34-1-amd64), thus pm-hibernate should work anyway. Indeed, removing /var/run/do-not-hibernate and hibernating did not cause any issue (FYI, I am now at the third hibernation/thawing cycle after the issue above). The following patch should solve this issue, tested locally while both upgrading the running kernel and a not-running one:
Actually, preventing hibernation is not the right solution. The right solution is to make sure hibernation works even when a new version of the running kernel is installed. I do that by hand in my system by copying the vmlinuz and initrd files in /etc/rc.local to a safe place which I can select from the GRUB menu. Stefan
And how do you suggest we detect such local modifications? Imho it is better to err on the safe side. Not being able to hibernate, even if possible, is a nuisance. Losing data because of a failing resume/thaw is not. Michael
I don't suggest you detect them, I suggest "you" (or some other part of
Debian) set them up.
Stefan
Yes, indeed, the process Stefan is using is the correct process, IMHO, and should be formalized. That is, after booting a given kernel (and it does need to be done immediately during/after booting so that a same-version upgrade doesn't replace it), that kernel and it's initrd should be "stashed" as the kernel to thaw into. Then the hibernation process should modify grub to add a "thaw from hibernate" option that boots the stashed kernel/initrd in addition to the other existing kernel options. The thaw option should probably be default though. In fact, writing up a package to plug all of that into the boot/hibernate/thaw process shouldn't be terribly difficult I think.
I think you are underestimating the complexity involved. That said, I'd be willing to review a detailed proposal or patch.
I must be since in a few hours I seem to have come up with a few modifications (all new files, no patching of existing files necessary) that achieves the goal. I have yet to debianize these additional files into a formal package, but perhaps we can start with a review of the files. Big fat disclaimer though... these are based on a Ubuntu Precise system so perhaps your mileage might vary. The attachments are: /etc/init/save-kernel-for-hibernate.conf /etc/grub.d/08_linux_thaw /etc/pm/sleep.d/20_update-grub Again, maybe there are some glaring holes in this implementation, but it really is the fruit of just a couple of hours of work and testing and it works, quite wonderfully here. It was even tested as working to resume from hibernate after a kernel update was installed and resumed again, after the new kernel was fresh booted and hibernated. Cheers, b.
you are aware you sent a patch for upstart while debian uses sysvinit? I stopped right there and didn't look any further
You have not yet made any comment on my last update including implementation. I would appreciate knowing why you think it's so complicated when I was able to achieve a result with so few changes. Cheers, b.
Yes, I am aware of that. I didn't think it would be too much of a stretch for one to understand what that upstart init script was doing and how a sysvinit implementation of it would work considering I was only putting forth a proof-of-concept to try to understand why you think this task is so complicated. Shall I resubmit this all after converting that upstart script into a sysvinit script for you? And didn't even bother to respond as such? Instead you just leave a contributor wondering? Is this really the way to foster a healthy open source community of contributors? Why do you have to be like that? Seriously. Is the rest of the work in my proof of concept so tainted just because there is a (IMHO, very simple to understand) upstart script in it and not a sysvinit script? Seriously though. Why do you have to be like that?
Hi, You submitted the patch just two weeks ago. At that point wheezy was already frozen. This means this feature will most likely not be accepted by the release team, so it wasn't a pressing issue for me and I simply didn't look at it back then. Instead you just leave a I just had a look at it today, when you pinged me again. Remember, I'm doing Debian in my spare time also and I'm (co-)maintainer of over two hundred packages, so I get a lot of bug reports and review requests. I can't answer each and every bug report right away and sometimes I'm just really short in my reply because I simply lack the time. world better. There is no need to make this personal Anyway back to a more technical level: I need to be honest and say that I don't like the approach to do this via a sysvinit or upstart script which does the copy on each and every boot, even when a/ the kernel doesn't actually change during runtime because it isn't upddated b/ the user doesn't actually use hibernation Also, running grub-mkconfig on every boot is is a very costly operation which can take several seconds. pm-utils is basically installed on every laptop and desktop system. On stable, the kernel practically never changes. Also, hibernation is a rather rarely used feature compared to suspend. So we slow down the boot process unnecessarily for almost everyone. Running the grub update on *every* hibernation is wrong, too. Most of the time the kernel will not have changed in between so this is slowing down hibernate unnecessarily, which should be as fast as possible. What happens to those grub entries after a reboot? It seems to me they are left there as stale hibernate entries. Stale entries are cleared during boot, so we will have those entries at least for one boot cycle, right? I also don't see any error handling anywhere, in case /boot was not writable/big enough to create the stashed kernel. This can happen if you have a separate /boot partition which is small or mounted ro. 08_linux_thaw looks like it could be painful to maintain, it looks rather complex and contains stuff like kexec. Is everything there really necessary? Is that a copy of /etc/grub.d/10_linux which has been extended by you? It has stuff like /etc/linuxmint/info in there which make me curious where it comes from as it generates warnings on my Debian system. I'm not a grub expert, so I'm a bit wary about having to maintain such a file. To sum up: I'm not happy about the general approach to do this kernel stashing during boot and running grub update at boot and before hibernation and the implementation has its flaws, too. You might look into the /etc/kernel/ hooks, which are run whenever a kernel is upgraded. Maybe it allows to do the kernel stashing in a much cleaner way. I would also very much prefer, if the grub specific hook is moved into grub proper. grub already contains the hooks for xen kernels or the recovery mode. So adding boot entries for such stashed hibernate kernel might fit in there, too. I've CCed Colin. Maybe he can comment on this. Colin, the relevant files are attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597199#35 Michael
Hi Michael, OK. That's a fair assessment. TBH, I was not entirely happy with the approach but wanted to put something out there to try to solicit comment and more importantly, ideas. Right. Agreed. And now that I have had some time to read your entire critique and reflect, probably that belongs in the actual resuming-from-hibernate code path. It can probably gated with some logic to see if the grub config is newer than stashed kernel to avoid it every time. I will look into that. No. They are cleaned out by the "resume|thaw" code path in /etc/pm/sleep.d/20_update-grub. No, during thaw (i.e. return from hibernation). No, per above. Yes. This was just proof-of-concept to solicit critique on the approach. Of course a final implementation would have to have error handling. Yes, it is a copy of /etc/grub.d/10_linux modified to handle the "Resume from Hibernation" grub entry. I debated simply adding that handling to the 10_linux hook or maintaining the spirit of grub.d's modularity. Obviously I chose the latter. I'm certainly not against the former, it just means more red-tape in the form of trying to get a modification into grub as well as pm-utils, co-ordinated. TBH, I'm not entirely optimistic that grub will take such a modification since it has reliance on the bits also being in pm-utils, tying the dependency of the two packages more tightly together. Yeah, that is just an artifact of the fact that my system is a Linux Mint system. Of course, if the work were applied to Debian, such a thing would not be in that file. Additionally, the duplication of "linux_entry()" in that file begs for some abstraction and/or sharing of that function amongst hooks. But again, my submission was just a PoC for comment. Well, I can agree with getting that stuff out of the boot path given your idea below, but if it's not in the boot path, it pretty much has to be in the hibernate path. Not having it in both the boot path and not in the hibernate path is pretty much like wanting your cake and eating it too. Yes, this is a good idea. I tend to forget that there is a hook system called during kernel upgrades and indeed, it would be a better place to stash the running kernel. Yes. The recovery mode is handled by 10_linux for the kernels that are handled by 10_linux but xen kernels are handled by their own hook in 20_linux_xen, just like my own 08_linux_thaw, and is very much a duplication+modification of 10_linux, again just like my own 08_linux_thaw. IOW, if xen kernel handling is the model to follow, then my 08_linux_thaw very much follows the model. Let me take a moment now to thank you very much for the critique. It was exactly what I was looking for. Thank-you. With any luck I will find the time to try to rework my implementation. Cheers, b.
Ok,
save-kernel-for-hibernate.conf:
# make sure any previous hibernate grub menu item is cleared out
grub-mkconfig >/boot/grub/grub.cfg
I assume this was done in case of a failed thaw?
Right, but 20_linux_xen is shipped and maintained by the grub maintainers.
While we are talking about grub, there is something which has been
bugging me for quite a while:
Consider you have different operating systems or multiple kernels
installed on your machine. After a hibernate, grub should not show the
full menu which lets you select an alternative kernel / system, but
immediately load the kernel which as used for hibernation.
If you have a shared partition between different systems and you boot
into the wrong one, i.e. not the one which was used for hibernation, you
risk data loss otherwise
So if we are going to mangle the grub entries anyway, maybe we can fix
this issue while at it.
Michael
Indeed. I had a failed thaw just yesterday in fact. That's one reason we do have to update grub in the boot path, unfortunately. Now, granted, it could be a little smarter and only run that if a resume-from-hibernate entry is found in the grub file, then it only slows down boots from failed thaws, which should hopefully be next to never -- although my failed thaw yesterday proves it's not never at all. Well, I don't really care one way or the other who ships and maintains it. I'm not entirely optimistic about them accepting it since it depends on how pm-utils does it's kernel stashing and needs to maintain parity with that. I suppose we could have both pm-utils and grub look in an /etc/default file about where kernels are stashed, etc. But yeah, if the grub maintainers accept that functionality, I have no problem with it being in grub. Yes, indeed. I actually tried to add a new top-level menu in my own grub when I was experimenting with all of this, so that the top level showed only the "resume from hibernate" option plus one other option "Boot a new kernel" which was a sub-menu that was just the usual top-level menu of your various kernels and other operating systems. Multiple levels of sub-menus didn't seem to work though, despite the grub folks saying they should, IIRC. Do you mean one root filesystem that is used by multiple grub entries for example? And you hibernate while booted on that shared root but then boot a new/fresh system on it after hibernating on it? I could see how that could be a problem. So then perhaps after a hibernate there is no "boot other system" option at all and the only option is to resume? In such a case, I guess we don't even need a menu. Grub should just boot the hibernation kernel without any pause or menu. OK. Cheers, b.
We could just do:
- at boot time:
1) rm /boot/vmlinuz-running /boot/initrd-running
2) get BOOT_IMAGE from /proc/cmdline
3) ln /boot/vmlinuz-running $BOOT_IMAGE
4) do the above for the initrd as well
- these hard symlinks should prevent dpkg from modifying the old kernel image
- when hibernating:
1) grub-editenv set HIBERNATED=true
- at thaw and shutdown:
1) grub-editenv unset HIBERNATED
- in Grub:
- detect if HIBERNATED=true and in this case boot the hibernated image
Greetings,
Mateusz Jończyk
Dear submitter, as the package pm-utils has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1058701 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)