Jump to content
funtoo forums

lazlo.vii

Members
  • Content Count

    25
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by lazlo.vii

  1. lazlo.vii

    feedback (for devs)

    This is where I am at as well. Many times over the last 15 years I have looked at Debian, Ubuntu, and (more recently) Devuan. I always say to myself "I like the stability but I don't need the cruft. I wish I had a distro I could customize and optimize without worrying about stability." Funtoo was as close to that as I could get until 1.3 and now I am hoping that it is a dream come true. Do we need more devs in Funtoo? As long as they are the right devs then sure. I think what might make an even bigger difference is a small group of dedicated documentation writers. Years ago when I worked with Sun Solaris my favorite site on the entire Internet was bigadmin.sun.com but it started to change for the worse when Oracle bought Sun. Fifteen years ago it was hands down the the best FAQ, docs, HowTo, and Cool Projects site any OS had ever seen. Not even the Debian Wiki or the FreeBSD handbook came close. Now it's a shadow of what it once was. Anyway my point is that a high quality OS to will never reach it's full potential if the only people that ever master it's use are those who can read the source code. Should your system have a logger installed and running by default? I think that is a good a idea but it's not a deal breaker. Should sshd be installed and running by default? I think it should be installed but I think there should be a reminder in the install guide to enable it and to create a .shh/authorized_keys file. I think password logins should be disabled by default. Secure remote access is far too important an item to leave out of the default system base.
  2. I was trying not say anything about Steam support. I know you guys are working on it. I ran out of will power though. Egosoft has released the X4: Foundations beta for Linux and so I am dual booting between Funtoo and Xubuntu just to play it. If you need some testing I am willing, I just need instructions for what to do.
  3. lazlo.vii

    USE flags? Why so necessary?

    Dispatch-conf is like a kinder, gentler etc-update.
  4. lazlo.vii

    USE flags? Why so necessary?

    When I did a fresh Funtoo 1.3 install on my desktop PC I just set my profile with epro and installed the KDE meta package and it worked (nearly) flawlessly. I did something like this: #epro flavor desktop # epro mix-ins kde-plasma-5-new # epro mix-ins no-systemd # epro mix-ins gfxcard-nvidia # emerge -vauND --with-bdeps=y @world # (say yes to any USE flag changes) # dispatch-conf # emerge -vauND --with-bdeps=y @world #emerge -va xorg-server nvidia-drivers nvidia-settings # emerge -va plasma-meta # (say yes to any USE flag changes) # dispatch-conf # emerge -va plasma-meta I have zero USE flags set in my make.conf and in package.use I only have what portage added.
  5. lazlo.vii

    Funtoo release model

    I don't know much about Daniel's decision making process or about how ego and Funtoo kits work. What I do know is that I want a stable OS that gives me a large amount of control with minimal effort. No other distro gives us this level of control and stability for this level of effort. I am willing to give up the rolling release model if it helps Daniel perfect the cost/benefit ratios of Funtoo. I don't want to fight with my computer systems, I want to use them. The same is true for my friends, my family, and their businesses. It can take a lot of time and effort to keep a production server stable without worrying about a rolling release model that builds a major system malfunction into the OS every six months. People will put up with a lot of things in life but smart people will not but up with wasted time. Most people won't use Funtoo because they see source based distros as a waste of time. I think addressing those concerns is vital to the future of the Funtoo project if it is going to grow financially. My best guess is that if the project doesn't grow financially it will not expand far beyond what we have now because Daniel needs to feed a family and pay his bills.
  6. lazlo.vii

    Screenshots

    For the first time in several years I am testing Funtoo on my desktop. If I can keep it stable I'll stick with it. Here is my KDE Plasma Desktop:
  7. lazlo.vii

    Adding a few modules to initramfs

    I want to ask a few questions before I take action. I think it's better than asking questions after I have broken my system. 😉 In /etc/genkernel.conf we can add all of the kernel modules to the initramfs by un-commenting the following line: # =========MISC INITRD CONFIGURATION============ # # Copy all kernel modules to the ramdisk #ALLRAMDISKMODULES="1" This seems like it's all or nothing. I just want to add the proprietary Nvidia drivers and the ath9k drivers for my usb WNIC in this case but it could be handy for quite a few other things as well. In Gentoo groups of pre-defined modules can be loaded from /usr/share/genkernel/defaults/modules_load and this file does exist in Funtoo but the related section is missing from /etc/genkernel.conf. Is it safe to enable this in Funtoo? If so I could easily add custom modules from there. If it isn't safe is there a better way to do this?
  8. I really do recommend checking out the Devuan live CD. It has a tool named refactra that will allow you to create a customized Devuan live iso. If you truly want to create your own personal mini-distro you could even use the Devuan Simple Distro Kit (SDK). Unless you are stuck with very limited bandwidth either option will give you a great deal of choice and perhaps help you create the perfect personalized tool kit.
  9. I saw that on distro watch yesterday. I don't think it will affect me much. I started using the Devuan Ascii live CD to do my Funtoo installs. It uses a Debian 4.9 kernel and supports UEFI. If there is anything I need that isn't already installed it's just two apt commands away. In fact the biggest problems are not really problems at all. First /bin/sh points to /bin/dash and second I have to remember to type /usr/sbin/chroot at the correct point during the install.
  10. lazlo.vii

    grub2 doesn't see mdraid by mduuid

    I have never tried to make grub see a RAID created with mdadm. I always keep /boot somewhere off of the RAID. So I don't know if either of these two suggestion will work. 1.) Tell grub to use /dev/sda as it's root. Something like "set root=(hostdisk//dev/sda,msdos1)" in you grub.cfg would work for that. 2.) Try installing grub on the RAID itself: "grub-install --boot-directory=/boot/ --modules='part_msdos mdraid1x' /dev/md127" Honestly though, I am not really sure that will work. For easy recovery in the event of catastrophic error I have learned the hard way (HINT: Don't make typos when executing a wipefs command) that having /boot accessible without any bells and whistles is the best way to go.
  11. lazlo.vii

    Screenshots

    OK, I finally got around to adding a desktop to my server:
  12. 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.
  13. lazlo.vii

    Explicit setting CPU_FLAGS_X86 for Skylake Xeon E3 v5

    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.
  14. lazlo.vii

    Explicit setting CPU_FLAGS_X86 for Skylake Xeon E3 v5

    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.
  15. lazlo.vii

    A new Odroid x86_64 SBC

    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/
  16. lazlo.vii

    Why Funtoo is not migrating on GitLab ?

    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.
  17. 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?
  18. lazlo.vii

    A quick question of the upcoming kernel switch.

    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.
  19. lazlo.vii

    A quick question of the upcoming kernel switch.

    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.
  20. lazlo.vii

    A quick question of the upcoming kernel switch.

    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.
  21. lazlo.vii

    Seems like everything's stuck

    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.
  22. lazlo.vii

    Seems like everything's stuck

    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.
  23. 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?
  24. 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.
  25. 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.
×