Jump to content
funtoo forums


Funtoo Linux BDFL
  • Content Count

  • Joined

  • Last visited

  • Days Won


drobbins last won the day on November 25

drobbins had the most liked content!

About drobbins

  • Rank



  • Location
    Albuquerque, NM, USA
  • Interests
    Cycling, Cars, Motorcycle.... Funtoo :)

Recent Profile Visitors

4,474 profile views
  1. Hi Everyone, I"ve posted a new YouTube video which I hope you find useful. Troubleshooting is an important topic and something worth reflecting on.
  2. @ennui AppArmor is enabled again, and for a bit the dovecot mess resurfaced. But I disabled the dovecot profiles this should have already been resolved. If necessary, reboot your container and it should be fine.
  3. I was able to reproduce the issue with pulseaudio not working until I killed it and I restarted. I spent a day trying to figure out why this was and no luck so far. I am wondering if it's an issue related to how steam interfaces with pulseaudio.
  4. GNOME 3.34.1 is ready for use and will become the default version of GNOME in 1.4-release in a few days. If you would like to use it now, you can add the following to /etc/ego.conf: [kits] gnome-kit = 3.34-prime Then ego sync, emerge -auDN @world, emerge @preserved-rebuild, and restart xdm and you should be in business. If you would like to avoid upgrading to GNOME 3.34, now is the time to insert the following code into /etc/ego.conf: [kits] gnome-kit = 3.32-prime Then, in a few days when 3.34-prime becomes active, you will stick with 3.32-prime and not get the updates until you want them.
  5. Also, please, open a bug for this issue on the bug tracker.
  6. Yes, it boots fine for me using UEFI. What hardware are you attempting to boot it on? (Laptop model or motherboard)
  7. @lazlo.vii will be adding persistent games storage (beyond container wipes) at some point. Can you first make sure that the container works with PulseAudio? I do not currently support ALSA. When you are in the container testing glxgears, type "echo $DISPLAY" and make sure it is set to the same value as your regular user outside of the container, and also run "xhost +local:" as your regular user outside of the container. Then see if glxgears will start. I have not reproduced this issue but someone else has, but they did not tell me the root cause of it. So hang tight, should be fixable.
  8. Hi All, I've upgraded our authentication framework, and you should be able to log in. But the migration was not without hiccups. You should be able to log in to forums, wiki, bugs, code.funtoo.org and friends. You might notice that some bugs on bugs.funtoo.org have my name listed as "drobbins#1". This isn't because I think I'm awesome, but because our migration triggered some bad behavior in JIRA and I need to repair its user database. It's annoying, but very fixable, and I'll get to this soon, and should continue to work in the meantime. If you have login issues, please message me privately on the forums, or contact me directly on discord or telegram (links on the main wiki page.)
  9. With the steam container running, use the launcher with the "attach" option to connect to a shell inside the container and try running "glxgears", and debug from there. There is info on the Steam page on the wiki on how to do this.
  10. Steam now has an official launcher script to make it easier to use, called "steam-nvidia-launcher". I've updated the Steam documentation at https://www.funtoo.org/Steam to now direct users to use the launcher script instead. It's easier to use and more robust, as you just have one script that does everything from download the docker image, to create the container, to start the container if it already exists and needs to be started locally. steam-nvidia-launcher also fixes a bug where the Steam container wouldn't start consistently after a reboot. Launcher is available here. Remember to consult the wiki (link above) for usage info: https://code.funtoo.org/bitbucket/users/drobbins/repos/docker-steam/browse/steam-nvidia-launcher
  11. You simply need to eselect python and choose another default python implementation first.
  12. Hi everyone, Since the 1.4 release, we have technically supported running Steam under Funtoo using LXD, docker or chroot, but we didn't really have an official build of Steam or official instructions, so a lot was left to the user and I know this was frustrating for a lot of people. When I realized that Steam setup was an ongoing, painful, still unresolved issue, I started work on an official set of instructions for setting up Steam, and I wasn't happy with the existing documentation out on the Interwebs for getting this set up, so I had to create our own reliable solution for this. The fruit of this effort is that we now have an official Steam Docker image for use on NVIDIA systems, as well as official setup instructions here: https://www.funtoo.org/Steam This is now the *official* way to install Steam on Funtoo. If you use our GNOME stage3, you are 95% of the way to getting Steam up and running, audio and all. If it's not working for you, open a bug, and we'll work on fixing the bug. No longer are you left to try to figure this out on your own or troubleshoot on your own. Also note that getting NVIDIA acceleration in containers working properly is a lot more complex than Open Source drivers. You should expect an Open Source edition of the Docker image to appear soon, along with similar detailed and officially-supported instructions. Enjoy! And let me know how it works (you can post in the Announcements Discussion forum) -Daniel
  13. I've added this documentation on subuids and subgids to the wiki, linked under the main LXD page: https://www.funtoo.org/LXD/What_are_subuids_and_subgids%3F#How_Does_LXD_Use_Subuids.3F
  14. OK, interesting, this means that as you found, the defaults in login.defs are not wonderful. From the useradd man page (see bolded part): SUB_GID_MIN (number), SUB_GID_MAX (number), SUB_GID_COUNT (number) If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate group IDs) allocate SUB_GID_COUNT unused group IDs from the range SUB_GID_MIN to SUB_GID_MAX for each new user. So this means, when you created /etc/subuid, you magically enabled useradd to try to start assigning subuid ranges to new users. And by default, its subuid range conflicts with the one in our LXD docs -- LXD eats up this range. There is no point for useradd to be assigning subuids and subgids to new users it creates by default. It's a cool feature if you need it, I guess, but it should be off by default. So /etc/login.defs should have SUB_GID_COUNT and SUB_UID_COUNT set to 0 by default. Also see bcowan's bug report and my response here: https://bugs.funtoo.org/browse/FL-6773
  • Create New...