Charles Duffy wrote:
Unpacking the initramfs generated by the netboot2 target, the lib links
are as follows:
[EMAIL PROTECTED] /local/ccd/netinst-test/generic_amd64.d $ ls -ld lib*
drwxrwxrwx 4 root root 4096 Jun 8 21:40 lib
lrwxrwxrwx 1 root root 6 Jun 8 21:40 lib64 -> ../lib
There *is* no .. when this is mounted as root, so ../lib does not exist.
More critically, lib does not in the built image contain any files. (It
does have two subdirectories, keymaps/ and modules/; these are populated
normally).
I've built a patch against genkernel to fix the ../lib link to just
point at ./lib (so it's valid even when not the root filesystem), and
opened bug 181376 against it; however, I'm having some trouble getting
that patch to be used: While I'm setting portage_overlay to a location
which is valid on the host, emerge is run within the chroot -- and my
overlay path isn't valid there. How do I work around this issue?
By using a newer version of genkernel. This problem was fixed in 3.4.7.
Second -- In my netboot2/packages/<package>/files, I'm including library
links using paths as they're built by the package, for instance:
netboot2/packages/com_err/files:
/lib64/libcom_err.so
/lib64/libcom_err.so.2
/lib64/libcom_err.so.2.1
/usr/bin/compile_et
/usr/lib64/libcom_err.so
Should I be using /lib/libcom_err.so instead, even though the ebuild
places these files in /lib64? Or is my first priority getting catalyst
to use the corrected genkernel package from my overlay?
You're pretty much in uncharted territory. The netboot2 target is very much
unsupported at this point. It's all still pretty experimental. It's also in a
state of flux and expected to get many changes in the catalyst 2.1 branch.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
