Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

eyesee

Members
  • Posts

    13
  • Joined

  • Last visited

Posts posted by eyesee

  1. 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.

  2. 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.

  3. 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

  4. 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...

  5. 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.

  6. 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

  7. 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

×
×
  • Create New...