commit 8cbef7b58645a7094d46ffc0de4476ca50759267
Author: root <gmt@malth.us>
Date:   Wed Feb 13 02:35:42 2013 -0800

    gen_package.sh: Don't clobber /lib symlinks!!!
    
    Holy shit, was this hard to diagnose.
    
    genkernel is clobbering the /lib symlink in
    gen_kerncache_extract_modules.  I am guessing that, given how
    long this bug has existed, and how subtle the breakage it causes
    can be, clobbered /lib -> /lib64 symlinks, with a mish-mash of
    semi-conflicting files existing between the two, are now rather
    prevalent in all configurations for which /lib is supposed to be
    a symlink (lots obv).
    
    The good news is that due to the nature of the problem and portage,
    something like the following is probably a safe-ish way to resolve the
    problem for most (if they can figure out how to kill enough processes
    to actually run it):
    
    fix_clobbered_lib_symlink_to() {
    	[[ -z $1 ]] && { echo needs argument. >&2 ; return 1 ; }
    	[[ -h /lib ]] && { echo no problem. >&2 ; return 0 ; }
    	[[ -d /lib ]] || { echo not a directory. >&2 ; return 1 ; }
    	to="${1#/}"
    	to="${to%/}"
    	cd /
    	[[ -d "${to}" ]] || {
    		echo "\"${to}\" is not a directory." >&2
    		return 1
    	}
    	rm -rf lib.backup_before_unclobber
    	cp -a lib lib.backup_before_unclobber
    	rm -rf "${to}.backup_before_unclobber"
    	cp -a "${to}" "${to}.backup_before_unclobber"
    	cd /lib
    	while read d ; do
    		d="${d#./}"
    		newd="/${to}/${d}"
    		[[ -d "${newd}" ]] && continue
    		[[ -h "${newd}" ]] && continue
    		[[ -e "${newd}" ]] && {
    			echo "Can't merge $d." >&2
    			return 1
    		}
    		mkdir "${newd}" || return $?
    	done < <( find . -type d \( -name '.' -o -print \) )
    	while read f ; do
    		f="${f#./}"
    		newf="/${to}/${f}"
    		[[ -e "${newf}" ]] && \
    			echo "WARNING: overwriting \"${newf}\"!!" >&2
    		mv -vf "${f}" "${newf}" || return $?
    	done < <( find . -type f )
    	cd /
    	ln -s "${to}" lib.new
    	ls -ld --color=yes /lib.new /lib{,.backup_before_unclobber} \
    		"/${to}"{,.backup_before_unclobber}
    	echo
    	echo /lib now contains $( find /lib -type f | wc -l ) files
    	echo and God knows what other things.  Take a gander and
    	echo then do you-hopefully-know-what....
    	echo
    }
    
    NB: to any googling passers-by: Please note that I have NEVER ONCE
    tested the above script (if it works as-is it's only because
    I've written abridged versions of it so many times on the
    command-line that I now know it by heart).  It could really fuck
    up your system pretty good.  So unless you understand all of the
    above or trust somebody who does, don't even /think/ about running it.
    
    Anyhow perhaps, at this point, to patch things up for everyone,
    something fairly agressive, like the above, should now happen in
    a baselayout rev bump, or even in an initramfs hack of some kind
    so as to avoid forcing people to try to stop udev to resolve this?
    
    Just thinking out loud, because, again, this circumstance causes a
    real cluster-fuck situation that is likely to be hard for some
    users to resolve -- not to mention, notice and/or identify -- on
    their own.  Once they do, the problem of merging the old /lib64 contents
    with the newer /lib contents may have become quite complex, so
    I think a stitch in time could really save 2^3+1 here.
    
    Signed-off-by: Greg Turner <gmt@malth.us>

diff --git a/gen_package.sh b/gen_package.sh
index 3b0c046..395b8a2 100755
--- a/gen_package.sh
+++ b/gen_package.sh
@@ -127,9 +127,9 @@ gen_kerncache_extract_modules()
 		print_info 1 'Extracting kerncache kernel modules'
         	if [ "${INSTALL_MOD_PATH}" != '' ]
 		then
-        		/bin/tar -xjf ${KERNCACHE} -C ${INSTALL_MOD_PATH} lib
+			/bin/tar -xjf ${KERNCACHE} -C ${INSTALL_MOD_PATH} lib/modules
 		else
-        		/bin/tar -xjf ${KERNCACHE} -C / lib
+			/bin/tar -xjf ${KERNCACHE} -C / lib/modules
 		fi
 	fi
 }