eyesee

That's good news ? And yes, thanks so much to everyone for the incredible job of making a systemd-free distro possible!

I totally agree to that statement and it is a good question. I hope Funtoo will still work in future without systemd.

I did some test runs regarding building a customized Funtoo live cd. The Devuan live-sdk looks nice and clean but it works only with zsh and I could not get it fully working. The Are31 live cd also looks promising and I gonna play around a bit more. Nice work done with that! Just wondering what a minimal sized live cd of that would be ? Interestingly I stumbled upon another project (https://github.com/ivandavidov/minimal) which produces quite small live cds of around 10MB. It is limited by default to BusyBox, Dropbear, etc. Seems also to work in Docker. Perhaps it would make sense to customize something like this for a minimal footprint.

I saw it two days ago. SysRescueCD until 5.3.2 is good so far for me bootstrapping Funtoo from stage3. It is annoying they moved to a Systemd-based distribution now. I will have a look at the Are31 LiveCD. As I do not need a window manager there is the question to me if it really needs to be 1,4GB in size. SysrescueCD 5.3.2 is just around 585 MB. A minimal console only version would be sufficient to me. Just enough to wget, tar and chroot for bootstrapping Funtoo.

Well, that would have been too easy ? Nice that you could solve it by yourself!

Hi jho! Just by looking at your Jenkins startup command: looks like you set the minimum RAM size to 40966 MB, but this should probably 4096M... Cheers, eyesee

Hej! Good it worked for you so far! ? I can imagine VirtualBox source ebuild or the installed guest additions have some issues. As said, I remember having problems with the source package on my Intel system too. But I have not investigated any further yet due to lack of time. I just switched to the binary package and that worked for me. So unfortunately I can not tell if this is a Threadripper related problem. I hope someone else can help you better than me. Perhaps you should consider writing a bug report on the Funtoo bug tracker. By the end of year I will also retry installing from sources. Cheers

Well, I remember I also once had problems with VirtualBox so I decided to switch to the binary package (virtualbox-bin). I also have just the virtualbox-modules installed, both in version 5.2.22 from portage. It might be worth a try, so if you uninstall everything related to Virtualbox and just emerge virtualbox-bin and virtualbox-modules I hope you will succeed. As a sidenote it is the case that in virtualbox-bin the executables changed from lowercase to camelcase. The additions can be installed manually from the UI, as said no need to do this with portage. However, as I do not have a AMD Ryzen system the problem might be something completely different...

Thanks for clarification, Oleg!

Ok, then I assume at least no negative effect when enabling the provided additional cpu flags from cpuid2cpuflags, as I assume those reflect the actual cpu capabilities, no matter whether those are respected by an ebuild or not. I will see latest when my computers are on fire... Thank you!

Well, thanks for your response! I know about the confusion of regular USE flags which could be handled differently depending on package. But CPU_FLAGS are probably more determined how these affect the resulting binary. Still the question for me is if modifying these flags has any benefit with the goal to squeeze ou the last bit of the processor capabilities... And yes, I know not every package will make use of the provided flags. For at least GCC I can imagine it possibly could have an effect.

Recently I fell into the trap having march=skylake in my CFLAGS which is not really supported by GCC 7. Now I have fixed this by setting CFLAGS march option to broadwell which makes sense and works so far. Thanks to all the people involved doing the hard work on that beast! To squeeze out the last bit of my CPU I wonder if it makes sense to adjust the CPU_FLAGS_X86 setting to the output I am getting from the cpuid2cpuflags tool. The output I am getting does differ from the recommendation on the subarches wiki page for skylake and the given x86-64bit make.defaults for Intel Skylake. Could the output be different because I have a Xeon E3 instead of an iCore 3/5/7? My ego profile shows the following: arch: x86-64bit build: current subarch: intel64-skylake The basic CPU_FLAGS_X86 option for Intel Skylake is according to the Subarches page: aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 make.defaults for x86-64-bit Intel skylake contains the following (difference underlined): aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 cpuid2cpuflags for my Xeon E3 v5 states there is another option available (difference underlined): aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 It seems like f16c and pclmul are not used in many packages explicitly. But I am also compiling non-ebuild stuff and some stuff from my own overlay. In general I have not that much insight how CPU flags are used and I do not know if the compilation of GCC with those additional flags would automagically improve compilation results in general. So my question is: would it be of any benefit to modify the CPU_FLAGS_X86 flag to reflect what cpuid2cpuflags spits out? Thanks! eyesee

At least it works for me. Have you read the notice on bugs.funtoo.org? You should go to https://auth.funtoo.org/login and upgrade your account. See also https://forums.funtoo.org/topic/1803-important-upgrade-your-funtoo-account/

Hi Checko, just guessing that it might help to rename your preferences folder for Virtualbox, e.g. mv ~/.VirtualBox ~/.VirtualBox.bak On the next start of VirtualBox it will get recreated. Possibly the autogenerated files compreg.dat and xpti.dat could be causing issues if you had the wrong guest additions installed. And, you can alternatively install the guest additions manually in the UI. No need to do it with emerge if that does not work. Cheers, eyesee

I also ran into this issue. Have you also check correct ownership? It should be the user portage in group portage for /var/cache/eix and everything inside.