lazlo.vii

My server has no desktop....

It will only have an effect if: 1.) The code being compiled comes from portage and 2.) The ebuild for that code specifies the use of the CPU_FLAGS. So, no ebuild = no settings from Portage are used by gcc.

CPU_FLAGS used to be standard USE flags until some people that know a lot more about Portage than I do decided that they were tired of having a lot of USE flags for CPU options that could be enabled globally or per package and might have different meanings depending on which package you were talking about. In an effort to stream line the code base and end the confusion they decided that all CPU options would be moved into the CPU_FLAGS settings. I don't think that Portage will care if a CPU_FLAG is included even if no ebuilds use it. I think that they will just be ignored in the same way that Portage ignores invalid USE flags. So if I am right you could add "CPU_FLAGS_X86="12_dozen_hamsters_running_on_wheels" and Portage wouldn't not care, but PETA might.

Hardkernel.com has released the Odroid-H2. It's an SBC based around an Intel Celeron (14nm, 10W TDP) with dual Realtek 1Gb NICs, dual channel DDR4 SODIMM slots, 2 SATA3, and one m.2 NVMe slot. This looks like a fun project with some very serious uses. While I don't need another computer at all I am having to talk myself out of buying one so I don't blow my budget for Christmas. https://www.hardkernel.com/shop/odroid-h2/

I think that Microsoft knows the kind of problems that would be caused if they abused their ownership of GitHub and I think they know beyond a shadow of a doubt what it would cost them: https://www.theregister.co.uk/2018/06/08/nat_friedman_github_ceo_elect_ama_session/ Let's face it, when it comes to freedom, privacy, an open market, and just about every other category of economic threat you can imagine Google/Alphabet/Android/Chrom* is bigger than Microsoft ever was. If Microsoft wants to stop their market share slide (much less regain market dominance) then they need software developers to like them and to work with them.

For a long time I have wanted a simple and secure way to deploy NFS. While there are some options such as Kerberos it's not what I would call easy to set up. This may change based on what I read here: https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-00 I won't claim to understand a lot of what is there. If this becomes the new standard for NFS or even RPC in general could it then be possible to add USE="tls" to a later version of the packages and have it work "out of the box" with a stable and sane default config? If someone has a valid SSL/TLS cert via Let's Encrypt could that same cert be used for encrypting all of their NFS and/or RPC traffic? Thanks for putting up with my questions.

I have changed my mind about the size of LV's and decided to go with 8GB instead of 4GB so I don't have to guess about having enough space in /*/tmp to compile a new kernel. I'll edit this post to add my results when I get done. Hopefully that will be within the next 3 hours. Well, I have run basic tests with defrag and zlib compression and changed RAID back and forth from 0,1, and 10, added large amounts of data, deleted some of it, did it all again, made a few snap shops, deleted them, and so on. I can't find any obvious problems with the usage or functionality of kernel 4.9 on a btrfs filesystem created with newer kernel. I know that data point doesn't make a statistically useful sample, but it does put my mind at ease.

This morning I gave it some thought and decided I will set up a VM with 4x 4GB LV's on my ssd. I still have my copy of SRCD 5.2.2 so I will install in the same manner I used for the host server, which was to just use one drive formatted in btrfs for the install and then convert to RAID10 once the system had been rebooted and the profile set. Once that is done I can switch kernels and see what happens. If I run into any problems because of the switch I will not lose data because it will be a VM and because it is VM I can walk away and leave it paused if need be. If using different versions of the kernel is going to cause issues I think is good way to test for it because I'll end up using one kernel (4.14.32) for the creation of the initial btrfs partition, a second (4.14.12-2) for the creation of the RAID10, and a third (4.9.130) to test scrubbing, compression, rebalancing, and anything else I will have time for. The different SRCD versions and the kernel used in them are listed here if anyone needs them: http://www.system-rescue-cd.org/Changes-x86/ After this test I do not think I will use SRCD any more for installing btrfs based Funtoo systems. A Devuan or Debian livecd seems like a much safer choice.

Thank you for the information. I don't really own another system that fully compares with my server, but I can install Funtoo to a new btrfs partition on my desktop pc, copy over the world file from the server, build the same software, and then try the kernel down grade. It will take some time but might give me a good idea of the kinds of problems I might encounter.

With today's announcement of the upcoming switch to debian-sources-lts I have started thinking about stuff on my server that might be affected. While I want to track as much of the stable Funtoo Portage tree as can I am unsure what affects downgrading the kernel will have. I use btrfs for my RAID10 and that is my main concern. I don't really know what else might be affected because of the huge amount of work that goes into the kernel. I try to keep a my server simple and just install what I need or really want so I don't think it will be a lot. Short of downgrading to debian-sources-lts and testing it right now, is there an easy way to predict some the changes before hand so I be on the look out for trouble?

Call me stupid, but I have to ask: If you have to add a keyword to unmask a package is it really part of the "normal update"? I am not trying to be an asshat. My view of it has always been that the Funtoo Devs (and most people on the forums) know far more about the inner workings of Portage than I do and if they have a package masked, key-worded, or otherwise locked out it's not my place to second guess them. I just don't make a habit of unmasking packages without a very good reason so I don't know if it is considered standard procedure. Maybe I am too conservative in my views and they need adjusting. Maybe this is getting too far off topic since the OP was asking about plex-media-server in one of the overlays...If so please tell me to be quiet.

I have also been on debian-sources 4.14.12 for months. In fact the last time I compiled a kernel was... ~ $ ls -al /boot total 23384 drwxr-xr-x 3 root root 4096 Oct 5 08:14 . drwxr-xr-x 1 root root 162 Aug 29 09:50 .. -rw-r--r-- 1 root root 0 Oct 5 08:14 .keep -rw-r--r-- 1 root root 0 Jul 20 07:39 .keep_sys-apps_baselayout-0 -rw-r--r-- 1 root root 3288058 Aug 20 21:29 System.map-debian-sources-x86_64-4.14.12-2 -rw-r--r-- 1 root root 5125120 Oct 2 12:12 early_ucode.cpio drwxr-xr-x 6 root root 4096 Oct 2 12:12 grub -rw-r--r-- 1 root root 10213136 Aug 20 22:05 initramfs-debian-sources-x86_64-4.14.12-2 -rw-r--r-- 1 root root 5240592 Aug 20 21:29 kernel-debian-sources-x86_64-4.14.12-2 ...August 20th. For the record: ~ $ emerge -pv ="debian-sources-4.14.17" These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS *] sys-kernel/debian-sources-4.14.17:4.14.17::core-kit [4.14.12:4.14.12::core-kit] USE="binary btrfs -zfs" 104,130 KiB Total: 1 package (1 in new slot), Size of downloads: 104,130 KiB The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by =debian-sources-4.14.17 (argument) =sys-kernel/debian-sources-4.14.17 ** NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes.

OK, I have updated and the issue has not come back. Now I just need to recreate a few containers and restore their data (three cheers for backups) which will be a pain in the ass but at least it's working again.

I rolled my filesystem back to a snapshot taken on Oct 8. This was before the update that installed LXD 3.6 and everything started correctly from openrc. Now I just need to install the updates from the past month and hope the issue doesn't resurface.

I have to ask, are you running the command as root or at least using sudo as a non-root user? If not you can't change files in /etc