Oleg Vinichenko

containers are sharing the host node kernel. Update has to be performed on that servers.

yes, there is a new kernel for the containers.

The new debian-sources-4.14.12 release now available which has the fix for severe security problem, known as meltdown. https://meltdownattack.com/

currently there is no patch for the debian kernels. For tracking: https://security-tracker.debian.org/tracker/CVE-2017-5753 https://security-tracker.debian.org/tracker/CVE-2017-5715 https://security-tracker.debian.org/tracker/CVE-2017-5754 currently, only Wheezy kernels getting a fixes: https://anonscm.debian.org/git/kernel/kernel.git/commit/?h=wheezy-security

ideally the init scripts need migrated. but in reality it should not cause problem. Actually, there is new LVM you can test. 2.02.173, without keywords.

the keywording part is not necessary. its only for the stable users. Can be removed.

no need for additional 32Mb Bios Boot partition. LVM install guide has the examples for fstab and boot-update's boot.conf. You need to change /boot to be vfat instead ext2 LABEL=boot /boot vfat noatime 0 0

for the 2) case, the debian-sources is compiled with initramfs which is created with LVM support by default. So, what you do is just unpack the stage into the volume that holds "/", use correct boot.conf, emerge lvm2 and add it's init script to boot runlevel. For the UEFI you just need additional partition formatted with FAT32. The LVM_Install does not cover this and this bit needs addition, but is as plain simple as having a separate partition with FAT32, rest of partition can be the LVM layout.

the wiki is open, please, correct. the kernel update has to be performed manually with recreation of new initramfs with --zfs argument. This applies for both: kernel update or zfs tools update. This is reflected in wiki. Please, post what exact stage3 you used (with date of stage), so that's it's possible to check what ego version included.

then its likely an UEFI firmware bug or some such issues. I think its worth a try a technical support from ASUS. Search patterns indeed shows that RAM on SABERTOOTH 990FX could be a problem.

are you booting into 32-bit kernel by any chance?

the problem is reported in https://bugs.funtoo.org/browse/FL-4576 the imagemagick-7 support patch is ready which will allow to remove the strict dependency on older imagemagick and hence resolving the conflict.

Merry Christmas everyone! The new debian-sources-4.14.2 release now available and will be the default kernel in stages. We hope it will work good for you. Please, report any inconveniences found with update on bugs.funtoo.org.

paste output of emerge -pvt imagemagick

please, add following into your make.conf CFLAGS="-march=silvermont -mno-aes -O2 -pipe" CXXFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}" FCFLAGS="${CFLAGS}" your cpu does not support AES instruction set.

xorg-1.19 is also default branch :)

notice, that media-kit 1.1-prime branch is the default for couple of days.

looking around what the update could like. it needs newer version of ICU. but yes, bugs.funtoo.org is the correct place for that kind of requests :)

Hi, everyone! We are pleased to announce that media-kit 1.1-prime branch is set as default. After tree update you will notice a bunch of updates to media-related ebuilds.

please report this issue on bugs.funtoo.org

build.funtoo.org is up now

unfortunately there is no 32-bit builds of chromium upstream anymore. and 64-bit during compilation exceeds 2GB, so there actually not much of an option for compiling it from sources. You could try setting I_KNOW_WHAT_I_AM_DOING="1" emerge chromium with at least 4GB of swap enabled. It could pass. Alternatively, consider using precompiled versions such as google-chrome or firefox-bin.

the experimental profile will not do much and it is way behind current build. it used back in the days to test some bleeding versions or some experimental ideas. it is not used now actively but this could change in future.

the compilation stopped due to resource exhaustion, due to lack of RAM or having no swap.

no, there is no need to recompile kernel. Kernel has it's own compilation flags and which are quite specific and not the ones set for sources compilation on your box. generally, it is not recommended to deviate from the default flags. It is good that -O3 mostly work for you. For the rest of ebuilds that do not compile: ideally, those need fixed in source code, however it might be not the task for upstream. You can set specific package environment to have that list compiled with -O2. Here is how: mkdir -p /etc/portage/env create file in that directory called o2.conf (name is example, so you know what's the file about) with following content: CFLAGS="your flags -O2" CXXFLAGS="${CFLAGS}" Then, have following file: /etc/portage/package.env with contents: app-foo/bar o2.conf app-bar/baz o2.conf app-blarg/baroni o2.conf Use real category (app-foo) and package names (bar), those above are just dummy examples. Hope, this is clear.