work in progress... ebuild is working, need to integrate the resuming into genkernel initramfs generation
Created attachment 102855 [details] suspend-0.5.ebuild
Created attachment 102856 [details, diff] suspend-0.5-build.patch
bug #156431 has a genkernel patch which makes the whole thing rather easy: # emerge suspend configure resume in /etc/suspend.conf enable CONFIG_SOFTWARE_SUSPEND in kernel # genkernel [...] --suspend all reboot into new kernel # s2disk power on, system resumes to last point
mobile herd: anyone interested in co-maintaining this? I expect it will get popular over time...
Hi, What are the kernel requirements for this to work? I built it by hand.... Thank you.
see comment #3
Thank you for thje reply, but... I can't find the CONFIG_SOFTWARE_SUSPEND option in "menuconfig".
Type /SOFTWARE_SUSPEND<enter> in menuconfig and ensure you have satisfied all dependencies
It turns out that we aren't going to use this at work just yet and I don't have time to maintain it in my own time. Hopefully someone else will continue my work so far and get this in portage.
I'd love to have it on the tree. I've installed the ebuild and (after discovering that fglrx and fb wouldn't go along well) I got my Thinkpad T60 to suspend and resume, both to memory and disk. Much easier than suspend2, which still was giving me headaches when resuming.
I had to add the option -j1 to the line with "emake" to get it compiled on two of my systems (P4 2.6 GHz and Core2Duo). See Bug #179493
I have expanded a bit on this with two files; new ebuild and a script to generate initrd-images. Will post them shortly. Ebuild changes: - Replaced header (easytag?) - Added ~x86 keyword - Added short instructions to pkg_postinst() (elog) - Added installation of create-resume-initrd.sh (should be in files/) create-resume-initrd.sh: - Not the script that is bundled with suspend-0.5, but it does the same. Resume device and image size is read from /etc/suspend.conf instead of user input. I'm new to ebuilds, so I'm wondering: 1: Is there a way to check in the ebuild what CONFIG_s the kernel was compiled with? That way I could get rid of a few elogs. 2: Could someone make sure I didn't do something silly in the ebuild? I hope I did things the right way. PS: I don't use genkernel, and I don't know if things should be handled differently with it. Any input on that?
Created attachment 123896 [details] Ebuild with added keyword, elogs and script (next attachment) installation.
Created attachment 123897 [details] Script for resume-initrd generation.
I will be able to maintain this. I've fixed liblzf build, I am waiting for upstream to ack.
Created attachment 124984 [details] suspend-0.5.ebuild olechrt: I am sorry, but don't like the long logs. You should look at the README to know what to do.
Created attachment 124985 [details] suspend-0.5-build.patch
Created attachment 124988 [details] suspend-0.5.ebuild
Created attachment 124989 [details] liblzf-2.1_beta1.ebuild For now, I've put the fixed tarball at: http://dev.gentoo.org/~alonbl/liblzf-2.1_beta1.tar.bz2
Please check it out.
liblzf upstream is very rude! I won't maintain his library. >I hope so, in another way. Get to your senses and *learn* to get rid of your >wrong assumptions. Your proposals are techniccally unsound. Hating *me* for >your deficiencies is pointless. I am just the messenger. > >And I do regret having wasted my time with you. Certainly "those other" >distros have more capable maintainers that actually listen to technical >suggestions. > >*PLONK*
Update: I've worked with upstream in order to make this package more distribution friendly package. 1. Use lzo and not lzf. 2. Use autoconf/automake. 3. Support fbsplash. 4. Many more cleanups. Soon the new release with (1), (4) is released. Then genkernel will need to be updated. This is much easier to maintain. dsd: At bug#156445 you compiled the uswsusp as part of genkernel, I wish to modify it to use existing files and just copy resume into initramfs (much like splashutils), is there any reason why this should be avoided?
Yes. I no longer accept features that require files from the built system and am moving towards having everything use internal builds only. The reason for this is for cross-compiling reasons, where taking from the local disk is a *really* bad idea.
But how do you sync version/features/configuration required to exists both in root filesystem and initramfs? s2disk/s2both exists on root filesystem and resume exists on initramfs. They both needs to be synced (same version, same features [USE]) Also there is an issue of configuration, /etc/suspend.conf needs also to be synced up between these environments. BTW: Cross compile does not actually work (bug#190327).
I am well aware of what does and does not work in genkernel, thank you. I am also working to fix these problems, so I am not going to introduce anything new which doesn't meet with my goals. Remember that genkernel is a "Gentoo Hosted Project" which means it should be usable by *anyone* running Linux. There is far too much "Gentoo only" code in there that needs to be modified into a more widely available usage, which I am trying to do. It is just happening slowly.
Please replay to me questions at comment#24: But how do you sync version/features/configuration required to exists both in root filesystem and initramfs? s2disk/s2both exists on root filesystem and resume exists on initramfs. They both needs to be synced (same version, same features [USE]) Also there is an issue of configuration, /etc/suspend.conf needs also to be synced up between these environments. AS you said, genkernel should be available for all users... And the suspend package put the initramfs binary at /usr/lib/suspend/resume so it may be copied to initramfs at later time. I will be glad to read of a better solution, but mind that ${ROOT}/usr/sbin/s2disk, ${ROOT}/usr/sbin/s2ram and ${ROOT}/usr/lib/suspend/resume shares version, compression, libraries, splash etc... I don't see how this conflict with your goals, as the same applied to every component like this one which needs to be split between initramfs and root. splashtutils and suspend are a good example.
(In reply to comment #26) > Please replay to me questions at comment#24: > > But how do you sync version/features/configuration required to exists both in > root filesystem and initramfs? I haven't even thought about it. > s2disk/s2both exists on root filesystem and resume exists on initramfs. > They both needs to be synced (same version, same features [USE]) That's nice. It still isn't going to come from the host system. I am not going to rely on any of the following: make.conf /var/db entries anything in /etc/portage binaries on the system for inclusion into initramfs > Also there is an issue of configuration, /etc/suspend.conf needs also to be > synced up between these environments. This is simple to resolve. You setup genkernel.conf to point to the location for your suspend.conf file and give a sensible default file. This means you aren't *relying* on anything from the host system, as the configuration can come from anywhere. > AS you said, genkernel should be available for all users... And the suspend > package put the initramfs binary at /usr/lib/suspend/resume so it may be copied > to initramfs at later time. ...and? > I will be glad to read of a better solution, but mind that > ${ROOT}/usr/sbin/s2disk, ${ROOT}/usr/sbin/s2ram and > ${ROOT}/usr/lib/suspend/resume shares version, compression, libraries, splash > etc... We typically don't follow that philosophy with genkernel. The design of genkernel is to create a usable kernel for as many people as possible. What this means is we'll compile with pretty much every option enabled by default. > I don't see how this conflict with your goals, as the same applied to every > component like this one which needs to be split between initramfs and root. > splashtutils and suspend are a good example. OK. Let me put it simply. If it requires copying some binary from the host system doing the build, it fails my requirements. Lots of current code will need to be revamped for this. As I said, it'll happen over time. Anyway, enough of that. It doesn't really belong here, so I'll quit filling all your boxes with bugspam.
(In reply to comment #27) > > s2disk/s2both exists on root filesystem and resume exists on initramfs. > > They both needs to be synced (same version, same features [USE]) > > That's nice. It still isn't going to come from the host system. I am not > going to rely on any of the following: > > make.conf > /var/db entries > anything in /etc/portage > binaries on the system for inclusion into initramfs > > > Also there is an issue of configuration, /etc/suspend.conf needs also to be > > synced up between these environments. > > This is simple to resolve. You setup genkernel.conf to point to the location > for your suspend.conf file and give a sensible default file. This means you > aren't *relying* on anything from the host system, as the configuration can > come from anywhere. So why can't I point to /usr/lib/suspend/resume as well? It can point to anything... > We typically don't follow that philosophy with genkernel. The design of > genkernel is to create a usable kernel for as many people as possible. What > this means is we'll compile with pretty much every option enabled by default. Which option? suspend can be used with many options: compression, encryption, bootsplash, splashy, fbsplash and more. Which one will you enable and which you disable? How do you choose these? Will you recompile all dependencies in genkernel? So why don't you also compile the libc? > OK. Let me put it simply. If it requires copying some binary from the host > system doing the build, it fails my requirements. Lots of current code will > need to be revamped for this. As I said, it'll happen over time. Anyway, > enough of that. It doesn't really belong here, so I'll quit filling all your > boxes with bugspam. This is not bugspam, people are waiting for this package, and until I understand how we support version sync and advanced features such as compression and fbspalsh sync with the root components we will not be able to provide this to our users. I think that the users in the CC are interested in what we have to say regarding this. --- Maybe we can remove the compilation of suspend from current genkernel implementation and make genkernel support several overlays, so packages like splashutils and suspend may provide their overlays in predefined location so user can include them at build process? This may ease your decision to support this, as genkernel it-self does not directly depended on external binaries.
(In reply to comment #28) > So why can't I point to /usr/lib/suspend/resume as well? > It can point to anything... You can do whatever you want. I'll do what I feel is best in genkernel. Deal? > Which option? > suspend can be used with many options: compression, encryption, bootsplash, > splashy, fbsplash and more. > Which one will you enable and which you disable? > How do you choose these? Wow. I guess I really do need to spell it out. I would enable them all by default. > Will you recompile all dependencies in genkernel? > So why don't you also compile the libc? Are you trying to be dense or do you really just not understand what I am trying to accomplish? > This is not bugspam, people are waiting for this package, and until I No. It definitely *is* bug spam. Adding an ebuild has nothing to do with the genkernel support. However, since you're so concerned, I'm just going to rip out the current support that is in genkernel for the next release so you can get this into the tree without having to concern yourself with how I plan on supporting it in my package. > understand how we support version sync and advanced features such as > compression and fbspalsh sync with the root components we will not be able to > provide this to our users. > > I think that the users in the CC are interested in what we have to say > regarding this. Well, I am not interested in repeating myself over and over again, so I'm removing myself/genkernel from CC. I have already said everything that I think needs to be said from my end. I didn't realize this was going to turn into the Spanish Inquisition when Daniel first came up with it. I'm sorry that I jumped the gun and added support for this to genkernel when I did.
I can't merge suspend-0.5. I have liblzf installed (the beta ebuild): * Applying suspend-0.5-build.patch ... [ ok ] >>> Done src_unpack >>> Starting src_compile make -j2 CONFIG_COMPRESS=1 SUSPEND_DIR=/sbin CONFIG_UDEV=1 CC=i686-pc-linux-gnu-gcc i686-pc-linux-gnu-gcc -O2 -Wall -c vt.c -o vt.o i686-pc-linux-gnu-gcc -O2 -Wall -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c md5.c -o md5.o i686-pc-linux-gnu-gcc -O2 -Wall -DHAVE_INTTYPES_H -DHAVE_STDINT_H -I/usr/local/include -DCONFIG_COMPRESS -c encrypt.c -o encrypt.o i686-pc-linux-gnu-gcc -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c config.c -o config.o i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c bootsplash.c -o bootsplash.o i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c splashy_funcs.c -o splashy_funcs.o i686-pc-linux-gnu-gcc -O2 -Wall -c vbetool/lrmi.c -o vbetool/lrmi.o i686-pc-linux-gnu-gcc -O2 -Wall -c vbetool/x86-common.c -o vbetool/x86-common.o i686-pc-linux-gnu-gcc -O2 -Wall -DS2RAM -c vbetool/vbetool.c -o vbetool/vbetool.o i686-pc-linux-gnu-gcc -O2 -Wall -DS2RAM -c radeontool.c -o radeontool.o i686-pc-linux-gnu-gcc -O2 -Wall -DS2RAM -c dmidecode.c -o dmidecode.o i686-pc-linux-gnu-gcc swap-offset.c -o swap-offset i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c splash.c -o splash.o i686-pc-linux-gnu-gcc -O2 -Wall -g s2ram.c vt.o vbetool/lrmi.o vbetool/x86-common.o vbetool/vbetool.o radeontool.o dmidecode.o -lpci -o s2ram i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS vt.o md5.o encrypt.o config.o suspend.c -o s2disk splash.o bootsplash.o -L/usr/local/lib -llzf /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpci.a(names.o): In function `pci_load_name_list': names.c:(.text+0x527): undefined reference to `gzopen' names.c:(.text+0x5b9): undefined reference to `gzgets' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpci.a(names.o): In function `.L154': names.c:(.text+0x6bb): undefined reference to `gzclose' names.c:(.text+0x6d8): undefined reference to `gzeof' names.c:(.text+0x75c): undefined reference to `gzclose' names.c:(.text+0xb0d): undefined reference to `gzopen' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpci.a(names.o): In function `.L155': names.c:(.text+0xc7d): undefined reference to `gzerror' names.c:(.text+0xc9f): undefined reference to `gzclose' collect2: ld returned 1 exit status make: *** [s2ram] Error 1 make: *** Waiting for unfinished jobs....
Cyrill Helg: Please wait for the next release (soon).
(In reply to comment #30) > I can't merge suspend-0.5. I have liblzf installed (the beta ebuild): Well, you can if you re-emerge pciutils without the stupid zlib use flag...
Created attachment 129971 [details] suspend-0.7.ebuild New ebuild, with autoconf patch for the next release (Will make it easier for me to help and get some feedback before next release).
Created attachment 129972 [details, diff] suspend-0.7-autoconf.patch
genkernel users: Please refer to bug#156445, I've places some instructions of how to use the overlay in order to make it work.
why does the ebuild depend on dev-libs/libx86? the only ebuild[0] i found is named sys-libs/libx86. is the fbsplash use flag commented out because of a missing splashy/libsplashy ebuild? if not, can you provide a link to one? [0] http://viewvc.tuxfamily.org/svn_picoverlay_ebuilds/trunk/sys-libs/libx86/?pathrev=86
FWIW, fbsplash != splashy.
Created attachment 130866 [details] libx86-0.99.ebuild dev-libs/libx86
(In reply to comment #36) > why does the ebuild depend on dev-libs/libx86? > the only ebuild[0] i found is named sys-libs/libx86. Attached. > is the fbsplash use flag commented out because of a missing splashy/libsplashy > ebuild? if not, can you provide a link to one? After upstream merge the fbsplash I will post an update.
(In reply to comment #37) > FWIW, fbsplash != splashy. afair uswsusp currently only supports splashy (In reply to comment #39) > (In reply to comment #36) > > why does the ebuild depend on dev-libs/libx86? > > the only ebuild[0] i found is named sys-libs/libx86. > > Attached. > > > is the fbsplash use flag commented out because of a missing splashy/libsplashy > > ebuild? if not, can you provide a link to one? > > After upstream merge the fbsplash I will post an update. > Good news! (:
Created attachment 130871 [details] libx86-0.99.ebuild This dev-libs/libx86 should also work for amd64, can anyone test?
Created attachment 130872 [details, diff] libx86-0.99-build.patch
Added to tree with fbsplash support, I will resync this when upstream makes some progress. genkernel users will have to patch genkernel in order to work with this package, see bug#156445.
*** Bug 128468 has been marked as a duplicate of this bug. ***
