Re: [gentoo-user] flag icu
On 08/13/18 13:14, Corentin �Nado� Pazdera wrote: > August 13, 2018 6:58 PM, "james" wrote: > >> Here's what I got running your script:: >> >> /etc # /root/profile-explorer.sh >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/base/packages >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/baselayout-2 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/findutils-4.4 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-devel/patch-2.7 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/default/linux/packages >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/base/packages >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/baselayout-2 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/findutils-4.4 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-devel/patch-2.7 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/default/linux/packages >> >> Manually looking a the > > Seems weird, also no need to run it as root... > Here's my output for comparison : > > ``` > % ./profile-explorer.sh > [+] EROOT : / > [+] PORTDIR : /var/db/repos/gentoo > [+] CURPROFILE: default/linux/amd64/17.0 > [+] EAPI : 5 > > [+] packages (@system) > /var/db/repos/gentoo/profiles/base/packages > /var/db/repos/gentoo/profiles/default/linux/packages > ``` > > And the `explored-packages` file should symply contain a copy of the > different inherited packages > files. > >> less /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/base/packages >> >> I see: >> # Old ICU is unsupported. ICU 58 only remains for 13.0 based profiles. >> > > >> But the system has:: >> >> [I] dev-libs/icu 60.2 >> >> equery uses icu >> >> gives me similar info: >> >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/base/packages >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/baselayout-2 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/findutils-4.4 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-devel/patch-2.7 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/default/linux/packages >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/base/packages >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/baselayout-2 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-apps/findutils-4.4 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> *>=sys-devel/patch-2.7 >> --- Invalid atom in /etc/portage/package.use/explored-packages: >> /usr/portage/profiles/default/linux/packages >> [ Legend : U - final flag setting for installation] >> [ : I - package is installed with flag ] >> [ Colors : set, unset ] >> * Found these USE flags for dev-libs/icu-60.2: >> U I >> + + abi_x86_32 : 32-bit (x86) libraries >> - - debug : Enable extra debug codepaths, like asserts and extra >> output. If >> you want to get meaningful backtraces see >> >> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces >> - - doc : Add extra documentation (API, Javadoc, etc). It is >> recommended to >> enable per package instead of globally >> + + examples : Install examples, usually source code >> - - static-libs : Build static versions of dynamic libraries as well >> >> Which begs the Q1} can I get rid of the flag icu? What are >> consequences, as a baseline system flag, of it's removal ? >> >> less /usr/portage/profiles/base/packages >> show me more of what the @system set contains. Very interesting and >> useful. I'm thinking of aggregation of those listed packages >> and some basic (ascii) table form (equery,emerge, eix) parsed listing >> of the default and current flag settings. A "verification" tool >> if you like. Surely it would help if this info was (is?) more readily >> available and organized for folks that need a systematic approach, like >> heterogeneous HPC clusters. The tools exist for 'ad-hoc' and one off, >> but more of an organized representation at least at the set level. >> >> I feel like there is an existing tool that can yield all of this >> information, as it is on a current system. I've read where there are >> efforts to clean up the packages and default flags used in @system, >> so the bare minimum list per arch/profiles would ultimately be >> a useful listing, particular for my HPC. In HPC less is always faster >> and better, as it is in security and so many more aspects of CS. >> >> Obviosly, I have a few things to fix on this (fragile) system, but >> that'll happen as I'm at the beginning stages of auto_installs of >>
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/15 08:13, Nikos Chantziaras wrote: > On 15/08/18 18:45, tu...@posteo.de wrote: > > > > I put nvidia-uvm explictly into /etc/conf.d/modules - which was not > > necessary ever beforeand it shows the same problems: No cuda > > devices. > > > > I think I will dream this night of no cuda devices... ;( > > Or you might want to use the LTS (Long Term Support) driver series for now, > which is 390.x (390.77 being the latest of that series.) > > You can see what the latest LTS series is by going here: > > https://nvidia.com/drivers > > Select your GPU and "Linux 64-bit" and click search. This will tell you what > the currently recommended "stable" driver is. > > And the show must go on: Secure Connection Failed An error occurred during a connection to nvidia.com. Peer attempted old style (potentially vulnerable) handshake. Error code: SSL_ERROR_UNSAFE_NEGOTIATION The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. Learn more… Report errors like this to help Mozilla identify and block malicious sites Sigh...
[gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 15/08/18 18:45, tu...@posteo.de wrote: I put nvidia-uvm explictly into /etc/conf.d/modules - which was not necessary ever beforeand it shows the same problems: No cuda devices. I think I will dream this night of no cuda devices... ;( Or you might want to use the LTS (Long Term Support) driver series for now, which is 390.x (390.77 being the latest of that series.) You can see what the latest LTS series is by going here: https://nvidia.com/drivers Select your GPU and "Linux 64-bit" and click search. This will tell you what the currently recommended "stable" driver is.
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
August 15, 2018 5:45 PM, tu...@posteo.de wrote: > I put nvidia-uvm explictly into /etc/conf.d/modules - which was not > necessary ever beforeand it shows the same problems: No cuda > devices. > > I think I will dream this night of no cuda devices... ;( > > On 08/15 05:11, tu...@posteo.de wrote: > >> On 08/15 02:32, Corentin “Nado” Pazdera wrote: >> August 15, 2018 2:59 PM, tu...@posteo.de wrote: > > Yes I did reboot the sustem. In my initial mail I mentioned a tool > called CUDA-Z and Blender, which both reports a missing CUDA device. >> Ok, so you do not have a specific error which might have been thrown by the >> module? >> Other ideas, check dev-util/nvidia-cuda-toolkit version and double check >> nvidia/nvidia_uvm with >> modinfo to ensure they are installed and loaded correctly with the right >> version? >> Could you also run /opt/cuda/extras/demo_suite/deviceQuery (from >> nvidia-cuda-toolkit) and show its >> output? >> >> My installation works, so at least we know their version is not completely >> broken... >> Driver version: 396.51 >> Cuda version: 9.2.88 >> >> -- >> Corentin “Nado” Pazdera >> >> I compiled the new version of the driver again and rebooted the >> system. >> >> # dmesg | grep -i nvidia: >> >> [ 11.375631] nvidia_drm: module license 'MIT' taints kernel. >> [ 12.313260] nvidia-nvlink: Nvlink Core is being initialized, major device >> number 246 >> [ 12.313586] nvidia :07:00.0: vgaarb: changed VGA decodes: >> olddecodes=io+mem,decodes=none:owns=io+mem >> [ 12.313691] nvidia :02:00.0: enabling device ( -> 0003) >> [ 12.313737] nvidia :02:00.0: vgaarb: changed VGA decodes: >> olddecodes=io+mem,decodes=none:owns=none >> [ 12.313826] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 396.51 Tue Jul >> 31 10:43:06 PDT 2018 >> (using threaded interrupts) >> [ 12.491106] input: HDA NVidia HDMI as >> /devices/pci:00/:00:0b.0/:02:00.1/sound/card2/input9 >> [ 12.492291] input: HDA NVidia HDMI as >> /devices/pci:00/:00:0b.0/:02:00.1/sound/card2/input10 >> [ 12.493772] input: HDA NVidia HDMI as >> /devices/pci:00/:00:02.0/:07:00.1/sound/card1/input11 >> [ 12.494605] input: HDA NVidia HDMI as >> /devices/pci:00/:00:02.0/:07:00.1/sound/card1/input12 >> [ 13.963644] caller _nv001112rm+0xe3/0x1d0 [nvidia] mapping multiple BARs >> [ 34.236553] caller _nv001112rm+0xe3/0x1d0 [nvidia] mapping multiple BARs >> [ 34.516495] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for >> UNIX platforms 396.51 >> Tue Jul 31 14:52:09 PDT 2018 >> >> # modprobe -a nvidia-uvm >> >> # dmesg | grep uvm >> >> [ 209.441956] nvidia-uvm: Loaded the UVM driver in 8 mode, major device >> number 245 >> >> # /opt/cuda/extras/demo_suite/deviceQuery >> /opt/cuda/extras/demo_suite/deviceQuery Starting... >> >> CUDA Device Query (Runtime API) version (CUDART static linking) >> >> cudaGetDeviceCount returned 30 >> -> unknown error >> Result = FAIL >> [1] 5086 exit 1 /opt/cuda/extras/demo_suite/deviceQuery >> >> CUDA-Z shows also "no CUDA device" >> >> # modinfo nvidia-uvm >> filename: /lib/modules/4.18.0-RT/video/nvidia-uvm.ko >> supported: external >> license: MIT >> depends: nvidia >> name: nvidia_uvm >> vermagic: 4.18.0-RT SMP preempt mod_unload >> parm: uvm_perf_prefetch_enable:uint >> parm: uvm_perf_prefetch_threshold:uint >> parm: uvm_perf_prefetch_min_faults:uint >> parm: uvm_perf_thrashing_enable:uint >> parm: uvm_perf_thrashing_threshold:uint >> parm: uvm_perf_thrashing_pin_threshold:uint >> parm: uvm_perf_thrashing_lapse_usec:uint >> parm: uvm_perf_thrashing_nap_usec:uint >> parm: uvm_perf_thrashing_epoch_msec:uint >> parm: uvm_perf_thrashing_max_resets:uint >> parm: uvm_perf_thrashing_pin_msec:uint >> parm: uvm_perf_map_remote_on_native_atomics_fault:uint >> parm: uvm_hmm:Enable (1) or disable (0) HMM mode. Default: 0. Ignored if >> CONFIG_HMM is not set, or >> if NEXT settings conflict with HMM. (int) >> parm: uvm_global_oversubscription:Enable (1) or disable (0) global >> oversubscription support. (int) >> parm: uvm_leak_checker:Enable uvm memory leak checking. 0 = disabled, 1 = >> count total bytes >> allocated and freed, 2 = per-allocation origin tracking. (int) >> parm: uvm_force_prefetch_fault_support:uint >> parm: uvm_debug_enable_push_desc:Enable push description tracking (int) >> parm: uvm_page_table_location:Set the location for UVM-allocated page >> tables. Choices are: vid, >> sys. (charp) >> parm: uvm_perf_access_counter_mimc_migration_enable:Whether MIMC access >> counters will trigger >> migrations.Valid values: <= -1 (default policy), 0 (off), >= 1 (on) (int) >> parm: uvm_perf_access_counter_momc_migration_enable:Whether MOMC access >> counters will trigger >> migrations.Valid values: <= -1 (default policy), 0 (off), >= 1 (on) (int) >> parm: uvm_perf_access_counter_batch_count:uint >> parm: uvm_perf_access_counter_granularity:Size of the physical memory region >> tracked by each >> counter. Valid values
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
I put nvidia-uvm explictly into /etc/conf.d/modules - which was not necessary ever beforeand it shows the same problems: No cuda devices. I think I will dream this night of no cuda devices... ;( On 08/15 05:11, tu...@posteo.de wrote: > On 08/15 02:32, Corentin “Nado” Pazdera wrote: > > August 15, 2018 2:59 PM, tu...@posteo.de wrote: > > > > > Yes I did reboot the sustem. In my initial mail I mentioned a tool > > > called CUDA-Z and Blender, which both reports a missing CUDA device. > > > > Ok, so you do not have a specific error which might have been thrown by the > > module? > > Other ideas, check dev-util/nvidia-cuda-toolkit version and double check > > nvidia/nvidia_uvm with modinfo to ensure they are installed and loaded > > correctly with the right version? > > Could you also run /opt/cuda/extras/demo_suite/deviceQuery (from > > nvidia-cuda-toolkit) and show its output? > > > > My installation works, so at least we know their version is not completely > > broken... > > Driver version: 396.51 > > Cuda version: 9.2.88 > > > > -- > > Corentin “Nado” Pazdera > > > > I compiled the new version of the driver again and rebooted the > system. > > # dmesg | grep -i nvidia: > > [ 11.375631] nvidia_drm: module license 'MIT' taints kernel. > [ 12.313260] nvidia-nvlink: Nvlink Core is being initialized, major device > number 246 > [ 12.313586] nvidia :07:00.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=io+mem > [ 12.313691] nvidia :02:00.0: enabling device ( -> 0003) > [ 12.313737] nvidia :02:00.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=none > [ 12.313826] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 396.51 Tue > Jul 31 10:43:06 PDT 2018 (using threaded interrupts) > [ 12.491106] input: HDA NVidia HDMI as > /devices/pci:00/:00:0b.0/:02:00.1/sound/card2/input9 > [ 12.492291] input: HDA NVidia HDMI as > /devices/pci:00/:00:0b.0/:02:00.1/sound/card2/input10 > [ 12.493772] input: HDA NVidia HDMI as > /devices/pci:00/:00:02.0/:07:00.1/sound/card1/input11 > [ 12.494605] input: HDA NVidia HDMI as > /devices/pci:00/:00:02.0/:07:00.1/sound/card1/input12 > [ 13.963644] caller _nv001112rm+0xe3/0x1d0 [nvidia] mapping multiple BARs > [ 34.236553] caller _nv001112rm+0xe3/0x1d0 [nvidia] mapping multiple BARs > [ 34.516495] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for > UNIX platforms 396.51 Tue Jul 31 14:52:09 PDT 2018 > > # modprobe -a nvidia-uvm > > # dmesg | grep uvm > > [ 209.441956] nvidia-uvm: Loaded the UVM driver in 8 mode, major device > number 245 > > > # /opt/cuda/extras/demo_suite/deviceQuery > /opt/cuda/extras/demo_suite/deviceQuery Starting... > > CUDA Device Query (Runtime API) version (CUDART static linking) > > cudaGetDeviceCount returned 30 > -> unknown error > Result = FAIL > [1]5086 exit 1 /opt/cuda/extras/demo_suite/deviceQuery > > CUDA-Z shows also "no CUDA device" > > # modinfo nvidia-uvm > filename: /lib/modules/4.18.0-RT/video/nvidia-uvm.ko > supported: external > license:MIT > depends:nvidia > name: nvidia_uvm > vermagic: 4.18.0-RT SMP preempt mod_unload > parm: uvm_perf_prefetch_enable:uint > parm: uvm_perf_prefetch_threshold:uint > parm: uvm_perf_prefetch_min_faults:uint > parm: uvm_perf_thrashing_enable:uint > parm: uvm_perf_thrashing_threshold:uint > parm: uvm_perf_thrashing_pin_threshold:uint > parm: uvm_perf_thrashing_lapse_usec:uint > parm: uvm_perf_thrashing_nap_usec:uint > parm: uvm_perf_thrashing_epoch_msec:uint > parm: uvm_perf_thrashing_max_resets:uint > parm: uvm_perf_thrashing_pin_msec:uint > parm: uvm_perf_map_remote_on_native_atomics_fault:uint > parm: uvm_hmm:Enable (1) or disable (0) HMM mode. Default: 0. > Ignored if CONFIG_HMM is not set, or if NEXT settings conflict with HMM. (int) > parm: uvm_global_oversubscription:Enable (1) or disable (0) global > oversubscription support. (int) > parm: uvm_leak_checker:Enable uvm memory leak checking. 0 = > disabled, 1 = count total bytes allocated and freed, 2 = per-allocation > origin tracking. (int) > parm: uvm_force_prefetch_fault_support:uint > parm: uvm_debug_enable_push_desc:Enable push description tracking > (int) > parm: uvm_page_table_location:Set the location for UVM-allocated > page tables. Choices are: vid, sys. (charp) > parm: uvm_perf_access_counter_mimc_migration_enable:Whether MIMC > access counters will trigger migrations.Valid values: <= -1 (default policy), > 0 (off), >= 1 (on) (int) > parm: uvm_perf_access_counter_momc_migration_enable:Whether MOMC > access counters will trigger migrations.Valid values: <= -1 (default policy), > 0 (off), >= 1 (on) (int) >
Re: [gentoo-user] Is this a portage bug?
On Wednesday, 15 August 2018 12:45:05 BST Franz Fellner wrote: > I think that's the way "equery w" works: > >> Display the path to the ebuild that would be used by Portage with the > > current configuration. << > With your current configuration there is no package matching your query. > > Alternatives for future use in such cases: > ❯ epkginfo -k kyocera-1x2x-mfp-driver > * net-print/kyocera-1x2x-mfp-driver [gentoo] > 1.1203-r1:0: ~amd64 -* > > ❯ equery y kyocera-1x2x-mfp-driver > > Keywords for net-print/kyocera-1x2x-mfp-driver: > | a | | > | m | | > | d x | | > | 6 8 | | > | 4 6 | u | > | > | a a a p s | | | n | > | l m r i p h m s p f m f | e u s | r > | p d a m a p c x p 6 3 a b i b | a s l | e > | h 6 r 6 6 p 6 8 p 8 9 s r s p s | p e o | p > | a 4 m 4 4 c 4 6 a k 0 h c d s d | i d t | o > > --+-+---+--- > > 1.1203-r1 | * ~ * * * * * * * * * * * * * * | 6 o 0 | gentoo Well, they do say you learn something new every day - if you're not careful. Thanks all for the lesson, and Franz for the ideas. -- Regards, Peter.
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/15 02:32, Corentin “Nado” Pazdera wrote: > August 15, 2018 2:59 PM, tu...@posteo.de wrote: > > > Yes I did reboot the sustem. In my initial mail I mentioned a tool > > called CUDA-Z and Blender, which both reports a missing CUDA device. > > Ok, so you do not have a specific error which might have been thrown by the > module? > Other ideas, check dev-util/nvidia-cuda-toolkit version and double check > nvidia/nvidia_uvm with modinfo to ensure they are installed and loaded > correctly with the right version? > Could you also run /opt/cuda/extras/demo_suite/deviceQuery (from > nvidia-cuda-toolkit) and show its output? > > My installation works, so at least we know their version is not completely > broken... > Driver version: 396.51 > Cuda version: 9.2.88 > > -- > Corentin “Nado” Pazdera > I compiled the new version of the driver again and rebooted the system. # dmesg | grep -i nvidia: [ 11.375631] nvidia_drm: module license 'MIT' taints kernel. [ 12.313260] nvidia-nvlink: Nvlink Core is being initialized, major device number 246 [ 12.313586] nvidia :07:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [ 12.313691] nvidia :02:00.0: enabling device ( -> 0003) [ 12.313737] nvidia :02:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [ 12.313826] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 396.51 Tue Jul 31 10:43:06 PDT 2018 (using threaded interrupts) [ 12.491106] input: HDA NVidia HDMI as /devices/pci:00/:00:0b.0/:02:00.1/sound/card2/input9 [ 12.492291] input: HDA NVidia HDMI as /devices/pci:00/:00:0b.0/:02:00.1/sound/card2/input10 [ 12.493772] input: HDA NVidia HDMI as /devices/pci:00/:00:02.0/:07:00.1/sound/card1/input11 [ 12.494605] input: HDA NVidia HDMI as /devices/pci:00/:00:02.0/:07:00.1/sound/card1/input12 [ 13.963644] caller _nv001112rm+0xe3/0x1d0 [nvidia] mapping multiple BARs [ 34.236553] caller _nv001112rm+0xe3/0x1d0 [nvidia] mapping multiple BARs [ 34.516495] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 396.51 Tue Jul 31 14:52:09 PDT 2018 # modprobe -a nvidia-uvm # dmesg | grep uvm [ 209.441956] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 245 # /opt/cuda/extras/demo_suite/deviceQuery /opt/cuda/extras/demo_suite/deviceQuery Starting... CUDA Device Query (Runtime API) version (CUDART static linking) cudaGetDeviceCount returned 30 -> unknown error Result = FAIL [1]5086 exit 1 /opt/cuda/extras/demo_suite/deviceQuery CUDA-Z shows also "no CUDA device" # modinfo nvidia-uvm filename: /lib/modules/4.18.0-RT/video/nvidia-uvm.ko supported: external license:MIT depends:nvidia name: nvidia_uvm vermagic: 4.18.0-RT SMP preempt mod_unload parm: uvm_perf_prefetch_enable:uint parm: uvm_perf_prefetch_threshold:uint parm: uvm_perf_prefetch_min_faults:uint parm: uvm_perf_thrashing_enable:uint parm: uvm_perf_thrashing_threshold:uint parm: uvm_perf_thrashing_pin_threshold:uint parm: uvm_perf_thrashing_lapse_usec:uint parm: uvm_perf_thrashing_nap_usec:uint parm: uvm_perf_thrashing_epoch_msec:uint parm: uvm_perf_thrashing_max_resets:uint parm: uvm_perf_thrashing_pin_msec:uint parm: uvm_perf_map_remote_on_native_atomics_fault:uint parm: uvm_hmm:Enable (1) or disable (0) HMM mode. Default: 0. Ignored if CONFIG_HMM is not set, or if NEXT settings conflict with HMM. (int) parm: uvm_global_oversubscription:Enable (1) or disable (0) global oversubscription support. (int) parm: uvm_leak_checker:Enable uvm memory leak checking. 0 = disabled, 1 = count total bytes allocated and freed, 2 = per-allocation origin tracking. (int) parm: uvm_force_prefetch_fault_support:uint parm: uvm_debug_enable_push_desc:Enable push description tracking (int) parm: uvm_page_table_location:Set the location for UVM-allocated page tables. Choices are: vid, sys. (charp) parm: uvm_perf_access_counter_mimc_migration_enable:Whether MIMC access counters will trigger migrations.Valid values: <= -1 (default policy), 0 (off), >= 1 (on) (int) parm: uvm_perf_access_counter_momc_migration_enable:Whether MOMC access counters will trigger migrations.Valid values: <= -1 (default policy), 0 (off), >= 1 (on) (int) parm: uvm_perf_access_counter_batch_count:uint parm: uvm_perf_access_counter_granularity:Size of the physical memory region tracked by each counter. Valid values asof Volta: 64k, 2m, 16m, 16g (charp) parm: uvm_perf_access_counter_threshold:Number of remote accesses on a region required to trigger a notification.Valid values: [1, 65535] (uint) parm: uvm_perf_reenable_prefetch_faults_lapse_msec:uint parm:
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
August 15, 2018 2:59 PM, tu...@posteo.de wrote: > Yes I did reboot the sustem. In my initial mail I mentioned a tool > called CUDA-Z and Blender, which both reports a missing CUDA device. Ok, so you do not have a specific error which might have been thrown by the module? Other ideas, check dev-util/nvidia-cuda-toolkit version and double check nvidia/nvidia_uvm with modinfo to ensure they are installed and loaded correctly with the right version? Could you also run /opt/cuda/extras/demo_suite/deviceQuery (from nvidia-cuda-toolkit) and show its output? My installation works, so at least we know their version is not completely broken... Driver version: 396.51 Cuda version: 9.2.88 -- Corentin “Nado” Pazdera
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/15 12:45, Corentin “Nado” Pazdera wrote: > August 15, 2018 2:02 PM, tu...@posteo.de wrote: > > ...sorry, I am no native speaker...I dont understand. > > > > I did not know how to disable CUDA on both cards. > > So...since it works perfectly with the old driver I would think: > > No, CUDA is enabled (or at least the old driver does this for me). > > > > Then I do an "emerge " and CUDA stops > > working. I do not change anything else nor do I know, who/what could > > disable CUDA on both cards ... except for the driver itsself. > > > > This is weird. > > > > Again, for logical reasons I think, that the culprit is either the > > driver itsself or a missing (and therefor undocumented) configuration > > step needed for the new drivers. > > > > The cards are not "old" in any sense. > > Ok, what I meant is : how did you check CUDA "was not working"? And could you > check it on both cards. > > Also, as said by realnc, did you reboot ? > > -- > Corentin “Nado” Pazdera > Yes I did reboot the sustem. In my initial mail I mentioned a tool called CUDA-Z and Blender, which both reports a missing CUDA device.
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/15 03:35, Nikos Chantziaras wrote: > On 15/08/18 15:02, tu...@posteo.de wrote: > > Then I do an "emerge " and CUDA stops > > working. I do not change anything else nor do I know, who/what could > > disable CUDA on both cards ... except for the driver itsself. > > Dumb question, but just to be sure: did you reboot after upgrading the > driver? The driver never worked for me correctly, unless I reboot. Unloading > the driver with "modprobe -r" and loading the new one doesn't work > correctly, only rebooting does. > > Yes, I did reboot the system
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
August 15, 2018 2:02 PM, tu...@posteo.de wrote: > ...sorry, I am no native speaker...I dont understand. > > I did not know how to disable CUDA on both cards. > So...since it works perfectly with the old driver I would think: > No, CUDA is enabled (or at least the old driver does this for me). > > Then I do an "emerge " and CUDA stops > working. I do not change anything else nor do I know, who/what could > disable CUDA on both cards ... except for the driver itsself. > > This is weird. > > Again, for logical reasons I think, that the culprit is either the > driver itsself or a missing (and therefor undocumented) configuration > step needed for the new drivers. > > The cards are not "old" in any sense. Ok, what I meant is : how did you check CUDA "was not working"? And could you check it on both cards. Also, as said by realnc, did you reboot ? -- Corentin “Nado” Pazdera
[gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 15/08/18 15:02, tu...@posteo.de wrote: Then I do an "emerge " and CUDA stops working. I do not change anything else nor do I know, who/what could disable CUDA on both cards ... except for the driver itsself. Dumb question, but just to be sure: did you reboot after upgrading the driver? The driver never worked for me correctly, unless I reboot. Unloading the driver with "modprobe -r" and loading the new one doesn't work correctly, only rebooting does.
[gentoo-user] Re: Is this a portage bug?
On 2018-08-15, Peter Humphrey wrote:
> Hello list,
>
> While trying to get a USB printer recognised on an Atom box, I found this,
> immediately after emerge --sync && eix-update:
>
> (atom) peak / # eix -c kyocera
> [N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs) and
> filters for Kyocera 1x2x MFP
> [N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description files for
> (some) Kyocera Mita Printers
> Found 2 matches
>
> (atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
> net-print/kyocera-mita-ppds
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies ... done!
>
> !!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver" have
> been masked.
> !!! One of the following masked packages is required to complete your request:
> - net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by: missing
> keyword)
>
> (atom) peak / # grep kyocera /etc/portage/package.keywords
> net-print/kyocera-1x2x-mfp-driver
> net-print/kyocera-mita-ppds
>
> I wonder whether the "1x2x" is confusing portage.
There is no confusion. The package isn't available for your
architecture/keyword.
Portage finds it, and says it is masked by "missing keyword".
"(--)" in the eix output is what eix -c shows when there's no version
available for your system.
You could unmask it - you can run
emerge -pv --autounmask net-print/kyocera-1x2x-mfp-driver
to see what files need to be changed and how (this won't make any
changes by itself).
But keep in mind, from portage(5) ("man 5 portage"):
«Additional Note: If you encounter the -* KEYWORD, this indicates
that the package is known to be broken on all systems which are not
otherwise listed in KEYWORDS. For example, a binary only package
which is built for x86 will look like:
games-fps/quake3-demo-1.11.ebuild:KEYWORDS="-* x86"»
--
Nuno Silva
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/15 11:39, Corentin “Nado” Pazdera wrote: > August 15, 2018 1:16 PM, tu...@posteo.de wrote: > > > The wiki-page is old...it speaks of nvidia-driver-174. > > Yeah, for legacy cards... If you check the history its also been updated > quite frequently. > > > modprobe.d/nvidia.conf: > > > > # Nvidia drivers support > > alias char-major-195 nvidia > > alias /dev/nvidiactl char-major-195 > > > > # To tweak the driver the following options can be used, note that > > # you should be careful, as it could cause instability!! For more > > # options see /usr/share/doc/nvidia-drivers-396.24-r1/README > > # > > # !!! SECURITY WARNING !!! > > # DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW > > # WHAT YOU ARE DOING. > > # ONLY ADD TRUSTED USERS TO THE VIDEO GROUP, THESE USERS MAY BE ABLE TO > > CRASH, > > # COMPROMISE, OR IRREPARABLY DAMAGE THE MACHINE. > > options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 > > NVreg_DeviceFileGID=27 > > NVreg_ModifyDeviceFiles=1 > > > > modprobe.d/nvidia-rmmod.conf > > > > # Nvidia UVM support > > remove nvidia modprobe -r --ignore-remove nvidia-drm nvidia-modeset > > nvidia-uvm nvidia > > > > All the configurations are working all the years up to > > x11-drivers/nvidia-drivers-396.24-r1. > > After that, no CUDA device was found. > > Based on logical reasons, I would tend to think, that it is something > > version specific and no global setting which is valid since > > nvidia-driver-174. > > Updates may need to change a config file after bringing breaking changes, it > might not be the cause > I agree. But its possible. > > Is CUDA disabled on both cards? I have a 970Ti, although my MB is different, > we might try to > compare the big differences in our systems? > > -- > Corentin “Nado” Pazdera > ...sorry, I am no native speaker...I dont understand. I did not know how to disable CUDA on both cards. So...since it works perfectly with the old driver I would think: No, CUDA is enabled (or at least the old driver does this for me). Then I do an "emerge " and CUDA stops working. I do not change anything else nor do I know, who/what could disable CUDA on both cards ... except for the driver itsself. This is weird. Again, for logical reasons I think, that the culprit is either the driver itsself or a missing (and therefor undocumented) configuration step needed for the new drivers. The cards are not "old" in any sense.
Re: [gentoo-user] Is this a portage bug?
I think that's the way "equery w" works:
>> Display the path to the ebuild that would be used by Portage with the
current configuration. <<
With your current configuration there is no package matching your query.
Alternatives for future use in such cases:
❯ epkginfo -k kyocera-1x2x-mfp-driver
* net-print/kyocera-1x2x-mfp-driver [gentoo]
1.1203-r1:0: ~amd64 -*
❯ equery y kyocera-1x2x-mfp-driver
Keywords for net-print/kyocera-1x2x-mfp-driver:
| a | |
| m | |
| d x | |
| 6 8 | |
| 4 6 | u |
| a a a p s | | | n |
| l m r i p h m s p f m f | e u s | r
| p d a m a p c x p 6 3 a b i b | a s l | e
| h 6 r 6 6 p 6 8 p 8 9 s r s p s | p e o | p
| a 4 m 4 4 c 4 6 a k 0 h c d s d | i d t | o
--+-+---+---
1.1203-r1 | * ~ * * * * * * * * * * * * * * | 6 o 0 | gentoo
Am Mi., 15. Aug. 2018 um 12:23 Uhr schrieb Peter Humphrey <
pe...@prh.myzen.co.uk>:
> On Wednesday, 15 August 2018 09:50:09 BST Franz Fellner wrote:
> >
> > Am Mi., 15. Aug. 2018 um 11:29 Uhr schrieb Peter Humphrey <
> >
> > pe...@prh.myzen.co.uk>:
> > > Hello list,
> > >
> > > While trying to get a USB printer recognised on an Atom box, I found
> > > this, immediately after emerge --sync && eix-update:
> > >
> > > (atom) peak / # eix -c kyocera
> > > [N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs)
> > > and filters for Kyocera 1x2x MFP
> > > [N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description
> files
> > > for (some) Kyocera Mita Printers
> > > Found 2 matches
> > >
> > > (atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
> > > net-print/kyocera-mita-ppds
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > Calculating dependencies ... done!
> > >
> > > !!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver"
> > > have been masked.
> > > !!! One of the following masked packages is required to complete your
> > > request:
> > > - net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by:
> > > missing keyword)
> > >
> > > (atom) peak / # grep kyocera /etc/portage/package.keywords
> > > net-print/kyocera-1x2x-mfp-driver
> > > net-print/kyocera-mita-ppds
> > >
> > > I wonder whether the "1x2x" is confusing portage.
>
> > It's ~amd64 only. So if you get missing keyword, could it be you are on
> > x86?
>
> This is an X86 box (Atom N270), but it's more complex than that:
>
> (atom) peak / # equery w net-print/kyocera-1x2x-mfp-driver
> !!! No packages matching 'net-print/kyocera-1x2x-mfp-driver'
> (atom) peak / # ls -l /usr/portage/net-print/kyocera-1x2x-mfp-driver
> total 7.0K
> drwxr-xr-x 2 portage portage 1.0K Sep 6 2017 files
> -rw-r--r-- 1 portage portage 3.4K Jan 15 2018
> kyocera-1x2x-mfp-driver-1.1203-r1.ebuild
> -rw-r--r-- 1 portage portage 317 Dec 12 2017 Manifest
> -rw-r--r-- 1 portage portage 529 Sep 6 2017 metadata.xml
>
> Thus my usual use of portage tools failed, so I didn't get as far as seeing
> this:
>
> (atom) peak / # grep KEYWORDS
> /usr/portage/net-print/kyocera-1x2x-mfp-driver/*ebuild
> KEYWORDS="-* ~amd64"
>
> Something does seem to be, if not broken, somewhat bent.
>
> --
> Regards,
> Peter.
>
>
>
>
>
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
August 15, 2018 1:16 PM, tu...@posteo.de wrote: > The wiki-page is old...it speaks of nvidia-driver-174. Yeah, for legacy cards... If you check the history its also been updated quite frequently. > modprobe.d/nvidia.conf: > > # Nvidia drivers support > alias char-major-195 nvidia > alias /dev/nvidiactl char-major-195 > > # To tweak the driver the following options can be used, note that > # you should be careful, as it could cause instability!! For more > # options see /usr/share/doc/nvidia-drivers-396.24-r1/README > # > # !!! SECURITY WARNING !!! > # DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW > # WHAT YOU ARE DOING. > # ONLY ADD TRUSTED USERS TO THE VIDEO GROUP, THESE USERS MAY BE ABLE TO CRASH, > # COMPROMISE, OR IRREPARABLY DAMAGE THE MACHINE. > options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 > NVreg_DeviceFileGID=27 > NVreg_ModifyDeviceFiles=1 > > modprobe.d/nvidia-rmmod.conf > > # Nvidia UVM support > remove nvidia modprobe -r --ignore-remove nvidia-drm nvidia-modeset > nvidia-uvm nvidia > > All the configurations are working all the years up to > x11-drivers/nvidia-drivers-396.24-r1. > After that, no CUDA device was found. > Based on logical reasons, I would tend to think, that it is something > version specific and no global setting which is valid since > nvidia-driver-174. Updates may need to change a config file after bringing breaking changes, it might not be the cause I agree. But its possible. Is CUDA disabled on both cards? I have a 970Ti, although my MB is different, we might try to compare the big differences in our systems? -- Corentin “Nado” Pazdera
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/15 10:33, Corentin “Nado” Pazdera wrote: > August 15, 2018 4:19 AM, tu...@posteo.de wrote: > > > On 08/14 11:16, Nikos Chantziaras wrote: > > > >> On 14/08/18 13:35, tu...@posteo.de wrote: > >> Hi, > >> > >> after upgrading to nvidia-drivers-396.51 no CUDA devices were found. > >> Last version, which works for me is nvidia-drivers-396.24-r1. > >> > >> Do you have the "uvm" USE flag set? It might be required for CUDA, but it's > >> disabled by default (perhaps wrongly, because USE flags should follow > >> upstream defaults unless there's a reason not to.) > > > > Yes it is: > > > > (this is the version, which is currentlu still working > > Installed versions: 396.24-r1(0/396)^md(08:31:04 PM 08/14/2018)(X driver > > kms static-libs tools uvm > > -acpi -compat -gtk3 -multilib -pax_kernel -wayland ABI_MIPS="-n32 -n64 > > -o32" ABI_PPC="-32 -64" > > ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD") > > > > and set via /etc/portage/package.use > > > > # required by app-admin/conky-1.10.6-r1::gentoo[nvidia,X] > > # required by @selected > > # required by @world (argument) > >> =x11-drivers/nvidia-drivers-378.13 static-libs uvm > > > > What else could be the reason for the problem? > > How can I fix it? > > Can you also show content of modprobe.d file ? > Did you read the whole wiki page ? Did you check for MSI interrupts ? > https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers#Driver_fails_to_initialize_when_MSI_interrupts_are_enabled > > Regards, > -- > Corentin “Nado” Pazdera > The wiki-page is old...it speaks of nvidia-driver-174. modprobe.d/nvidia.conf: # Nvidia drivers support alias char-major-195 nvidia alias /dev/nvidiactl char-major-195 # To tweak the driver the following options can be used, note that # you should be careful, as it could cause instability!! For more # options see /usr/share/doc/nvidia-drivers-396.24-r1/README # # !!! SECURITY WARNING !!! # DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW # WHAT YOU ARE DOING. # ONLY ADD TRUSTED USERS TO THE VIDEO GROUP, THESE USERS MAY BE ABLE TO CRASH, # COMPROMISE, OR IRREPARABLY DAMAGE THE MACHINE. options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27 NVreg_ModifyDeviceFiles=1 modprobe.d/nvidia-rmmod.conf # Nvidia UVM support remove nvidia modprobe -r --ignore-remove nvidia-drm nvidia-modeset nvidia-uvm nvidia All the configurations are working all the years up to x11-drivers/nvidia-drivers-396.24-r1. After that, no CUDA device was found. Based on logical reasons, I would tend to think, that it is something version specific and no global setting which is valid since nvidia-driver-174. Regards,
Re: [gentoo-user] sanoid (was Backup questions)
On Wed, 15 Aug 2018 02:45:20 -0400, J. Roeleveld wrote: > > On Tuesday, August 14, 2018 10:52:30 PM CEST John Covici wrote: > > On Tue, 14 Aug 2018 16:06:21 -0400, > > > > J. Roeleveld wrote: > > > On August 14, 2018 11:42:18 AM UTC, John Covici > wrote: > > > >I use sanoid/syncoid to back up using zfs. Its great, keeps snapshots > > > >for as long as I want them (I use 80 days for now). And it keeps > > > >hourlies for the last couple of days as well, so I could roll back in > > > >case of a problem. Very nice if you use zfs. > > > > > > I tried sanoid, but it has a few problems which really become annoying > > > when you have a lot of datasets: 1) every dataset is handled seperately, > > > no use of recursive snapshots when datasets are inside the same tree 2) > > > it keeps seperate hourly, daily, snapshots, which means it will > > > happily create multiple snapshots with only a few seconds difference for > > > every dataset around midnight. 3) when rolling back several snapshots, > > > there are multiple errors reported because the cache (where does it store > > > that?) does not match reality. > > > > > > Have these been resolved yet? > > > > > > I ended up writing my own system for this, got some extra intelligence in > > > there to work around any possible error condition I have encountered. > > Well, I got around your second point by having a special job at 11:59 > > pm to create the dailies and the one at midnight works well. I only > > do the cron jobs hourly, not every minute like they wanted. > > > > If your script is not special for you, I would like to see it, maybe I > > would use it instead. Things seem to work for now, however with those > > modifications. > > Current code is too specific for my situation. I think you would be quicker > to > write something yourself instead of modifying my code. > > The steps are: > - Check if an snapshot needs to be done (incl. type: hourly, daily, weekly, > monthly) > - If yes: > 1) create a recursive snapshot on the entire pool > 2) remove unnecessary snapshots (temp, swap, > placeholders,not_for_current_type) > 3) register snapshots into database > 4) clean up old snapshots > > Because I register actual snapshots and point snapshot-type entries to these, > I can quickly determine which snapshots are really unecessary. This also > drastically reduces the amount of snapshots on the system. (My SAN currently > has 2611 ZFS snapshots). > > I also found it is far quicker to create a recursive snapshot on the entire > pool and then removing all the unecessarily created ones. OK, I will look into that. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
August 15, 2018 4:19 AM, tu...@posteo.de wrote: > On 08/14 11:16, Nikos Chantziaras wrote: > >> On 14/08/18 13:35, tu...@posteo.de wrote: >> Hi, >> >> after upgrading to nvidia-drivers-396.51 no CUDA devices were found. >> Last version, which works for me is nvidia-drivers-396.24-r1. >> >> Do you have the "uvm" USE flag set? It might be required for CUDA, but it's >> disabled by default (perhaps wrongly, because USE flags should follow >> upstream defaults unless there's a reason not to.) > > Yes it is: > > (this is the version, which is currentlu still working > Installed versions: 396.24-r1(0/396)^md(08:31:04 PM 08/14/2018)(X driver kms > static-libs tools uvm > -acpi -compat -gtk3 -multilib -pax_kernel -wayland ABI_MIPS="-n32 -n64 -o32" > ABI_PPC="-32 -64" > ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD") > > and set via /etc/portage/package.use > > # required by app-admin/conky-1.10.6-r1::gentoo[nvidia,X] > # required by @selected > # required by @world (argument) >> =x11-drivers/nvidia-drivers-378.13 static-libs uvm > > What else could be the reason for the problem? > How can I fix it? Can you also show content of modprobe.d file ? Did you read the whole wiki page ? Did you check for MSI interrupts ? https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers#Driver_fails_to_initialize_when_MSI_interrupts_are_enabled Regards, -- Corentin “Nado” Pazdera
Re: [gentoo-user] Is this a portage bug?
On 15 August 2018 at 11:22, Peter Humphrey wrote: > On Wednesday, 15 August 2018 09:50:09 BST Franz Fellner wrote: > (atom) peak / # equery w net-print/kyocera-1x2x-mfp-driver > > Something does seem to be, if not broken, somewhat bent. That seems to be correct. equery w takes your configuration into account when figuring out which path to show. Since it is only keyworded for ~amd64, it is not available for you x86 box. For my ~amd64 box it works just fine. Regards, Arve
Re: [gentoo-user] Is this a portage bug?
On Wednesday, 15 August 2018 09:50:09 BST Franz Fellner wrote:
>
> Am Mi., 15. Aug. 2018 um 11:29 Uhr schrieb Peter Humphrey <
>
> pe...@prh.myzen.co.uk>:
> > Hello list,
> >
> > While trying to get a USB printer recognised on an Atom box, I found
> > this, immediately after emerge --sync && eix-update:
> >
> > (atom) peak / # eix -c kyocera
> > [N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs)
> > and filters for Kyocera 1x2x MFP
> > [N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description files
> > for (some) Kyocera Mita Printers
> > Found 2 matches
> >
> > (atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
> > net-print/kyocera-mita-ppds
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies ... done!
> >
> > !!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver"
> > have been masked.
> > !!! One of the following masked packages is required to complete your
> > request:
> > - net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by:
> > missing keyword)
> >
> > (atom) peak / # grep kyocera /etc/portage/package.keywords
> > net-print/kyocera-1x2x-mfp-driver
> > net-print/kyocera-mita-ppds
> >
> > I wonder whether the "1x2x" is confusing portage.
> It's ~amd64 only. So if you get missing keyword, could it be you are on
> x86?
This is an X86 box (Atom N270), but it's more complex than that:
(atom) peak / # equery w net-print/kyocera-1x2x-mfp-driver
!!! No packages matching 'net-print/kyocera-1x2x-mfp-driver'
(atom) peak / # ls -l /usr/portage/net-print/kyocera-1x2x-mfp-driver
total 7.0K
drwxr-xr-x 2 portage portage 1.0K Sep 6 2017 files
-rw-r--r-- 1 portage portage 3.4K Jan 15 2018
kyocera-1x2x-mfp-driver-1.1203-r1.ebuild
-rw-r--r-- 1 portage portage 317 Dec 12 2017 Manifest
-rw-r--r-- 1 portage portage 529 Sep 6 2017 metadata.xml
Thus my usual use of portage tools failed, so I didn't get as far as seeing
this:
(atom) peak / # grep KEYWORDS
/usr/portage/net-print/kyocera-1x2x-mfp-driver/*ebuild
KEYWORDS="-* ~amd64"
Something does seem to be, if not broken, somewhat bent.
--
Regards,
Peter.
Re: [gentoo-user] Cups without X
On Wed, 15 Aug 2018 08:53:03 +0100, Peter Humphrey wrote: > > ISTR something about not setting USB_PRINTER in the kernel config, but > > it's been a while since I used a USB printer. When I did, it was on a > > headless box. > > Yes, I knew about the kernel printer support being obsolete, and > therefore I don't have it selected. > > As yours was a headless box, you must have solved the problem I'm > facing, or else it didn't happen at all. Fortunately for me, but not so helpful for you, it was the latter. -- Neil Bothwick I thought the 10 commandments were multiple choice. pgp6Hvw7Ag0Wj.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Is this a portage bug?
It's ~amd64 only. So if you get missing keyword, could it be you are on x86?
Am Mi., 15. Aug. 2018 um 11:29 Uhr schrieb Peter Humphrey <
pe...@prh.myzen.co.uk>:
> Hello list,
>
> While trying to get a USB printer recognised on an Atom box, I found this,
> immediately after emerge --sync && eix-update:
>
> (atom) peak / # eix -c kyocera
> [N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs)
> and filters for Kyocera 1x2x MFP
> [N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description files
> for (some) Kyocera Mita Printers
> Found 2 matches
>
> (atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
> net-print/kyocera-mita-ppds
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies ... done!
>
> !!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver"
> have been masked.
> !!! One of the following masked packages is required to complete your
> request:
> - net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by: missing
> keyword)
>
> (atom) peak / # grep kyocera /etc/portage/package.keywords
> net-print/kyocera-1x2x-mfp-driver
> net-print/kyocera-mita-ppds
>
> I wonder whether the "1x2x" is confusing portage.
>
> --
> Regards,
> Peter.
>
>
>
>
>
[gentoo-user] Is this a portage bug?
Hello list,
While trying to get a USB printer recognised on an Atom box, I found this,
immediately after emerge --sync && eix-update:
(atom) peak / # eix -c kyocera
[N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs) and
filters for Kyocera 1x2x MFP
[N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description files for
(some) Kyocera Mita Printers
Found 2 matches
(atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
net-print/kyocera-mita-ppds
These are the packages that would be merged, in order:
Calculating dependencies ... done!
!!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver" have
been masked.
!!! One of the following masked packages is required to complete your request:
- net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by: missing
keyword)
(atom) peak / # grep kyocera /etc/portage/package.keywords
net-print/kyocera-1x2x-mfp-driver
net-print/kyocera-mita-ppds
I wonder whether the "1x2x" is confusing portage.
--
Regards,
Peter.
Re: [gentoo-user] Cups without X
On Tuesday, 14 August 2018 17:32:47 BST Neil Bothwick wrote: > On Tue, 14 Aug 2018 15:24:48 +0100, Peter Humphrey wrote: > > My problem is that, even though the system detects the printer being > > connected, cups can't see it. I've tried everything I can think of so > > I'm now hoping that someone here can point out my (no doubt elementary) > > error. > > ISTR something about not setting USB_PRINTER in the kernel config, but > it's been a while since I used a USB printer. When I did, it was on a > headless box. Yes, I knew about the kernel printer support being obsolete, and therefore I don't have it selected. As yours was a headless box, you must have solved the problem I'm facing, or else it didn't happen at all. -- Regards, Peter.
Re: [gentoo-user] sanoid (was Backup questions)
On Tuesday, August 14, 2018 10:52:30 PM CEST John Covici wrote: > On Tue, 14 Aug 2018 16:06:21 -0400, > > J. Roeleveld wrote: > > On August 14, 2018 11:42:18 AM UTC, John Covici wrote: > > >I use sanoid/syncoid to back up using zfs. Its great, keeps snapshots > > >for as long as I want them (I use 80 days for now). And it keeps > > >hourlies for the last couple of days as well, so I could roll back in > > >case of a problem. Very nice if you use zfs. > > > > I tried sanoid, but it has a few problems which really become annoying > > when you have a lot of datasets: 1) every dataset is handled seperately, > > no use of recursive snapshots when datasets are inside the same tree 2) > > it keeps seperate hourly, daily, snapshots, which means it will > > happily create multiple snapshots with only a few seconds difference for > > every dataset around midnight. 3) when rolling back several snapshots, > > there are multiple errors reported because the cache (where does it store > > that?) does not match reality. > > > > Have these been resolved yet? > > > > I ended up writing my own system for this, got some extra intelligence in > > there to work around any possible error condition I have encountered. > Well, I got around your second point by having a special job at 11:59 > pm to create the dailies and the one at midnight works well. I only > do the cron jobs hourly, not every minute like they wanted. > > If your script is not special for you, I would like to see it, maybe I > would use it instead. Things seem to work for now, however with those > modifications. Current code is too specific for my situation. I think you would be quicker to write something yourself instead of modifying my code. The steps are: - Check if an snapshot needs to be done (incl. type: hourly, daily, weekly, monthly) - If yes: 1) create a recursive snapshot on the entire pool 2) remove unnecessary snapshots (temp, swap, placeholders,not_for_current_type) 3) register snapshots into database 4) clean up old snapshots Because I register actual snapshots and point snapshot-type entries to these, I can quickly determine which snapshots are really unecessary. This also drastically reduces the amount of snapshots on the system. (My SAN currently has 2611 ZFS snapshots). I also found it is far quicker to create a recursive snapshot on the entire pool and then removing all the unecessarily created ones. -- Joost
