overkill
-
Posts
132 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Blogs
Posts posted by overkill
-
-
Is Funtoo ready for AMD Ryzen CPUs? Does it need GCC 6.X and a 4.11 kernel for full support? I'd like to know before I get a new system.
-
To accomplish what? I've been using gentoo sources with the same cpufreq kernel config for years. Are you trying to get pstates working or update your microcode? I'm not the one who knows how to do either :(
# uname -a Linux kpd 4.4.15-gentoo #1 SMP Mon Jul 18 10:18:41 CDT 2016 x86_64 Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz GenuineIntel GNU/Linux
This is my i5 box, but it's the same config as my i7
-
@ Overkill : then you use in kernel as default the "ondemand" governor ?
@whiteghost : tomorrow i will make other experiments with i7z (01:23 in my town) i go to sleep now.
Thanx :)
Yes, I use on demand. Here you see it at work:
# grep MHz /proc/cpuinfo cpu MHz : 3501.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 1000.000
-
I installed media-fonts/infinality-ultimate-meta and followed the simple instructions on forums.gentoo.org. No more ugly fonts or conflicting rendering settings with eselect fontconfig etc.
https://forums.gentoo.org/viewtopic-t-993030-start-0-postdays-0-postorder-asc-highlight-infinality.html -
I have an Intel i7-4770K and I use the kernel CPU Frequency scaling options without pstates and it works fine. I set the default governor to "ondemand" in the kernel. Each core then idles at 800MHz and scales up as needed.
I have cpupower installed on my system, but don't really need it as the kernel settings do what I desire.
-
If anyone notices that their fonts look much worse recently may want to try masking media-libs/freetype-2.6.5 and rolling back to version 2.6.3-r1. Doing that restored my beautiful, easy on the eyes font rendering.
Any one else having the same issue?
I posted a bug report on the issue - https://bugs.funtoo.org/browse/FL-3268
-
-
-
I did not. I had version 4, but not 4.1 or 4.2. Reconfigured and recompiled kernel. NFS fallback now works as it should.
-
The point is, I'm not specifying vers-4.2, the new nfs-utils is doing that by default. I only exposed the default common by running mount.nfs with the -v (verbose) switch to aid in troubleshooting my issue. As per the man page info I posted above - If a version is specified and fails, it's a permanent failure, where as if no version is specified, it will try 4, then 3 then 2. Apparently it is not doing that. It try's 4.2 and if it fails, no fall back versions are tried.
As far as _netdev option is concerned, I tried both with and without _netdev in my fstab. As long as I specified vers=3, mounting with or without _netdev worked.
-
I also changed my fstab mount options, which were not an issue with the previous versions(s) of nfs-utils, adding _netdev. Works with the 1.2.9-r4 but I still cannot mount the remote shares with >nfs-utils-1.2.9-r. Heres the error when running netmount manually:
# /etc/init.d/netmount start * Mounting network filesystems ... mount.nfs: an incorrect mount option was specified mount.nfs: an incorrect mount option was specified mount.nfs: an incorrect mount option was specified mount.nfs: an incorrect mount option was specified * Could not mount all network filesystems [ !! ] * ERROR: netmount failed to start
Ran mount.nfs manually with my fstab mount info, with the verbose flag:
# mount.nfs -v 192.168.16.244:/volume1/homes/blah /mnt/blah mount.nfs: timeout set for Thu Feb 4 12:14:20 2016 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.16.244,clientaddr=192.168.16.191' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified
Looks like mount.nfs is only trying NFS version 4.2, and not trying any other versions after failing. According to the docs, NFS should keep trying earlier versions after failure. No evidence that is occuring here.
Specifiying "vers=3" and the share is mounted successfully.
# mount.nfs -o vers=3 -v 192.168.16.244:/volume1/homes/blah /mnt/blah mount.nfs: timeout set for Thu Feb 4 12:18:13 2016 mount.nfs: trying text-based options 'vers=3,addr=192.168.16.244' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.16.244 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.16.244 prog 100005 vers 3 prot UDP port 892
It seems that the version fallback feature of NFS it not working for some reason. I'd say it's a bug.
Straight from 'man nfs':
Options supported by all versions These options are valid to use with any NFS version. nfsvers=n The NFS protocol version number used to contact the server's NFS service. If the server does not support the requested version, the mount request fails. If this option is not specified, the client negotiates a suit? able version with the server, trying version 4 first, version 3 second, and version 2 last. vers=n This option is an alternative to the nfsvers option. It is included for compatibility with other operating sys? tems
Adding 'vers=3' to my /etc/fstab nfs mount options solved the problem. -
I configured as the post-install text recommended. It worked after installation, but not after subsequent reboots. I had to revert to the previous version and revert to the previous startup scripts.
With nfs-utils-1.3.2-r6 installed, nfsmount disabled and nfsclient and netmount enable, fstab specified mounts (only two) fail.
# rc-status Runlevel: default netif.eth0 [ started ] netif.tap0 [ started ] netif.tap1 [ started ] netif.br0 [ started ] sysklogd [ started ] ntp-client [ stopped ] ntpd [ started ] netif.eth1 [ started ] numlock [ started ] acpid [ started ] dbus [ started ] nfsclient [ started ] netmount [ stopped ] xdm [ started ] cupsd [ started ] shorewall [ started ] postfix [ started ] sshd [ started ] apcupsd [ started ] udev-postmount [ started ] vixie-cron [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed rpc.pipefs [ started ] lvmetad [ started ] rpcbind [ started ] rpc.statd [ started ] rpc.idmapd [ started ] xdm-setup [ started ] Dynamic Runlevel: manual openrc-settingsd [ started ]
netmount is stopped - trying to restart it manually yields:
# /etc/init.d/netmount start * Mounting network filesystems ... mount.nfs: an incorrect mount option was specified mount.nfs: an incorrect mount option was specified mount.nfs: an incorrect mount option was specified mount.nfs: an incorrect mount option was specified * Could not mount all network filesystems [ !! ] * ERROR: netmount failed to start
Rolling back to nfs-utils-1.2.9-r4 and reverting back to only using nfsmount and everything works perfectly. The NFS shares are on a Synology Disk Station using nfs v3 shares. -
I also experienced the same problem. I masked >net-fs/nfs-utils-1.2.9-r4 and reinstalled. Problem went away. I intended to file a bug report, but I've been extremely busy.
-
P is the "portage" overlay, I = installed
You should read the manual for equery. It's a tool you need to learn if you are going to use funtoo or gentoo.
# man equery
-
You would need to mask any version greater than the desired version.
Use equery to check available versions on your box
# equery l -po konsole * Searching for konsole ... [-P-] [ ] kde-apps/konsole-4.14.3:4/4.14 [-P-] [ ] kde-apps/konsole-4.14.3-r1:4/4.14 [-P-] [ ] kde-apps/konsole-4.14.3-r2:4/4.14 [-P-] [ ] kde-apps/konsole-15.08.3:5
Mask anything greater than your desired version
# echo ">kde-apps/konsole-4.14.3-r2" >> /etc/portage/package.mask
Check again with equery to make sure that there are no typos and the mask is successful. There should be an "M" next to masked versions.
# equery l -po konsole * Searching for konsole ... [-P-] [ ] kde-apps/konsole-4.14.3:4/4.14 [-P-] [ ] kde-apps/konsole-4.14.3-r1:4/4.14 [-P-] [ ] kde-apps/konsole-4.14.3-r2:4/4.14 [-P-] [M ] kde-apps/konsole-15.08.3:5
Now try to install konsole again using the "ask" flag.
# emerge konsole -av
-
On my system, gparted was installed with the btrfs useflag. Reinstalling without btrfs useflag killed all the asciidoc and texlive dependencies. I guess the docs for btrfs needs asciidoc and texlive?
-
Isn't there an overlay for compiz?
-
Systemd no longer being pulled in. Thanks Daniel!
-
I just sync'd one of my funtoo boxes. Looks like gnome-3.16 is ready for installation.... but wait, gnome-3.16 wants to pull in SYSTEMD!!!! Say it ain't so!!!!!
I hope I'm wrong.
... [ebuild U ] gnome-base/gnome-3.16.0:2.0::gentoo [3.14.1:2.0::gentoo] USE="accessibility bluetooth cdr classic cups extras" 0 KiB [blocks B ] sys-fs/eudev ("sys-fs/eudev" is blocking sys-apps/systemd-226-r1, sys-apps/gentoo-systemd-integration-4) [blocks B ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/eudev-3.1.2-r10) [blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/eudev-3.1.2-r10, app-admin/openrc-settingsd-1.0.1) ... -
172.97.103.0/24 is a subblock of 172.103.64.0/18, which is listed on SpamHaus' DROP list (Don't Route Or Peer). Spamhaus has a good reputation so I'd say it's a legit block. You might want to add ACCEPT rules for Funtoo's servers before your BOGON rules if they fall in this range.
Info on Spamhaus' DROP list is here.EDIT: This is pretty serious. Funtoo's IP addresses lie in the subblock 172.97.100.0 - 172.97.103.255, which is registered to Brownrice Internet, Inc. Someone should be actively proding Brownrice to get their subnet out of that block list if at all possible.
-
Funtoo has dev-scheme/termite-0.15 in the current tree, and it depends on gnome-pty-helper-0.38.3
Maybe you haven't really removed the gentoo overlay version of termite?
EDIT: Disregard, wrong termite.
-
Which HDMI port are you plugging into? the HDMI from the integrated intel grapics on the motherboard, or the nVidia HDMI on the graphics card?
Have you tried both?
Did you set your opengl with eselect?
-
Did you already use eselect as root to choose your opengl driver?
# eselect opengl list Available OpenGL implementations: [1] nvidia [2] xorg-x11 * # eselect opengl set 2 Switching to xorg-x11 OpenGL interface... done
-
IRC, the mirrors variable in make.conf is for distfiles, not for the portage tree.
Is Funtoo ready for AMD Ryzen CPUs?
in General Discussion
Posted
Thanks for the info, Oleg. Guess I'll wait a little longer. I hate being an early adopter. BIOS from AMD/motherboard makers still need work as well.