walterw

Hi cardinal, My distfiles are downloaded to /var/cache/portage/distfiles as best as I can tell and it is installing genkernel-next-68. I overwrote my logs, so I don't have the original message, but here is my /etc/make.conf (it is automatically generated, so I apologize for all the lines, they're organized by patches): http_proxy="http://localhost:8118" CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=x86-64 -O2 -pipe" CXXFLAGS="-march=x86-64 -O2 -pipe" CPU_FLAGS_X86="mmx mmxext sse sse2" MAKEOPTS="-j5" USE="" VIDEO_CARDS="" SANE_BACKENDS="" LINGUAS="" # kernel USE="${USE} symlink -fortran -openmp acpi" # funtoo-network USE="${USE} -networkmanager" # compression USE="${USE} zlib minizip" # lvm USE="${USE} lvm device-mapper" # permissions USE="${USE} pam caps filecaps" # cups USE="${USE} cups" # ext4 USE="${USE} ext4" # luks USE="${USE} cryptsetup" # zsh USE="${USE} zsh-completion" # english LINGUAS="${LINGUAS} en" # compression USE="${USE} lz4" I could remove the symlink and uninstall the kernel and try to reproduce it? Also, for genkernel, I do have a custom init + scripts, so that could be a potential concern, but I also grepped there and do not see anything that'd point to /usr/share/genkernel/src. The error message was for genkernel-next only and it was after building the kernel and modules. I think it was during the initramfs phase. EDIT: I am building a different system that uses ZFS and as such requires an earlier kernel, interestingly enough, that kernel built just fine along with the initramfs (no error messages about files not being in /usr/share/genkernel/src, and that directory does not exist). The one that built is: 4.14.80 and the one that wasn't was 4.19.1. Now, before I upgraded to 1.3-release, the last time I built the other system, it was actually using the 4.20 kernel, so the portage trees must have been different. Furthermore, the last time I built this system, it was actually using the 4.14.90 kernel. I'll have to investigate in more detail, maybe that will shed some light onto what is really going on.

I am trying to build / install funtoo from a stage 3 tarball using the latest 1.3-release and hitting a snag with kernel compilation. All other packages (from what I can tell) are being properly fetched to /var/cache/portage/distfiles and installed. During the kernel compilation (specifically, when generating the initramfs), I'm getting an error: Could not find source tarball /usr/share/genkernel/src/open-iscsi-2.0-872.tar.gz. Please refetch. This is occurring for any files that are required for the init such as busybox and open-iscsi (which oddly enough should not be in my init), I manually copied a file there to see that it'd resolve it and it did just resolve that single one, but I don't want to do it piece meal. Now, the files are in distfiles (/var/cache/portage/distfiles) and I am thinking I can symlink /usr/share/genkernel/src/ to distfiles, but is that required or is there something else broken that is causing this? I did check the install guide and don't see anything alluding to that. I also grepped /etc for any such configuration also to no avail. EDIT: symlinking /usr/share/genkernel/src to /var/cache/portage/distfiles worked and I was able to install gentoo sources. Thanks, Walter

Will funtoo be tracking upstream automatically or will there still be human intervention (even for current)? Also, along the same lines, I noticed that sometimes I have packages I cannot install because my kits don't have that package version available. Is there a utility that exists to perform that dependency check with the kit to ensure accuracy? I am on master so I would expect that to be manually revised / curated whereas 1.3 release would be automatic?

Thanks - I will wait then.

Thanks - I tried that many times. I also started over with a new stage3. My systems with zfs in them all have this problem, the systems without do not. I have no idea why yet.

Thanks - the bug report is closed, what are the next steps for this?

I am attempting to update my systems and for whatever reason, when running: emerge --newuse -uD world -vp mips-sources is complaining of eapi7-ver: EAPI=5 not supported. I don't have mips-sources installed and I'm on an x86/64 system. Calculating dependencies / * ERROR: sys-kernel/mips-sources-4.13.16::nokit failed (depend phase): * eapi7-ver: EAPI=5 not supported * * Call stack: * ebuild.sh, line 603: Called source '/var/git/meta-repo/kits/nokit/sys-kernel/mips-sources/mips-sources-4.13.16.ebuild' * mips-sources-4.13.16.ebuild, line 27: Called inherit 'eapi7-ver' 'eutils' 'kernel-2' * ebuild.sh, line 294: Called __qa_source '/var/git/meta-repo/kits/core-kit/eclass/eapi7-ver.eclass' - * ebuild.sh, line 79: Called source '/var/git/meta-repo/kits/core-kit/eclass/eapi7-ver.eclass' * eapi7-ver.eclass, line 62: Called die * The specific snippet of code: * die "${ECLASS}: EAPI=${EAPI:-0} not supported";; * * If you need support, post the output of `emerge --info '=sys-kernel/mips-sources-4.13.16::nokit'`, * the complete build log and the output of `emerge -pqv '=sys-kernel/mips-sources-4.13.16::nokit'`. * Working directory: '/usr/lib64/python2.7/site-packages' * S: '/var/tmp/portage/sys-kernel/mips-sources-4.13.16/work/linux--20171007' | * ERROR: sys-kernel/mips-sources-4.9.75::nokit failed (depend phase): * eapi7-ver: EAPI=5 not supported * * Call stack: * ebuild.sh, line 603: Called source '/var/git/meta-repo/kits/nokit/sys-kernel/mips-sources/mips-sources-4.9.75.ebuild' * mips-sources-4.9.75.ebuild, line 27: Called inherit 'eapi7-ver' 'eutils' 'kernel-2' * ebuild.sh, line 294: Called __qa_source '/var/git/meta-repo/kits/core-kit/eclass/eapi7-ver.eclass' * ebuild.sh, line 79: Called source '/var/git/meta-repo/kits/core-kit/eclass/eapi7-ver.eclass' * eapi7-ver.eclass, line 62: Called die * The specific snippet of code: * die "${ECLASS}: EAPI=${EAPI:-0} not supported";; * * If you need support, post the output of `emerge --info '=sys-kernel/mips-sources-4.9.75::nokit'`, * the complete build log and the output of `emerge -pqv '=sys-kernel/mips-sources-4.9.75::nokit'`. - * Working directory: '/usr/lib64/python2.7/site-packages' * S: '/var/tmp/portage/sys-kernel/mips-sources-4.9.75/work/linux--20161216' \ * ERROR: sys-kernel/mips-sources-4.4.110::nokit failed (depend phase): * eapi7-ver: EAPI=5 not supported * * Call stack: * ebuild.sh, line 603: Called source '/var/git/meta-repo/kits/nokit/sys-kernel/mips-sources/mips-sources-4.4.110.ebuild' * mips-sources-4.4.110.ebuild, line 27: Called inherit 'eapi7-ver' 'eutils' 'kernel-2' * ebuild.sh, line 294: Called __qa_source '/var/git/meta-repo/kits/core-kit/eclass/eapi7-ver.eclass' * ebuild.sh, line 79: Called source '/var/git/meta-repo/kits/core-kit/eclass/eapi7-ver.eclass' * eapi7-ver.eclass, line 62: Called die * The specific snippet of code: * die "${ECLASS}: EAPI=${EAPI:-0} not supported";; * * If you need support, post the output of `emerge --info '=sys-kernel/mips-sources-4.4.110::nokit'`, * the complete build log and the output of `emerge -pqv '=sys-kernel/mips-sources-4.4.110::nokit'`. * Working directory: '/usr/lib64/python2.7/site-packages' * S: '/var/tmp/portage/sys-kernel/mips-sources-4.4.110/work/linux--20160123' ... done! Total: 0 packages, Size of downloads: 0 KiB WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: dev-python/urllib3:0 dev-python/urllib3-1.23:0/0::python-modules-kit, ebuild scheduled for merge conflicts with <dev-python/urllib3-1.23[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)] required by dev-python/elasticsearch-py-6.3.0:0/0::python-modules-kit, installed Now, the interesting thing is, I only get this error when updating systems with ZFS, but those ebuilds don't appear to have changed recently. I'm running the default kits, but I also tried updating to 1.2 where possible, but that didn't seem to make any difference.

Hi cafaia, File received, I see it is compressed with gzip. I see that scandelay actually supports no args, it waits 3 seconds by default (when passed as an argument with no parameters) I didn't see anything that stood out, can you try editing /usr/share/genkernel/defaults/linuxrc and adding echo statements throughout to see where it might be occurring, followed by rebuilding the initramfs (and booting up with the modified init)? Then, we can narrow down exactly. Don't forget to backup your original ... Also, share the updated initramfs just so I can see it was updated as expected.

Hi cafaia, If you don't mind, can you post your initramfs? That is the only way I see to troubleshoot this. The other alternative is to look at the source files in /usr/share/genkernel to try and backtrack what is going on there. BTW, I checked my linuxrc (/usr/share/genkernel/defaults/linuxrc), and I don't see an ro option, is that a kernel command-line option? Just for giggles, can you remove that argument?

I masked gentoo-sources > 4.15.0 and rebuilt everything since apparently 4.17 is not ready yet and the newer ZFS ebuilds are not yet available.

Hi cafaia, Hmm, this is an example of what I use, I have a modified initramfs ... linux /kernel-genkernel-x86_64-4.8.7-hardened consoleblank=300 crypt_root=/dev/disk/by-uuid/87f271ea dolvm doluks root=/dev/250.1/root-1 real_root=/dev/250.1/root-1 rootfstype=squashfs scandelay=2 memory tmpfs_size=4G initrd /initramfs-genkernel-x86_64-4.8.7-hardened If you modified your initramfs, please share. If not, please also confirm. It is odd to be getting that message if you haven't modified the initramfs and before openrc starts. In my case, I've gotten a variation before in shell scripts when I'm expecting a variable to be set, but it is not.

I thought scandelay took a numerical argument. I use this to boot off of USB devices because it sometimes takes a second or 2 to see them

I have previously installed ZFS with no issues, but am currently getting: sed: can't read /var/tmp/portage/sys-kernel/spl-9999/work/spl-9999/scripts/check.sh: No such file or directory * ERROR: sys-kernel/spl-9999::core-kit failed (prepare phase): * Cannot patch check.sh I see in the upstream zfsonlinux/spl.git repository that there is indeed no check.sh script - it appears I should be using the spl-0.7.9999.ebuild. However, that is not available in portage in any of the kits (1.0, 1.1, or 1.2).

I am building funtoo root images for a different target architecture than the build system and wondering if that is causing some packages to fail to run. I am starting with a generic subarch: https://www.funtoo.org/Generic_64 And, I modify /etc/make.conf to: CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=x86-64 -O2 -pipe" CXXFLAGS="-march=x86-64 -O2 -pipe" CPU_FLAGS_X86="mmx mmxext sse sse2" I do that to hopefully ensure that gcc won't build for my system which is an i7 and the target systems are a 64-bit Intel Atom and a 64-bit AMD netbook processor. However, I still am unable to run a select few applications as I get invalid opcode during execution (they do run just fine on the system on which I built them). Am I missing a step to build for a different target architecture? I don't believe distcc is required here, but all I really want to do is tell gcc not to use march=native which it prefers to do by default.

Thanks, that fixed it - I followed the gentoo docs and not the funtoo ones.