lazlo.vii

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

I have version 3.6 installed.

I don't know what I did, but what ever it was it wasn't good. I had to shut it down my server and move it to clean the floor and after booting it back up I noticed my containers were not running. Running /etc/init.d/lxd start: * Starting lxd service ... * start-stop-daemon: /usr/libexec/lxd does not exist [ !! ] * ERROR: lxd failed to start I tried "rc-update del lxd default" and rebooted then "rc-update add lxd default && openrc" Still had the same issue. So then I tried "mkdir /usr/libexec/lxd && openrc" and I got: * Starting lxd service ... [ ok ] lxc list Error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: no such file or directory tail -f /var/log/syslog showed me this: /etc/init.d/lxd[21723]: ERROR: lxd failed to start /etc/init.d/lxd[21771]: start-stop-daemon: failed to exec `/usr/libexec/lxd': Permission denied If I start lxd as root with "lxd --group lxd" I can get my containers but I have to do it in a tmux session so I can leave it running after logging out of ssh. Doing this I am unable to tell any difference from the way my server used to start lxd via openrc. What ever I did wrong was done days or maybe weeks ago. Did I miss configure something? Did I use the wrong option in etc-update? I have tried recompiling lxd, lxc, lxcfs, and cgmanager but it didn't change anything. I am at a loss. What should I look at next?

I did this a while back to set up an AP with hostapd: /etc/conf.d $ cat net.brwlan template="bridge" ipaddr="192.168.0.201/24" gateway="192.168.0.1" nameserver="192.168.0.1" slaves="net.eth0 net.wlan0" stp="on" forwarding=1 with /etc/conf.d $ cat net.eth0 template="interface-noip" and /etc/conf.d $ cat net.wlan0 template="interface-noip"[/code] Now, since you already have an AP I think you could configure net.brwlan to connect to the AP but to be honest I don't know much about it since that is not documented in the networking guide. NetworkManager seems to be the only official way to connect to an AP in Funtoo. If I had to do it I would start with reading up on wpa_supplicant and try to write a bash script to bring the bridge up and and then connect to the AP. Or, I would try to let NetworkManager manage the wifi and then attempt to get my box to just act as a router with no bridging of NICs at all. I don't have a lot of faith in NW though. Unless it has improved greatly in the past 5 years I think it would just get in the way. Have a look at https://wiki.gentoo.org/wiki/Home_router It might give you some ideas. With luck someone that knows the Funtoo networking scripts more intimately than I do can give you a better answer.