Bug 152945 - sys-kernel/genkernel: fix unionfs support
|
Bug#:
152945
|
Product: Gentoo Hosted Projects
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: genkernel@gentoo.org
|
Reported By: lxnay@lxnaydesign.net
|
|
Component: genkernel
|
|
|
URL:
http://www.archlinux.org/packages/10670/
|
|
Summary: sys-kernel/genkernel: fix unionfs support
|
|
Keywords: InSVN
|
|
Status Whiteboard:
|
|
Opened: 2006-10-26 23:31 0000
|
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.
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 an attachment (id=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 an attachment (id=102580) [details]
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 an attachment (id=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.
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.
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 an attachment (id=110079) [details]
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.
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.
