cardinal

@cardinal
Thank you much. That worked.

Hi All,
Thanks to funtoo supporters, we now have a new fast download service that is available for everyone. Upgrading to the latest portage-2.3.25_beta2 will enable this service. The fastpull service consists of a lot of different moving parts, but it adds up to distfiles downloading very fast and being available. Here's how it works.
When we regenerate meta-repo and kits, ebuilds are scanned for new SRC_URI tarballs, etc. These new distfiles are queued for download. Our fastpull spider then downloads these distfiles automatically, and uploads them to Google Cloud Storage. When you try to download a SRC_URI, you hit https://fastpull-us.funtoo.org first, which redirects you to the download on fast Google Cloud Storage. The design of fastpull is to ensure that all distfiles are always available going forward. It will also help us to identify situations where for some reason or another we are missing a distfile for download, although these situations should happen less and less frequently (and hopefully disappear) now that fastpull is deployed.
Best,
Daniel Robbins

Arg, I figured it out right after posting this.  I specified my LVM root partition by two different paths, although both of them are valid.
 
In boot.conf I had /dev/mapper/vg1-rootfs
In fstab I had /dev/vg1/rootfs (which is a symbolic link to /dev/mapper/vg1-rootfs)
 
Once I made them the same, boot-update worked.
 
I realized two other mistakes I made, which I would like to point out. 
 
1)  In boot.conf I had this:
kernel kernel[-v] initrd initramfs-genkernel[-v] This does not work because [-v] is not a wildcard like I had thought.  It seems to be a variable which gets its value from the kernel line.  On my system the kernel is 'kernel-debian-sources-x86_64-4.4.6-1'.  So I think [-v] equals '-debian-sources-x86_64-4.4.6-1'.  Boot-update cannot find a match for my initrd line, which would be 'initramfs-genkernel-debian-sources-x86_64-4.4.6-1' -- that file does not exist.  I thought my initrd line would match to initramfs-genkernel-x86_64-4.4.6-1, but I was wrong about that.
 
The other mistake I made is that I do not need the genkernel initramfs at all.  The debian one works fine for an LVM root filesystem.
 
So my files now look like this, and my system is bootable.
 
/etc/boot.conf:
boot { generate grub default "Funtoo Linux genkernel lvm" timeout 3 } "Funtoo Linux genkernel lvm" { kernel kernel[-v] initrd initramfs[-v] params += dolvm real_root=/dev/vg1/rootfs rootfstype=ext4 resume=swap:/dev/mapper/vg1-swap /etc/fstab:
/dev/sda1 /boot ext2 noauto,noatime 1 2 /dev/vg1/swap none swap sw 0 0 /dev/vg1/rootfs / ext4 noatime 0 1 boot-update configures grub.cfg with the following kernel and initrd:
kernel-debian-sources-x86_64-4.4.6-1 initramfs-debian-sources-x86_64-4.4.6-1 Sorry for the noise!

@cardinal
Thanks for that strace, that did help alot!
I noticed one major difference while initializing.  It seems that on my system its using:
/usr/lib/python-exec/python3.4/../../../lib64/python3.4/encodings/ascii.py and on your system its using:
/usr/lib/python-exec/python3.4/../../../lib64/python3.4/encodings/utf_8.py Using ascii instead of utf_8 in python is not completely unexpected on my system since I try to avoid building anything outside en_US locale with ISO-8859-1 encoding.
Later, (on both yours and mine) it reads the file:
/var/git/meta-repo/kits/core-kit/profiles/base/make.defaults In that file, it finds non-ascii (code points >0x7e) characters in the file contents as part of a utf-8 sequence in one of the first author's names in a comment, and mine dies immediately after, because the python ascii parser does not attempt to handle any extended characters and throws exceptions instead.
So this brings up the next question of why my system is using ascii instead of utf_8.  I do have utf-8 support enabled in some places, and I have the referenced "utf_8.py" file (the one yours loaded earlier) in my system, but it's not choosing to load it for some reason.
I guess I'll dig in deeper and see where the rabbit hole leads.  Thanks again cardinal!

Ego no longer changes "gentoo:" to "core-kit:" in profiles
The bug report is closed and the source code on git master is fixed.
I install the ego-9999 live version built using fixed git source code until epro-2.3.4 is released.
funtoo rj # echo "app-admin/ego **" >> /etc/portage/package.accept_keywords/ego funtoo rj # emerge -1a ego  
 

This was very helpful.  Your output...
open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 My output...
open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied) It turns out that /etc/portage/repos.conf/ is owned by root:root.  Presumably, eix is using the portage user, and in combination with my default umask=077, it did not have permission.  It's not a problem for /var/git/meta-repo/ because it is owned by portage:portage.  I had adjusted the permissions of /var/git/meta-repo/ and one point, but never touched /etc/portage/repos.conf/.  Occasionally, umask=077 does lead to some oddities.
I have it working now.
Thank you.

Follow directions here to install/use meta-repo.
Funtoo eliminated stable.
Funtoo users running stable have to upgrade to current.
I had one system running stable that I upgraded to current while still running ports-2012 before switching to meta-repo.
Funtoo in many cases upgrades package versions at a slower rate than gentoo.
On synced meta-repo dev-db/postgresql-10.0-r1
funtoo rj # emerge -av postgresql These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-eselect/eselect-postgresql-2.0-r1::core-kit 0 KiB [ebuild N ] dev-db/postgresql-10.0-r1:10::dev-kit USE="nls pam python readline server ssl xml zlib -doc -kerberos -ldap -libressl -perl (-selinux) -static-libs -systemd -tcl -threads -uuid" LINGUAS="en -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" PYTHON_SINGLE_TARGET="python3_4 -python2_7 -python3_5 -python3_6" PYTHON_TARGETS="python2_7 python3_4 -python3_5 -python3_6" 19,179 KiB Total: 2 packages (2 new), Size of downloads: 19,179 KiB Would you like to merge these packages? [Yes/No]  

The output from this command gives you the subarch for your cpu.
gcc -march=native -Q --help=target | grep march Find the output of -march=  that matches in the right column printed in red here:
http://www.funtoo.org/Subarches#amd64
Click the link to download optimized stage at the beginning of the line where you  find the matching march.
For example if "-march=  amdfam10"
Download http://www.funtoo.org/Amd64-k10
 
 
 
Reference:
http://www.funtoo.org/Install#Installing_the_Stage_3_tarball
http://www.funtoo.org/Subarches

emerge -av =app-admin/ego-1.1.3-r5
ego sync
emerge -avuDN @world

That's how I do it and it's working great for my i7-6700

Build microcode cpio with iucode_tool and load as initrd, If there is a problem disable in the grub menu prior to boot.

Build microcode cpio with iucode_tool and load as initrd, If there is a problem disable in the grub menu prior to boot.

Remove  early_ucode.cpio  from your bootloader configuration.
 
https://wiki.gentoo.org/wiki/Intel_microcode

Thanks Cardinal i solved the problem, there was a asus av66/100/200 option in the kernel menu, i selected that one as module, i recompiled the kernel, rebooted and alsa detected the sound card now.

[ot]
@Cardinal: Never abandon us ... your knowledge is too precious. With so much esteem Sandro [/ot]   :)

Forum search returns no results:https://bugs.funtoo.org/browse/FL-2718

The Master, Headphone, and Speaker controls in the alsamixer picture are muted.
Use the m key while you highlight to toggle them from MM to 00
 
If you require more help use the alsa-info.sh:

wget http://www.alsa-project.org/alsa-info.sh chmod +x alsa-info.sh ./alsa-info.sh Choose y to upload the information.Provide the link to uploaded info in your reply.

This does the trick:
euse -E pulseaudio # enable pulseaudio feature globally # to be sure I also installed alsa-oss. Don't have time to check if it is really necessary. emerge -auDN @world # update and recompile all packages that uses pulseaudio # reboot and run alsamixer to make sure pulseaudio is unmuted. Case closed.

Hello, cardinal!
 
Thank you very much for your attention.

Local patches are applied to the source code only, not the ebuild.
Modified ebuilds go in the local overlay.

cardinal, you save my funtoo box, man!

echo "app-misc/tracker -eds -ffmpeg gstreamer" >> /etc/portage/package.use solve my problem!

Thanks man! Thanks guys!

Use flag eds for tracker-1.6.2 forces reverse dependency for <mail-client/evolution-3.5.3   <gnome-extra/evolution-data-server-3.5.3
Disable eds flag from tracker-1.6.2 should enable world update.

echo "app-misc/tracker -eds" >> /etc/portage/package.use/tracker emerge -avuDN @world Reference: https://forums.gentoo.org/viewtopic-t-1056996-view-previous.html?sid=19f2fb68584a9473e28c1de12a40692b

dev-util/nvidia-cuda-toolkit-6.5.19-r1.ebuild
RDEPEND="${DEPEND}
<sys-devel/gcc-4.9[cxx]

cd xorg-kit List all available branches :
rj@funtoo ~/xorg-kit $ git branch -a * master   remotes/origin/1.17-prime   remotes/origin/HEAD -> origin/master   remotes/origin/gentoo-1.17-snap   remotes/origin/gentoo-1.19-snap   
 
New Ports-2017 tree and Kits
 
For xorg-kit, you will want to check out the 1.17-prime branch. You can keep ports-2017 on the master branch.
1.17-prime is a branch that contains a curated snapshot of xorg 1.17. We have grabbed a snapshot of xorg from Gentoo that we have found particularly stable, and will be adding security backports, bug fixes and feature enhancements -- but without bumping versions of ebuilds. This is equivalent to an 'enterprise grade' version of xorg. If you need to run xorg and just have it work, all the time, and not have it break, you can know that sticking with the 1.17-prime branch will greatly increase your likelihood of this happening. It is what 1.17-prime is designed for. Note the "-prime" extension, which is our way of saying "this is the good stuff" -- the prime cuts of Larry the Cow  ;) 1.17-prime's functionality and hardware support should continue to remain constant -- so that if it works well on your laptop, you can have very good confidence that you can reload your laptop using 1.17-prime and it will continue to work well into the future.
rj@funtoo ~/xorg-kit $ git checkout 1.17-prime Branch 1.17-prime set up to track remote branch 1.17-prime from origin. Switched to a new branch '1.17-prime' rj@funtoo ~/xorg-kit $ git branch * 1.17-prime master Bleeding-edge users will want to use the master branch to get access to all the latest Gentoo goodies:
rj@funtoo ~/xorg-kit $ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. rj@funtoo ~/xorg-kit $ git branch 1.17-prime * master

I forgot to post this in the forums, but make sure you read about Funtoo kits:
 
http://www.funtoo.org/News:New_Ports-2017_tree_and_Kits