Linux 2.6.17 added a new way of hibernating (suspend-to-disk): exposing some more interface to userspace and then letting the snapshot image control be done as a user program. Userspace utilities were developed to use this functionality: http://suspend.sourceforge.net I intend to add an ebuild for this very soon: bug #156431 I haven't added support to the initrd generating code, is this still used/supported? It could be added easily if necessary.
Created attachment 102863 [details, diff] patch
Created attachment 102918 [details, diff] ebuild patch
Created attachment 102919 [details, diff] suspend-0.5-Makefile.patch
Created attachment 102986 [details, diff] updated genkernel patch suspend.conf is now copied in gen_initramfs.sh rather than gen_compile.sh. This prevents it from being cached in the bincache.
OK. The patch has been added to genkernel's SVN. The rest will need to be done in the ebuild when I roll up a new version.
Hi! Will you consider supporting suspend2 in the same way? I will create a patch to add sys-apps/suspend2-userui into the initramfs.
File a new bug for new additions, please.
Fixed in 3.4.6
OK. Per the discussion on bug #156431, I am removing this support from genkernel until the package is added to the tree. Because of this, I am reopening this bug report until newer support can be added.
Which support do you wish we add? You explicitly said that there is no relation between the ebuild and genkernel.
OK. This was removed with genkernel-3.4.9_pre2 which is now in the tree. I guess we'll revisit this in the 3.5 branch, when I start working on it.
Created attachment 129631 [details, diff] genkernel-minimal-suspend.patch Please apply the following so that people can put resume in an overlay and initramfs will be capable of resuming. No need to compile anything for this one. Thanks.
So if I want to use uwsusp with my genkernel initrd (because of lvm2, my swap is a lvm2 volume) I need to just apply the latest patch to what? genkerel?
wolf31o2: Please apply the minimal support in init script (attachment#129631 [details, diff]), so people may introduce their own overlay as in suspend2 case.
For people intersting in making uswsusp work (bug#156431): 1. Apply patch for genkernel from attachment#129631 [details, diff] . 2. Do: mkdir -p /tmp/initramfs-overlay/sbin cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever> Have fun!
[update] For people intersting in making uswsusp work (bug#156431): 1. Apply patch for genkernel from attachment#129631 [details, diff] [edit] . 2. Do: mkdir -p /tmp/initramfs-overlay/sbin mkdir -p /tmp/initramfs-overlay/etc cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin cp /etc/suspend.conf /tmp/initramfs-overlay/etc genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever> Have fun!
Created attachment 130076 [details, diff] dev_snapshot.patch Somehow udev on initrd does not create /dev/snapshot device on my system (genkernel-3.4.8, amd64) so resume can't do anything. This patch creates /dev/snapshot if it's missing before running /sbin/resume.
Created attachment 130111 [details, diff] genkernel-minimal-suspend.patch Thanks Sergey, A minor update.
*** Bug 191712 has been marked as a duplicate of this bug. ***
Do not add 156431 here. You do not need genkernel support to add an ebuild to the tree as genkernel is an independent Gentoo-hosted project which is independent to the tree. Thanks
But people cannot use this until you at least add attachment#130111 [details, diff] Adding the package to the tree will result in unusable package. So it is dependent. Please add the minimal patch, so we can drop the dependency.
BTW: The minimal support is identical to suspend2 support which already supported.
What? People can compile their own kernel and assemble their own initr{d,amfs} without genkernel. There are tons of packages in the tree without support in genkernel. What I am trying to explain to you is that genkernel is *not* blocking your package being added. I've also made it clear that I'm not going to revisit this for some time. I have no intentions on adding your patch to genkernel for reasons I have stated so many times I am starting to feel blue in the face. I am not interested in supporting *any* new code which pulls from the running system. Period. Now, please stop adding this bug as a blocker to your bug. Your bug does not depend on genkernel any more than gentoo-sources does. You have done your due diligence by adding a patch here that will allow users of your ebuild to use this support. As upstream, I have rejected this patch. Now, you have two choices here, you can either add the ebuild and be done with it and I'll add proper suspend support to the next genkernel in a manner that I think is best, which includes doing all of the building and such within genkernel, or you can sit on it for as long as you like. I will not be adding any support for suspend until it is in the tree, and that support will be added in the manner of my choosing. I am not meaning this to be rude, but genkernel is my package and I am the one that has to support it. I'm not going to support code I do not with to support, so please take this opportunity to revisit your thoughts on this and understand that whatever pressure that you might think that you are putting on me as genkernel's upstream is unwarranted and unwanted. Now, please do not add 156431 to this bug again. I have no intentions on ever adding suspend support to genkernel until it is in the tree. I thought that I had made this clear before when I said that I wish I had never added it. Thanks
The patch for minimal support does not pull anyting from the tree! So the reasons you keep mentioning are not true. Please add the patch from attachment#130111 [details, diff], as people are waiting for it. As in the livecd theme cases... I need to do your job in making users happy... The minimal patch will do nothing for your ego so please add it.
*sigh* What part of "I am not going to add it" do you not understand? Trying to passive-aggressively threaten someone by adding devrel to a *technical discussion* sure isn't the way to win an upstream to your cause. I'm sorry, but unless there is some interpersonal issue that I am unaware of here, Developer Relations has exactly zero authority here. The closest team that would preside over this would be the QA team, but refusing to support something I don't feel like supporting isn't exactly a QA violation. It is my right and privilege as the upstream maintainer of genkernel. Now, I am trying to be as civil as I possible can with you, but you are starting to upset me with your single-mindedness on this issue. I have requested that you stop and you have not. In case you are wondering, that *is* a devrel-enforceable charge. Of course, I think we can work this out like civil adults without involving Developer Relations, which is why I am removing them from this bug. If you insist on bringing them in on a technical issue, I will be forced to play my hand and file a complaint against you for harassment. Let me say this one more time. I am not adding your patch. Your continued persistence that I am somehow obligated to do so is bordering on harassment. Stop your harassment *now* or I will be forced to take appropriate action. Thank you.
Created attachment 134504 [details, diff] genkernel-minimal-suspend.patch [Update, no need for configuration file] For people intersting in making uswsusp work with genkernel: 1. Apply this patch. 2. Do: mkdir -p /tmp/initramfs-overlay/sbin cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever> 3. Add resume=<device> at your kernel command-line. Have fun!
Can we please have attachment#134504 [details, diff] for genkernel-3.4.9? Thanks.
Prodding like that on the bug just makes us (well, me) want to stick this bug at the very end of the queue. We're right in the middle of a release cycle, in addition to having jobs and real lives. You've done your part by creating the patch. We'll get around to doing our part.
Created attachment 136075 [details] genkernel-3.4.9_pre9-uswsusp.patch Rebase.
Why haven't you added this to 3.4.9? Was it so hard to apply a simple patch? From comment#28, it seems to be some kind of queue unrelated to technical priority. I did not bother you (as requested), in order to not get into the end of this strange queue... Well... On genkernel-3.4.9 too, users will also won't be able to use uswsusp. That means that whoever cares about his users ends up in getting comments like this... And our users not getting a solution. Great work!
Created attachment 140761 [details, diff] genkernel-3.4.9-uswsusp.patch Rebase. For people intersting in making uswsusp work with genkernel: 1. Apply this patch. 2. Do: mkdir -p /tmp/initramfs-overlay/sbin cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever> 3. Add real_resume=<device> at your kernel command-line.
*sigh* Allow me to explain to you *one more time* why this has not been added. I am planning on writing the code for this support in such a manner as to not require it to pull files from the local filesystem when it is not necessary. As such, it was not ready for inclusion in 3.4.9, as 3.4.9 was essentially a rollup release for things required for releases. Since we weren't using this in our releases, it was deferred to a later date. While I understand that you do not personally agree with this decision, I *am* upstream for this piece of software and it is up to me to decide what to do with it. As such, you really need to have some patience and wait for me to include this *without* the attitude. There is *no reason* for you to act in this way. As such, consider this my "dev to dev" talk about your continued attitude problems towards me. Stop your little personal crusade, now. I don't care if I made you upset by not accepting your patches, as is. That is my prerogative as the package maintainer. It also isn't a QA violation to *not* add new code. It *could* be a QA violation if I refused to fix broken code, but this is new support, and doesn't apply, as such. Please take a step back and think about your interactions on this bug and think about it as if I were an external developer of an external piece of software. Would that upstream even want to deal with you again after this sort of an attitude? Of course not... Since you seem determined to think that the inclusion in non-technical, allow me to point you to https://bugs.gentoo.org/show_bug.cgi?id=156431#c23 for my reasoning. Whether you agree with it or not, it is a technical reason for why this has not been included. If you would like to see this included much more quickly, I ask you to rewrite the patch to build and compile the necessary binaries within genkernel. If there are any configuration files required for this, then the location of the config file should be a variable set in genkernel.conf, and should likely default to the default location. If you are not willing to write this patch, then you will need to wait for me to do so. That means you have to wait until it fits into *my* schedule. I had thought that I had made this perfectly clear, but I guess not. Also, new feature requests are *always* at the end of the queue. New feature requests without patches acceptable to the author are lower priority than patches that are acceptable. As such, this is already about as low of a priority as one can get, but your attitude makes me not want to work on this, so it *does* lower the priority and it *is* for a non-technical reason, but the main reason for it not being included is technical. I'd add this support even if you were a supreme asshole, so long as the patch was acceptable. In this case, the patch is not acceptable, and you're being a jerk about it. Please try to *at least* have a respectful attitude. I don't expect you to respect me or even to like me, but simply to respect that I am the current maintainer of this software and it is my call what does and doesn't go in and why. Thank you
Until a perfect solution will come, you can provide users the same level of support you already have for suspend2/tuxonice, whose patch you accepted. The minimal patch does not copy any binaries from local system as you requested, so I don't see what is wrong with it, it provides temporary solution, but makes some of Gentoo user happier. I ignore all personal stuff. If you want genkernel to be usable, you should rewrite it to be modular. For example have /usr/share/genkernel/packages.d which have a script for each package that responsible to compile it... And at /etc/genkernel.conf specify which packages to compile. The output of the packages is cpio file that merged into initramfs. At the initramfs there should be /etc/initramfs.d (or any other) which will have initramfs init script parts, sorted by a numeric prefix and sourced by /init. This way every package may add its own functionality into the init script. There should also be hooks in /init to allow registration of init parts functionality, for example at startup, after device manager, before root mount, after root mount etc... This way we can have app-genkernel/busybox, app-genkernel/uswusp, app-genkernel/splashutils which places the tarballs and builds script at the correct locations. If you do this, people may add whatever they wish into their initramfs in a proper way. But until then, adding a new package is a task only you can do to your satisfaction.
Forgot to mention that as packages builds them selves genkernel should also install their output to common root, so libraries may be found. For example, compiling with splashutils or libgcrypt libraries.
(In reply to comment #33) > If you want genkernel to be usable, you should rewrite it to be modular. This is exactly our plan with 3.5's release.
Half a year later and genkernel still does not support software suspend -- even though the solution has been in this bugreport a year. Could someone please add the patch to genkernel? It's annoying to have to do it manually every time I upgrade to a new kernel (even though I've made a shell script which does it). Alon Bar-Lev has retired for very good reasons (bug 233301 comment 128), Chris Gianelloni has also retired, so another developer assigned to genkernel suspend support is desired.
The genkernel package is still being maintained (1) by the same group of maintainers (2), however the preliminary work is not done on Gentoo infrastructure. When the new version is ready it will be committed it to the Gentoo tree. (1) http://git.wolf31o2.org/gitweb/?p=projs/genkernel.git;a=summary (2) wolf31o2 - retired Gentoo developer, agaffney - current Gentoo developer, robbat2 - current Gentoo developer
Correct. As stated before, these patches are not sufficient for inclusion. It doesn't matter how long the patch sits here in Bugzilla, it isn't going to magically become a candidate for inclusion without being reworked.
(In reply to comment #38) > Correct. As stated before, these patches are not sufficient for inclusion. It > doesn't matter how long the patch sits here in Bugzilla, it isn't going to > magically become a candidate for inclusion without being reworked. > Does anybody have any idea who is doing the rework? Its a shame that this support is still not there in genkernel.
any news on this patch ? was it already included ?
ping?
Maybe just add: [ -e /etc/initrd.splash ] && . /etc/initrd.splash +[ -e /etc/user.linuxrc ] && . /etc/user.linuxrc So people can override functions, such as do_resume. You cannot totally ignore mobile users, well you did since 2006.
(In reply to comment #38) > Correct. As stated before, these patches are not sufficient for inclusion. It > doesn't matter how long the patch sits here in Bugzilla, it isn't going to > magically become a candidate for inclusion without being reworked. Makes sense. Could you describe what a good patch to this problem needs? PS: Adding keywords Inclusion and "[patch] " prefix to better show this bugs nature in searches...
The kernel supports parameter resume=/dev/swappartation, I recommend not using initrd image unless you really need it for some reason. a) This bug was opened in 2006. Not yesterday. 2006. b) Patches to genkernel 3.4 are not welcome beceause we are supposedly waiting for a 3.5 rewrite announced in 2007. Also not yesterday, that's 3 years ago. It will never happen. c) Git shows no progress on genkernel 3.4.x and there is no 3.5 development being done. I know this is not a solution for those who need initrd, but if you don't then just don't use genkernel or just comment out the initrd image it makes from grub.conf and suspend to disk works just fine. Genkernel will apparently be broken until Alon Bar-Lev or some other developer(s) takes over the project. All other distributions support suspend to disk out of the box, users expect it and it is sad that Gentoo will never have genkernel support for it for really redicilous reasons.
(In reply to comment #44) > a) This bug was opened in 2006. Not yesterday. 2006. > b) Patches to genkernel 3.4 are not welcome beceause we are supposedly waiting > for a 3.5 rewrite announced in 2007. Also not yesterday, that's 3 years ago. It > will never happen. I understand und share part of that frustration. > c) Git shows no progress on genkernel 3.4.x and there is no 3.5 development > being done. lxnay and I are currently trying to bring his sabayon patches to genkernel to gentoo, see branch lxnay. If you have time and will to join genkernel maintenance please contact genkernel@g.o. so we can add you to that mail alias and integrate you with the process. We could use help on critical review of patches for instance (bugs assigned to genkernel plus keyword "inclusion"). > I know this is not a solution for those who need initrd, but if you don't then > just don't use genkernel or just comment out the initrd image it makes from > grub.conf and suspend to disk works just fine. > > Genkernel will apparently be broken until Alon Bar-Lev or some other > developer(s) takes over the project. All other distributions support suspend to > disk out of the box, users expect it and it is sad that Gentoo will never have > genkernel support for it for really redicilous reasons. Please help us port their approach over if you can. I myself am no expert on this area, yet.
a start would be to get the patch working with 3.4.10 or 3.4.11 so that the users (including me) could start / continue using uswsusp (including s2disk) again I've looked at the patch but unfortunately stuff seems to have changed too much that it would work anyone willing to help ? thanks !
Posted new patch here http://bugs.gentoo.org/show_bug.cgi?id=303533
*** Bug 303533 has been marked as a duplicate of this bug. ***
Created attachment 379324 [details] swsusp_resume func (In reply to Aleksey Kunitskiy from comment #47) > Posted new patch here http://bugs.gentoo.org/show_bug.cgi?id=303533 Thanks Aleksey. Could you take a look at this rewrite of the swsusp_resume() function in defaults/initrd.scripts? It needs to be tested. It should be a bit more efficient, though I just wanted to avoid eval. Hopefully it'll be easier to add things to as well. I put the check for the actual device back in, in line with the older version, though not using ls (cf: http://mywiki.wooledge.org/ParsingLs ) I figured since we're checking /proc/cmdline, then we're bound to Linux, so readlink is permissible. If the creation of /dev/snapshot is essential, then it should return on failure there, but I don't use any of this, so no idea. Regards, steveL.
Comment on attachment 379324 [details] swsusp_resume func Thank you for sharing this alternative function; I encountered issues with s2disk resumes not working when using swap files on the root of an encrypted luks disk, this deployment scenario requires --resume-offset be passed at boot. With some slight modifications this enabled the functionality for me and I just wanted to share further details if others are stumbling with similar issue. busybox v1.27.2 readlink does not support -e or -s flags, I replaced with -f. However, since this passes the systems suspend.conf file, you can literally pass resume=garbage and resuming from s2disk will work -- invading that check. Omitting "-f /etc/suspend.conf" would add further complexities elsewhere for those needing to set the offset parameters when using swap files. ...some thoughts are to check that we have valid args set before running the resume command? Or why bother and just pass a resume=true arg and read the conf file? or are there scenarios in which one would need to override those values?? Anyway, this still works for me but isn't entirely clean. Tested against genkernel 3.5.3.2 with an INITRAMFS_OVERLAY (as described within the previous comments to source the binary and config files) (I apologize if I'm posting on the wrong / old thread, please point me to the latest discussion?)
Can anyone confirm if this bug is still valid with recent genkernel versions (4.x)?
Genkernel 4.2.1 is missing the resume in swsusp_resume and does neither include it nor the /etc/suspend.conf The gentoo wiki correctly displays a warning w/ steps to circumvent this issue (https://wiki.gentoo.org/wiki/Suspend_and_hibernate#Suspend_to_disk). Not sure if this is the desired solution but patching initrd.scripts and provide an initramfs-overlay works for my gentoo box using LVM w/ encrypted root/swap.
