palica

We’d love to help you. To improve your chances of getting an answer, here are some tips:
Search, and research
...and keep track of what you find. Even if you don't find a useful answer elsewhere on the site, including links to related questions that haven't helped can help others in understanding how your question is different from the rest.
Write a title that summarizes the specific problem
The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:
Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.
If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Examples:
Bad: Is there command to do what it needs? Good: How can I apply changes proposed by emerge? Bad: Problem update system Good: Why does the compile of dev-libs/boost-1.63.0 fail with x86_64-pc-linux-gnu-g++: internal compiler error: Killed (program cc1plus)? Introduce the problem before you post any code
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. Here are some guidelines:
Include just enough code to allow others to reproduce the problem. For portage errors include all the relevant info and output. Include all relevant tags
Try to include a tag for the language, library, and specific API your question relates to. If you start typing in the tags field, the system will suggest tags that match what you've typed - be sure and read the descriptions given for them to make sure they're relevant to the question you're asking! See also: What are tags, and how should I use them?
Proof-read before posting!
Now that you're ready to ask your question, take a deep breath and read through it from start to finish. Pretend you're seeing it for the first time: does it make sense? Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question. Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!
Post the question and respond to feedback
After you post, leave the question open in your browser for a bit, and see if anyone comments. If you missed an obvious piece of information, be ready to respond by editing your question to include it. If someone posts an answer, be ready to try it out and provide feedback!
Look for help asking for help
In spite of all your efforts, you may find your questions poorly-received. Don't despair! Learning to ask a good question is a worthy pursuit, and not one you'll master overnight. Here are some additional resources that you may find useful:
Writing the perfect question How do I ask and answer homework questions? How to debug small programs Meta discussions on asking questions How to ask questions the smart way — long but good advice.

We’d love to help you. To improve your chances of getting an answer, here are some tips:
Search, and research
...and keep track of what you find. Even if you don't find a useful answer elsewhere on the site, including links to related questions that haven't helped can help others in understanding how your question is different from the rest.
Write a title that summarizes the specific problem
The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:
Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.
If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Examples:
Bad: Is there command to do what it needs? Good: How can I apply changes proposed by emerge? Bad: Problem update system Good: Why does the compile of dev-libs/boost-1.63.0 fail with x86_64-pc-linux-gnu-g++: internal compiler error: Killed (program cc1plus)? Introduce the problem before you post any code
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. Here are some guidelines:
Include just enough code to allow others to reproduce the problem. For portage errors include all the relevant info and output. Include all relevant tags
Try to include a tag for the language, library, and specific API your question relates to. If you start typing in the tags field, the system will suggest tags that match what you've typed - be sure and read the descriptions given for them to make sure they're relevant to the question you're asking! See also: What are tags, and how should I use them?
Proof-read before posting!
Now that you're ready to ask your question, take a deep breath and read through it from start to finish. Pretend you're seeing it for the first time: does it make sense? Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question. Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!
Post the question and respond to feedback
After you post, leave the question open in your browser for a bit, and see if anyone comments. If you missed an obvious piece of information, be ready to respond by editing your question to include it. If someone posts an answer, be ready to try it out and provide feedback!
Look for help asking for help
In spite of all your efforts, you may find your questions poorly-received. Don't despair! Learning to ask a good question is a worthy pursuit, and not one you'll master overnight. Here are some additional resources that you may find useful:
Writing the perfect question How do I ask and answer homework questions? How to debug small programs Meta discussions on asking questions How to ask questions the smart way — long but good advice.

@ennui sorry don't have access to funtoo infrastructure anymore. you'll have to wait for drobbins to answer this one.

I'm not losing my time anymore with you.
As said, you didn't read or understood the genuine post. Also you just copied and pasted the command I proposed on the first post which obviously doesn't answer any of the questions set out.
By moving to any kit git repo locally one can git ls-remote (or fetch all branches and check them out) and see what branches exists. But What I would like to know if there's any command to see how many or which branches exists for a given kit repo. Also I would like to query a description/definition for the stability associated to those branches.
Unfortunately none of these can be achieved by ego, AFAIK. ego kit -v list|status doesn't show all the existing branches for a given kit repository. Neither describes it's stability.
As example, you should be able to comprehend kde-kit has 3 git branches which are not shown by ego kit, nor a description for its stability:
ego kit -v list /var/git/meta-repo (updated 5 hours 42 minutes ago):  kit                  is active?      branch          stability  kde-kit              active          5.12-prime      prime  
So my questions persists. Is there any way to get this kind of information through system utilities or one should dig into with git commands and then decide which branch suits best reading untrusted sources?
Kind regards,

so you looked at github and explored git locally - no sign of ego kit list here. You wonder if there is a way to do it with ego or any funtoo specific command -> ego kit list
1.3-release will show once you switch to 1.3-release in ego.conf
[global]
release = 1.3
 
the stability tag:
current - tracking gentoo
prime - somehow seen as good for production
anything else - alpha, beta, dev => not good for production if you are not a developer
 

https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature
don't know how much debian backports btrfs fixes (or new features)
changelog here:
https://salsa.debian.org/kernel-team/linux/blob/046a5da6eb748c59f7402d5aae84ab7543dbb396/debian/changelog?expanded=true&viewer=simple
downgrade could be problematic if you use ZSTD as your compression for example, but not limited to this probably.
IMHO - test the downgrade on a separate pc or disk. (and never touch a running system)
at least for those running btrfs this kernel switch should be done with extreme caution.

since the commands from boot-update moved to ego you need to remove boot-update first.
 

Funtoo doesn't support systemd and probably never will.

Supported boot parameters
rollback=<on|yes|1> Do a rollback of specified snapshot. zfs_debug=<on|yes|1> Debug the initrd script zfs_force=<on|yes|1> Force importing the pool. Should not be necessary. zfs=<off|no|0> Don't try to import ANY pool, mount ANY filesystem or even load the module. rpool=<pool> Use this pool for root pool. bootfs=<pool>/<dataset> Use this dataset for root filesystem. root=<pool>/<dataset> Use this dataset for root filesystem. root=ZFS=<pool>/<dataset> Use this dataset for root filesystem. root=zfs:<pool>/<dataset> Use this dataset for root filesystem. root=zfs:AUTO Try to detect both pool and rootfs In all these cases, <dataset> could also be <dataset>@<snapshot>.
Booting from snapshot:
Enter the snapshot for the root= parameter like in this example:
linux /ROOT/funtoo-1@/boot/vmlinuz root=ZFS=rpool/ROOT/funtoo-1@some_snapshot ro boot=zfs $bootfs quiet This will clone the snapshot rpool/ROOT/funtoo-1@some_snapshot into the filesystem rpool/ROOT/funtoo-1_some_snapshot and use that as root filesystem. The original filesystem and snapshot is left alone in this case.
 

yes, I know that one exactly.
...
Once it will be fixed :)

i installed Runit i posted a video in the general discussion section. its really nice!!

https://github.com/haxmeister/funtoo-reporter

glsa-check doesn't provide an up-to-date information for Funtoo. Funtoo also backports lots of security fixes for the forked packages, so the information that you get with --list affected could be inaccurate or wrong.
There is a open bug for glsa-check tool for funtoo
in BFO https://bugs.funtoo.org/browse/FL-3832?jql=text ~ "glsa"
so you can subscribe to the bug and get update once such a tool is ready for funtoo. Until then you will have to check gentoo's GLSA list and check the README.rst in the kit of the package for example here:
https://github.com/funtoo/core-kit/blob/1.0-prime/README.rst
Funtoo also tries to audit forked ebuilds every 30 days. You can see all stale packages on this webpage:
http://ports.funtoo.org/stale/
If you want to help and use any of the packages that are listed as "stale" you can check if they are affected by any know vulnerabilities and report those on https://bugs.funtoo.org where they will be squashed as fast as possible.
Thank you in advance.

changing /etc/boot.conf to this should work
boot { generate grub default "Funtoo Linux genkernel" timeout 3 } "Funtoo Linux" { kernel bzImage[-v] } "Funtoo Linux genkernel" { kernel kernel-debian-sources-x86_64[-v] initrd initramfs-debian-sources-x86_64[-v] params += real_root=auto rootfstype=auto } "memtest86+" { type linux16 kernel /memtest86.bin }  

good

this has to be fixed in the translations, it has been corrected in English original. Since it is a wiki you can edit it yourself. Please do so if you have time to make the experience for all users better.

I would start over from a fresh install. Just backup your data and wipe the partition.
Your processor is Silvermont according to this https://en.wikipedia.org/wiki/List_of_Intel_Pentium_microprocessors#"Bay_Trail-M"_(22_nm) Grab this stage3 from build.funtoo.org - funtoo-current/x86-64bit/intel64-silvermont/2017-12-09/stage3-intel64-silvermont-funtoo-current-2017-12-09.tar.xz these are the settings already active in the stage3 so no need to set them by hand  
add only these settings to the make.conf:
 
run these commands:
 

 
update your system:
 

 
emerge lxde-meta:
 

 
continue the installation according to:
https://www.funtoo.org/Install#Configuring_your_system
report back here how it went
 

We’d love to help you. To improve your chances of getting an answer, here are some tips:
Search, and research
...and keep track of what you find. Even if you don't find a useful answer elsewhere on the site, including links to related questions that haven't helped can help others in understanding how your question is different from the rest.
Write a title that summarizes the specific problem
The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:
Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.
If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Examples:
Bad: Is there command to do what it needs? Good: How can I apply changes proposed by emerge? Bad: Problem update system Good: Why does the compile of dev-libs/boost-1.63.0 fail with x86_64-pc-linux-gnu-g++: internal compiler error: Killed (program cc1plus)? Introduce the problem before you post any code
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. Here are some guidelines:
Include just enough code to allow others to reproduce the problem. For portage errors include all the relevant info and output. Include all relevant tags
Try to include a tag for the language, library, and specific API your question relates to. If you start typing in the tags field, the system will suggest tags that match what you've typed - be sure and read the descriptions given for them to make sure they're relevant to the question you're asking! See also: What are tags, and how should I use them?
Proof-read before posting!
Now that you're ready to ask your question, take a deep breath and read through it from start to finish. Pretend you're seeing it for the first time: does it make sense? Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question. Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!
Post the question and respond to feedback
After you post, leave the question open in your browser for a bit, and see if anyone comments. If you missed an obvious piece of information, be ready to respond by editing your question to include it. If someone posts an answer, be ready to try it out and provide feedback!
Look for help asking for help
In spite of all your efforts, you may find your questions poorly-received. Don't despair! Learning to ask a good question is a worthy pursuit, and not one you'll master overnight. Here are some additional resources that you may find useful:
Writing the perfect question How do I ask and answer homework questions? How to debug small programs Meta discussions on asking questions How to ask questions the smart way — long but good advice.

We’d love to help you. To improve your chances of getting an answer, here are some tips:
Search, and research
...and keep track of what you find. Even if you don't find a useful answer elsewhere on the site, including links to related questions that haven't helped can help others in understanding how your question is different from the rest.
Write a title that summarizes the specific problem
The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:
Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.
If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Examples:
Bad: Is there command to do what it needs? Good: How can I apply changes proposed by emerge? Bad: Problem update system Good: Why does the compile of dev-libs/boost-1.63.0 fail with x86_64-pc-linux-gnu-g++: internal compiler error: Killed (program cc1plus)? Introduce the problem before you post any code
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. Here are some guidelines:
Include just enough code to allow others to reproduce the problem. For portage errors include all the relevant info and output. Include all relevant tags
Try to include a tag for the language, library, and specific API your question relates to. If you start typing in the tags field, the system will suggest tags that match what you've typed - be sure and read the descriptions given for them to make sure they're relevant to the question you're asking! See also: What are tags, and how should I use them?
Proof-read before posting!
Now that you're ready to ask your question, take a deep breath and read through it from start to finish. Pretend you're seeing it for the first time: does it make sense? Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question. Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!
Post the question and respond to feedback
After you post, leave the question open in your browser for a bit, and see if anyone comments. If you missed an obvious piece of information, be ready to respond by editing your question to include it. If someone posts an answer, be ready to try it out and provide feedback!
Look for help asking for help
In spite of all your efforts, you may find your questions poorly-received. Don't despair! Learning to ask a good question is a worthy pursuit, and not one you'll master overnight. Here are some additional resources that you may find useful:
Writing the perfect question How do I ask and answer homework questions? How to debug small programs Meta discussions on asking questions How to ask questions the smart way — long but good advice.

The complete build log is located at '/var/tmp/portage/dev-libs/boost-1.63.0/temp/build.log'. please paste that
What stage3 are you using? arch/subarch and build date.