This is to fix #413247 . Reproducible: Always
I have looked through the change log of releases _after_ 3.4.24 (using "git diff v3.4.24 master ChangeLog"). I propose to take 3.4.24, add the following commits on top, release the result as 3.4.24_p1. The commits/fixes I am thinking of: + Fail hard on LUKS inclusion error (bug #409277), advise about + sys-fs/cryptsetup[static], drop support for cryptsetup binary from /bin/ + http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=7ee9306c7d68bd8b54219788b61558abc8732e9e + defaults/linuxrc: + Fix docache (bug #397309) + http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=8ac8de605504c830b411be0d8eaa597e49ac75b1 + Make sure the sha256 module makes it into the initramfs (bug #405495). + Reported by Ogelpre. + http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=1159b4c2f6c7cb672941e4786b4d1b427c25748a http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=506a94ab26b488a54f1a1a84ba74a5cc7db34c6f If we ignore the missing version bump, you can preview the result here: http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=shortlog;h=refs/heads/v3.4.24_pX
I'm actually not having troubles with genkernel-3.4.24: I'm not using LUKS and I'm allowing modules in my initrd images (a "stock" genkernel setting, apart for LVM). So, you're the master here. I would vote +1 for your 3.4.24_p1 solution, but unfortunately: - I can't test it right now, if this is what you're expecting from me; - LUKS and docache issues do seem relevant to me, but it also seems to me they are affecting the actual stable version (3.4.20) anyway; - they are probably not widely used options; - issuing an p1 right now may seem conflicting with the "stable" purposes to me; - the 3.4.20 problem reported in bug#413247 prevents a clean genkernel execution, which in turn prevents using a new kernel in most (all?) stable systems, which seems more severe than LUKS and docache to me. So, this stabilization request was meant to quickly fix a problem introduced by 3.4.20 with the constraint of sys-apps/openrc-0.9.8.4 . If we really want LUKS and docache, I guess the best way would be to stable (say) openrc-0.9.9 and move to (say) genkernel-3.4.25.1 or whatever fixes these issues.
(In reply to comment #2) > - I can't test it right now, if this is what you're expecting from me; Fine by me. > - LUKS and docache issues do seem relevant to me, but it also seems to me > they are affecting the actual stable version (3.4.20) anyway; Point taken on docache: I reverted that one from v3.4.24_pX > - they are probably not widely used options; Luks is disk encryption, one of the main reasons to need an initramfs. sha256 is needed to make that work using common cipher "cbc-essiv:sha256". > - issuing an p1 right now may seem conflicting with the "stable" purposes to > me; Both yes and no. Without these patches the release wouldn't be that stable either. Plus we haven't received any bug reports about these patches since their introduction. > - the 3.4.20 problem reported in bug#413247 prevents a clean genkernel > execution, which in turn prevents using a new kernel in most (all?) stable > systems, which seems more severe than LUKS and docache to me. I don't mean to get these extra patches in the way of anything. No worries about delays from that from me. > So, this stabilization request was meant to quickly fix a problem introduced > by 3.4.20 with the constraint of sys-apps/openrc-0.9.8.4 . If we really want > LUKS and docache, I guess the best way would be to stable (say) openrc-0.9.9 > and move to (say) genkernel-3.4.25.1 or whatever fixes these issues. We can still go that route later. I'll release a 3.4.24_p1 (= 3.4.24 + sha256/luks fixes) in a few minutes and add arches to CC after that.
+*genkernel-3.4.24_p1 (12 May 2012) + + 12 May 2012; Sebastian Pipping <sping@gentoo.org> + +genkernel-3.4.24_p1.ebuild: + Add 3.4.24_p1 for stabilization (bug #415483) + Let the stabilization begin :-)
I've walked into the same trouble with genkernel, busybox and glibc. But instead of the probably common case, i'm using a diskless hardware and therefore I need the NFS feature in the busy box. At #379481 comment27 SpanKY states that he found a upstream patch for busybox to allow NFS mounts and it was released as busybox-1.19.3-r1. Notice, that with this patch also the CONFIG_FEATURE_NFS_MOUNT parameter becomes obsolete for recent kernels. But i can't get it runnin': genkernel now run's without errors while compiling the busybox, but it still breaks while booting at the point to mount the NFS root because this feature is missing. Some hour later I maybe found the core reason: Unfortunately neither the genkernel ebuilds -- which will "save" the used disfiles to "/var/cache/genkernel" -- nor the config file "/etc/genkernel.conf" or the script "/usr/share/genkernel/gen_compile.sh" -- which will actually do a private build for the cached version of the busybox support patched versions, i.e. the "saving" of the corresponding gentoo patchfile sets to the sources in /var/cache/src/...". As i can see, genkernel just rely on it's own patchset at "/usr/share/genkernel/patches/" and for genkernel-3.4.24_p1, the patch "busybox-1.19.3-kernel-nfs.patch" isn't included. Right now, after symlinking the patch file to this location and rebuilding the ramdisk, this version of the busybox is able to mount and the boot process continues as before. From that, you should think about a stable way to deal with Gentoo-patched versions of the included packages. thank you Guido
Guido, I see your point, but I guess here we're dealing with a different matter, which is a genkernel failure on stable systems introduced by an upgrade to the glibc library. The problem you point out seem related to busybox not working with NFS, which is relevant, of course, but I guess should be addressed in a different bug.
Dear Giampaolo, Yes, this bug origins from a analog problem with LUKS. But should I open a new thead with the headline "Gentoo maintainers, please work together" instead? :) In another bug SpanKY point's to genkernel, because "his" busybox ebuild is patched and works. But this (and others) work is cast away here, because -- as i can see -- it don't care about the ebuilds in portage tree to build up the packages included into the ramdisk. Instead, it maintains it's private set of build instructions and patches. Why? From the Gentoo point of view, busybox is Linux upstream. But to my knowledge genkernel is a Gentoo tool, right? Of corse, the problem is introduced upstream by a clash betweeen busybox and glibc. But for the Gentoo universe, there's already a solution available: SpanKY have backported a upstream patch, but he probably don't know genkernel will not use it. I suggest: For a short term, you should contact the Gentoo maintainers for the included packages and merge in the current patches in portage tree available for. And for a longer term, genkernel should use the full ("normal") ebuild mechanism to build the included packages. Thank you
(In reply to comment #7) First and foremost: this is the wrong place to have this kind of conversation. Second: This is the wrong bug to even start this conversation. But here are some short points that may give you some answer: 1. Genkernel is an abbreviation of "Generate Kernel", and was done to be usable from any distro. 2. Genkernel should be able to generate a ramdisk to be used by another system (think creating a initramfs able to boot from lvm on a system where lvm is not merged/installed). 3. We need to know what version of different packages is used in the ramdisk, and be able to handle upgrades of packages when we have time to adjust our scripts for it. We also want to be able to just have "genkernel version x.x.x" in a bugreport instead of "genkernel version x.x.x using e2fsprogs version x.x.x.x, busybox version x.x.x, lvm version x.x.x" and not having to convince our user that those version numbers actually matters. 4. Patches we need to apply may not be needed for Portage, and vice versa. 5. the way a package is configured/compiled by Portage may remove or add functions we use or do not need. 6. Gentoo is a project made up of herds and subprojects. All in a somewhat messy mesh where noone is able to know exactly how their project/package is used by other project/packages. 7. Gentoo and its subprojects are non-profit, and are maintained by people doing it on its spare time, motivated by their own iches and/or appreciation. This makes most of your suggestions nearly impossible. Mostly because noone has the time to handle the outcome of them. This is also why we need people like you to: 1. Write bugreports - Try to keep them short - Try to keep them on topic - Try to research as much as possible, search forums, other bugs, find patches and mention them (with links!) in the bugreport. 2. Try possible fixes/workarounds and make short comments, suggestions. In this case, what I would like you to do is report a new bug against Genkernel containing: 1. A description of your setup, so we know what you are trying to archive, and with what tools. 2. A description of what breaks. 3. A suggestion of a possible fix with - link to bugreports/forums/mailinglists if they exists explaining what and why - link to the patch
Dear Xake, thank you for the extensive meta-informations, especial about genkernel is not a Gentoo-specific tool. And let us stop this discussion at his point as requested. Guido
x86 stable
amd64 stable
ppc64 done
(In reply to comment #10) > x86 stable It's broken for me personally, see the new notes in bug #413247 :(
arm stable
Marked ppc stable.
alpha/ia64/s390/sparc stable
Continued in bug #425360.
