I have fixed unionfs support (--unionfs-dev) in genkernel. 2.6.18 kernel and latest unionfs >1.3 support is there, to get this one working I had to use a well-tested unionfs devel snapshot (thanks Arch Linux). Genkernel patch (against 3.4.4) attached.
Created attachment 100566 [details, diff] fixed unionfs compilation
Created attachment 100567 [details, diff] fixed unionfs compilation
This doesn't really "fix" it, which is why I haven't applied anything like this yet. The problem is that you need certain unionfs versions for certain kernels, which causes all kinds of hell to break loose. Since genkernel is supposed to be a generic kernel builder, it cannot be limited to a specific kernel version. Basically, we need a smarter unionfs build system for genkernel, or it needs to be stripped entirely and rethought.
yes but at least include those changes. I think that they are safe and needed to test unionfs+genkernel progresses. Please do not remove unionfs code in genkernel, it would be a shame, just keep that disabled so I can re-enable and fix the things that do not work ;) If you want, I could maintain that stuff.
Created attachment 100706 [details] unionfs helper functions You can use a hash table to choose the correct unionfs version based on the kernel. This attachment implements the hash table logic. It will set UNIONFS_VERSION to the correct version, given the value in ${KV}. To use these functions, change gen_compile.sh to source the file. Then, add: + get_unionfs_version + # subsitute source tarball here. + # the user can override this functionality by changing + # ${UNIONFS_SRCTAR} in /etc/genkernel.conf. genkernel can + # print a warning if the two versions do not match. + UNIONFS_SRCTAR=${UNIONFS_SRCTAR/UNIONFS_VER/${UNIONFS_VERSION}} inside of compile_unionfs_modules. The genkernel ebuild will have to download the different versions of unionfs. Also, this idea can be extended to invoke different versions of compile_unionfs_modules, if the versions differ enough.
great :) yes there are some small differences from unionfs 1.3 and the current svn. You can see the workaround to compile unionfs utils inside my patch.
Created attachment 102580 [details, diff] Use callbacks to build the correct unionfs based on the current kernel This patch implements the complete callback system. I have tested it with a 2.6.15 kernel and a 2.6.17 kernel. It may or may not work with different variants. It does not support 2.4.x kernels. The patch requires a small change to genkernel.conf. The difference is included in the patch. Look for the section named "sample_unionfs_genkernel.conf." Most of the interesting stuff is added into a new file named gen_unionfs_helper.sh. gen_compile.sh has been changed to call into the new file. I think that this patch is at least a start.
2.6.17??? Does it work with 2.6.18 kernels and a 2.6.18-aware unionfs? There have been some changes in the unionfs sources lately.
I have not tested with a 2.6.18 kernel. I didn't have a 2.6.18 kernel around, but the patch does have the hooks for unionfs version 1.4. Currently, those hooks just call the version 1.3 entry points. Look for "compile_unionfs_modules_1_4()" and "compile_unionfs_utils_1_4()" in gen_unionfs_helpers.sh.
(In reply to comment #9) > I have not tested with a 2.6.18 kernel. I didn't have a 2.6.18 kernel around, > but the patch does have the hooks for unionfs version 1.4. Currently, those > hooks just call the version 1.3 entry points. Look for > "compile_unionfs_modules_1_4()" and "compile_unionfs_utils_1_4()" in > gen_unionfs_helpers.sh. > Update: I just tested it and it works without any changes.
Ok Dan, I am going to test that ASAP. Chris? any hint? Is there anything that we could do to get unionfs back into genkernel? You could even add a USE flag on the genkernel ebuild that enables this "experimental" unionfs support.
I've tested your patch, in few words: - unnecessarily complex - buggy - needs constant updates to keep in sync with new unionfs releases
(In reply to comment #12) > I've tested your patch, in few words: > - unnecessarily complex What are your suggestions to make it simpler? > - buggy What bugs did you encounter? I did notice that the include line was relative to a path on my computer, but I have not experienced any other problems. > - needs constant updates to keep in sync with new unionfs releases > Conceptually, it only needs to be updated when unionfs changes the compilation steps. It is possible to make the script use a default callback when the version number is unrecognized. Also, the script does not really need callbacks for each unionfs version; it was just easier to prototype that way. I am going to upload a new version of the patch and a modified ebuild that patches the official genkernel release. The ebuild worked well enough to build a customized livecd with catalyst.
Created attachment 104749 [details] compressed version of patch This is a compressed version of the patch, with the relative include bug fixed. The naming scheme is used by the ebuild that is also attached.
Created attachment 104750 [details] A modified ebuild This ebuild patches the official genkernel. It also downloads all of the different unionfs tarballs.
Sorry, I like your efforts but I technically disagree with your solution: - unnecessarily complex: a) there aren't enough comments and the ones that are there are not fully comprehensible b) functions' names are not self-explanatory c) the structure of your version detection system is too complex me thinks d) I still prefer to just fix the actual genkernel's scripts and then think about the rest - buggy: a) on the sabayon overlay I have uploaded a brand new version of unionfs that should work with 2.6.19 (needs testing), using that package with genkernel on a 2.6.19-gentoo-r2 kernel simply does not work out of the box - needs constant updates to keep in sync with new unionfs releases a) we need to write code that continue to work with minimal human intervention. Let's keep the discussion open :) One thing is clear, we both want to see genkernel fixed.
Chris has fixed a xkb bug in genkernel 3.4.6: http://bugs.gentoo.org/show_bug.cgi?id=146714 Do you know if 3.4.6 will support unionfs for kernel 2.6.18 ?
No, it doesn't. As I said, I have *zero* plans on updating the unionfs support until a good, elegant solution is created for the fact that upstream unionfs sucks for supporting multiple kernels. Don't expect to see me working on a solution for this, at all. I'd just assume remove unionfs support entirely until a solution that doesn't suck is found.
Thanks god I already forked livecd-tools, so I won't mind forking that too someday :-). I need unionfs or at least the new aufs, that's the matter :P
Please keep your off-topic comments elsewhere. This is a bug report, not a forum.
OK. I've added Fabio's patch, after some slight modification. It isn't what I would call the most elegant solution, but it'll allow me to specify a known-working unionfs with a known-working kernel version for release.
Chris, if you want, I worked out a patch that supports unionfs-utils only. In this case, you'll have to use an in-kernel unionfs "driver". Atm, unionfs 2.0 included in akpm tree does not support addition/removal of branches but I've ported unionfs 1.5 to it, you can see it on sabayon-sources into the sabayon overlay, along with the updated genkernel.
Funny enough, I was actually thinking of something similar. We would build the utilities within genkernel, but require the modules to be built externally, such as via a callback (or built-in to the kernel). I'm not completely sold on the idea, though, as it means yet another thing that adds requirements to the host system for compiling a kernel. Anyway, that's something for another bug in another time.
Created attachment 110079 [details, diff] Unionfs support for genkernel 3.4.6 with PROPER branches management Newer unionfs-utils does not support branches indexes (0,1,2) but we must provide the complete name. This patch add unionfs-utils support to genkernel. unionfs module must be included in the kernel.
Created attachment 110081 [details] genkernel-3.4.6-r4 ebuild with unionfs-utils support
Umm... why are you adding more junk to this bug?
because I'm sure that you are interested in fixing the unionctl thing at least. Please note that you WON'T be able to use "--after 0" ANYMORE!.
Ehh... I'm not concerned with switching to the in-kernel unionfs code support just yet. For now, I'm sticking with building our own modules, since I'm looking at what *Gentoo* supports first. The 3.4.7 release of genkernel will be using the http://bugs.gentoo.org/attachment.cgi?id=100706 patch. Perhaps after that, we can revisit unionfs support in general for another genkernel release (likely 3.5.x)...
I know but read the patch. Please apply this: diff -Nurp genkernel-3.4.6.orig/generic/initrd.scripts genkernel-3.4.6/generic/initrd.scripts --- genkernel-3.4.6.orig/generic/initrd.scripts 2007-02-13 16:03:22.000000000 +0100 +++ genkernel-3.4.6/generic/initrd.scripts 2007-02-13 16:02:11.000000000 +0100 @@ -147,10 +147,12 @@ mount_sysfs() { # $2 = path to data directory # union_insert_dir() { - /sbin/unionctl $1 --add --after 0 --mode ro $2 + # detect branch 0 because newer unionfs doesn't support "0,1,2" + BRANCH_0="/"$(/sbin/unionctl $1 --list | cut -d/ -f2- | cut -d'(' -f1) + /sbin/unionctl $1 --add --after $BRANCH_0 --mode ro $2 if [ $? = '0' ] then - good_msg "Addition of $2 to $1 successful" + good_msg "Addition of $2 to $1 after branch $BRANCH_0 successful" fi } it does not break anything and will always work. read the unionctl manual.
Fixed in 3.4.7_pre3
