Re: [gentoo-user] x86.c:(.text+0xb2): undefined reference to `l1tf_vmx_mitigation' with linux kernel 4.18.1
On Fri, Aug 17, 2018 at 8:10 AM wrote: > > On 08/17 02:53, Adam Carter wrote: > > On Fri, Aug 17, 2018 at 1:15 PM, wrote: > > > > > Hi, > > > > > > CPU bugs seem to be more and more common: > > > https://www.heise.de/security/meldung/Linux-Kernel-und- > > > Distributionen-schuetzen-vor-Prozessorluecke-Foreshadow-L1TF-4137264.html > > > https://www.heise.de/security/meldung/Spectre-NG-Foreshadow- > > > gefaehrdet-Intel-Prozessoren-4137209.html > > > (sorry, I only know of this german spoken references...) > > > > > > With Linux kernel 4.18.1 Linus has introduced a fix (aka workaround) > > > of the Foreshadow bug. > > > > > > > 4.18, 4.17, 4.14, 4.9, and 4.4 have all had the fixes applied. > > > > > > > > Unfortunately compiling that kernel (as downloaded from > > > https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ ) > > > > > > gives me this bug: > > > > > > > gentoo-sources with gcc 7.3 builds fine for me. > > > > Intel: grep . /sys/devices/system/cpu/vulnerabilities/* > > /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion > > /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI > > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: > > Speculative Store Bypass disabled via prctl and seccomp > > /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user > > pointer sanitization > > /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic > > retpoline, IBPB, IBRS_FW > > > > AMD: grep . /sys/devices/system/cpu/vulnerabilities/* > > /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected > > /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected > > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: > > Speculative Store Bypass disabled via prctl and seccomp > > /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user > > pointer sanitization > > /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD > > retpoline, IBPB > > Hi, > > I am happy, that other sources do work for you Adam. > > Interesting would be, why the original sources does not compile for > me. > Any idea? > > > This problem has been reported upstream. See below. https://lkml.org/lkml/2018/8/15/118 In particular: Build is successful with CONFIG_KVM=y CONFIG_KVM_INTEL=y CONFIG_KVM_AMD=y but fails if only CONFIG_KVM=y CONFIG_KVM_AMD=y are selected.
Re: [gentoo-user] Backup questions
Marc Joliet wrote: > Am Freitag, 10. August 2018, 04:46:17 CEST schrieb Dale: >> Wols Lists wrote: >>> On 08/08/18 04:43, Dale wrote: Howdy, I just bought two external drive enclosures. One is sort of a spare but I do plan to do some backups on it, mostly pictures from my camera. In one of the enclosures I put a single 6TB drive that I found on ebay. It has about 7,000 hours on it so it should have some life left yet and it passed the smartctl tests. It is USB but it transfers fast. Now to some questions. I use rsync. Command looks something like rsync -auv /source/ /destination/. If I backup the config files in my home directory, should I also include the --delete option? If after a upgrade for example a config file is deleted, because it is no longer needed, or renamed, should the old file be removed or is there a reason to keep them on the backups? Adding the --delete option isn't a problem command wise BUT I wonder if it can cause a problem at some point. Thoughts on that. I plan to use the --delete option for videos since if I deleted one, it is likely broken or something. Biggest question is about config files. >>> May I suggest using btrfs for your backup drive? One MAJOR caveat - DO >>> NOT let the drive fill up - a combination of snapshots and drive-full >>> has been known (quite often) to trash the file system. But provided you >>> make sure it doesn't go above about 80% you should be fine. >>> >>> You can add an option to rsync such that it will back up "in place". In >>> other words, if only 1K is changed in a 1M file, it will overwrite that >>> 1K. So when you back up, the procedure is to take a snapshot, then run >>> rsync with both "in place" and "delete". >>> >>> This will give you the space economy of incremental backups, combined >>> with the utility of full backups - each snapshot is a full backup as of >>> that date, but each new snapshot only increases disk usage by the >>> changes since the last. And you reclaim space by deleting old snapshots. >> I did think about btrfs. I've read a lot of threads on here about >> people using it and it seems to have come a long ways and be pretty >> stable. Right now, I've got a lot going on and really don't have the >> time to sit down and read up on it and how it works or what all it can >> do. In all honesty, if my system were to crash later when I don't have >> so much going on, I'd like to move to btrfs for as much as possible of >> my system. > Yeah, it's a good idea to wait until you have time :) . And then migrate > piecemeal, not all at once. Following up on Wol's suggestion, I would start > with the backup drive, since you can exploit most of the features there > (well, > snapshots and compression, at least). Personally, I've had mostly good > experience with btrfs and enjoy its send/receive feature for full-system > incremental backups. > >> I suspect /boot would still have to be ext2 or something >> because of grub. > GRUB actually supports btrfs. However, on a UEFI system you will need a > FAT32 > file system for /boot, so I would argue that on a relatively recent system > the > issue is moot. > Yea, time is even more limited now. My Mom is still in the hospital about a hour away. I'm not supposed to visit people there, and other places where a lot of sick people can be, but it's my Mom. I went twice. The morning after the second visit, I was at the Doctors office. Now I'm sick. Luckily, the meds are working. Thing is, I don't feel like messing with computer stuff right now. Even cooking a meal is not so interesting. I can't taste or smell anyway. So, it may be a while before I get the time to deal with any of this. I would likely not learn anything about a new file system even if I read it more than once. I'm even avoiding updates just to prevent anything from going sideways. I wonder, how many times will I proof and edit this email I thought I read Grub, the new version, supported more file systems. Still, just for safety, I'd likely still use ext2. There's a lot of new stuff out there. Just tons of options. Thanks. Dale :-) :-)
Re: [gentoo-user] x86.c:(.text+0xb2): undefined reference to `l1tf_vmx_mitigation' with linux kernel 4.18.1
On 08/17 02:53, Adam Carter wrote: > On Fri, Aug 17, 2018 at 1:15 PM, wrote: > > > Hi, > > > > CPU bugs seem to be more and more common: > > https://www.heise.de/security/meldung/Linux-Kernel-und- > > Distributionen-schuetzen-vor-Prozessorluecke-Foreshadow-L1TF-4137264.html > > https://www.heise.de/security/meldung/Spectre-NG-Foreshadow- > > gefaehrdet-Intel-Prozessoren-4137209.html > > (sorry, I only know of this german spoken references...) > > > > With Linux kernel 4.18.1 Linus has introduced a fix (aka workaround) > > of the Foreshadow bug. > > > > 4.18, 4.17, 4.14, 4.9, and 4.4 have all had the fixes applied. > > > > > Unfortunately compiling that kernel (as downloaded from > > https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ ) > > > > gives me this bug: > > > > gentoo-sources with gcc 7.3 builds fine for me. > > Intel: grep . /sys/devices/system/cpu/vulnerabilities/* > /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion > /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: > Speculative Store Bypass disabled via prctl and seccomp > /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user > pointer sanitization > /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic > retpoline, IBPB, IBRS_FW > > AMD: grep . /sys/devices/system/cpu/vulnerabilities/* > /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected > /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: > Speculative Store Bypass disabled via prctl and seccomp > /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user > pointer sanitization > /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD > retpoline, IBPB Hi, I am happy, that other sources do work for you Adam. Interesting would be, why the original sources does not compile for me. Any idea?
Re: [gentoo-user] x86.c:(.text+0xb2): undefined reference to `l1tf_vmx_mitigation' with linux kernel 4.18.1
On Fri, Aug 17, 2018 at 1:15 PM, wrote: > Hi, > > CPU bugs seem to be more and more common: > https://www.heise.de/security/meldung/Linux-Kernel-und- > Distributionen-schuetzen-vor-Prozessorluecke-Foreshadow-L1TF-4137264.html > https://www.heise.de/security/meldung/Spectre-NG-Foreshadow- > gefaehrdet-Intel-Prozessoren-4137209.html > (sorry, I only know of this german spoken references...) > > With Linux kernel 4.18.1 Linus has introduced a fix (aka workaround) > of the Foreshadow bug. > 4.18, 4.17, 4.14, 4.9, and 4.4 have all had the fixes applied. > > Unfortunately compiling that kernel (as downloaded from > https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ ) > > gives me this bug: > gentoo-sources with gcc 7.3 builds fine for me. Intel: grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW AMD: grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB
[gentoo-user] x86.c:(.text+0xb2): undefined reference to `l1tf_vmx_mitigation' with linux kernel 4.18.1
Hi, CPU bugs seem to be more and more common: https://www.heise.de/security/meldung/Linux-Kernel-und-Distributionen-schuetzen-vor-Prozessorluecke-Foreshadow-L1TF-4137264.html https://www.heise.de/security/meldung/Spectre-NG-Foreshadow-gefaehrdet-Intel-Prozessoren-4137209.html (sorry, I only know of this german spoken references...) With Linux kernel 4.18.1 Linus has introduced a fix (aka workaround) of the Foreshadow bug. Unfortunately compiling that kernel (as downloaded from https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ ) gives me this bug: ... AR arch/x86/lib/built-in.a CC virt/lib/irqbypass.o AR virt/lib/built-in.a AR virt/built-in.a GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a AR built-in.a LD vmlinux.o MODPOST vmlinux.o arch/x86/kvm/x86.o: In function `kvm_get_arch_capabilities': x86.c:(.text+0xb2): undefined reference to `l1tf_vmx_mitigation' make[1]: *** [Makefile:1010: vmlinux] Error 1 make: *** [Makefile:273: __build_one_by_one] Error 2 [1]25144 exit 2 make clean all I am alone or is this known (a quick search on startpage.com does not give me any useful) or ... ? Is there a way around it? Cheers! Meino
Re: [gentoo-user] Replacement for gcruft: gcrud
> On 2018-08-16, at 14:22, james wrote:
>
> Yes, but, it'll be while for me. Offer and automated clean up option,
> and I have dozens of systems to test.
I'll figure out the kind of tests I want to run sometime soon.
>
>
> GLEP 64 was on the path to systematically solve what you you are doing
> after the fact::
>
> https://wiki.gentoo.org/wiki/GLEP:64
>
> More refs for your convenience
>
> http://asic-linux.com.mx/~izto/checkinstall/
>
> http://gittup.org/tup/
> ("It will automatically clean-up old files.")
Thanks for pointing these out.
It is really tempting to support macOS like tup does, although SIP and the
restored snapshot on boot kind of makes it unnecessary. And also the idea of
using a newly created FS to see changes is interesting.
A new GLEP to systematically delete extraneous files could be to restore a
non-user generated snapshot on boot just like iOS/macOS, but the problem is
that we don't always use the same filesystem or mount configurations. Another
way would be to use xattr but again the issue is compatibility.
--
Andrew
Re: [gentoo-user] Replacement for gcruft: gcrud
> On 2018-08-16, at 16:09, Corentin “Nado” Pazdera wrote: > > Hi, > > So I tested it, and I was surprised how many /etc files weren't put into > whitelist. > Actually, most of /etc shouldn't be suggested for deletion if the packages > are still installed. Thanks for testing! Really appreciate it. The whitelist is the biggest work in progress right now. Most of what it lists from /etc for me is /etc/config-archive which AFAIK is not managed by Portage at all although Portage will place old files there? I don't use the feature because my /etc is controlled by Git. The stuff listed in /var/ is pretty accurate as there's a lot of old website cruft and this computer does not serve anything like that anymore. > > Portage stuff like repositories could be whitelisted in a dynamic manner, or > at least bing able to > tell what directorie(s) are used to store them. The idea is to move to everything in the whitelist.c file to a declarative (no code unless you count RE) configuration file. I have not decided on a format but I am leaning towards INI-style because GLib2 has a parser for that built-in. The config file will specify exact paths, RE, and globs. There will be a default dynamic list generated at runtime based on what packages you have installed (as gcruft had this feature). > I also caught some wrongly listed files because of the multilib system with > /lib symlink. > For example, dhcpcd declared /lib/dhcpcd/dhcpcd-hooks, thus the realpath > /lib64/dhcpcd/dhcpcd-hooks > was listed in the removal suggestion. This should be fixed with profile 17.1 The /lib vs /lib64 issue will be resolved in a later version. I think I need to use lstat() everywhere instead of stat(), or I can call realpath() prior to storing values in the set. This file should be whitelisted, but only if you have dhcpcd installed (I've long since moved to dhcpd). I am trying to my best to give zero false positives, so you plan to have something like `% gcrud | ... | xargs rm -fR`. > > The log is so huge at the moment it is useless for me :/ > > % wc -l out.log > 461575 out.log Any thoughts on how to simplify analysis? -- Andrew
Re: [gentoo-user] Backup questions
Am Dienstag, 14. August 2018, 12:55:05 CEST schrieb Stefan G. Weichinger:
> Am 09.08.18 um 18:52 schrieb Wols Lists:
> > May I suggest using btrfs for your backup drive?
>
> I like btrbk:
>
> https://github.com/digint/btrbk
>
> I run btrfs as main filesystem on 3 systems (2 laptops, 1 main desktop)
> and so far I am not looking back.
>
> -> btrbk snapshots to local subvolumes ("time machine") + pulling btrbk
> backups to external disks + btrbk backups to another server.
>
> Works fine for me.
Works for me, too :) .
In all seriousness, I also ended up at btrbk for driving a btrfs snapshot
based backup system (btrbk is basically a fancy UI on top of the btrfs send/
receive machinery). I've been using it for, wow, for almost 3 years now
(first merged on 7th September 2015).
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Backup questions
Am Freitag, 10. August 2018, 04:46:17 CEST schrieb Dale: > Wols Lists wrote: > > On 08/08/18 04:43, Dale wrote: > >> Howdy, > >> > >> I just bought two external drive enclosures. One is sort of a spare but > >> I do plan to do some backups on it, mostly pictures from my camera. In > >> one of the enclosures I put a single 6TB drive that I found on ebay. It > >> has about 7,000 hours on it so it should have some life left yet and it > >> passed the smartctl tests. It is USB but it transfers fast. Now to > >> some questions. I use rsync. Command looks something like rsync -auv > >> /source/ /destination/. If I backup the config files in my home > >> directory, should I also include the --delete option? If after a > >> upgrade for example a config file is deleted, because it is no longer > >> needed, or renamed, should the old file be removed or is there a reason > >> to keep them on the backups? Adding the --delete option isn't a problem > >> command wise BUT I wonder if it can cause a problem at some point. > >> Thoughts on that. I plan to use the --delete option for videos since if > >> I deleted one, it is likely broken or something. Biggest question is > >> about config files. > > > > May I suggest using btrfs for your backup drive? One MAJOR caveat - DO > > NOT let the drive fill up - a combination of snapshots and drive-full > > has been known (quite often) to trash the file system. But provided you > > make sure it doesn't go above about 80% you should be fine. > > > > You can add an option to rsync such that it will back up "in place". In > > other words, if only 1K is changed in a 1M file, it will overwrite that > > 1K. So when you back up, the procedure is to take a snapshot, then run > > rsync with both "in place" and "delete". > > > > This will give you the space economy of incremental backups, combined > > with the utility of full backups - each snapshot is a full backup as of > > that date, but each new snapshot only increases disk usage by the > > changes since the last. And you reclaim space by deleting old snapshots. > > I did think about btrfs. I've read a lot of threads on here about > people using it and it seems to have come a long ways and be pretty > stable. Right now, I've got a lot going on and really don't have the > time to sit down and read up on it and how it works or what all it can > do. In all honesty, if my system were to crash later when I don't have > so much going on, I'd like to move to btrfs for as much as possible of > my system. Yeah, it's a good idea to wait until you have time :) . And then migrate piecemeal, not all at once. Following up on Wol's suggestion, I would start with the backup drive, since you can exploit most of the features there (well, snapshots and compression, at least). Personally, I've had mostly good experience with btrfs and enjoy its send/receive feature for full-system incremental backups. > I suspect /boot would still have to be ext2 or something > because of grub. GRUB actually supports btrfs. However, on a UEFI system you will need a FAT32 file system for /boot, so I would argue that on a relatively recent system the issue is moot. -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Replacement for gcruft: gcrud
August 16, 2018 8:07 AM, "Andrew Udvare" wrote: > gcruft seems to have died off (https://www.google.com/search?q=gcruft > only returns ebuild results). I was using it quite a lot and wrote many > exception files. It's gone now with no way for my or anyone else's > ebuild to get the original source. I did preserve it though, here: > https://gitlab.com/Tatsh/gcruft > > I wrote a replacement in C named gcrud. It only needs GLib2 installed to > work. It's much faster than gcruft ever was. The code is here: > > https://gitlab.com/Tatsh/gcrud > https://github.com/Tatsh/gcrud > > I am placing preference in GitLab for issues and merge requests, but I > will accept PRs from GitHub. > > The whitelist https://gitlab.com/Tatsh/gcrud/blob/master/whitelist.c is > currently hard-coded and limited but the results are satisfactory for > now in my use cases. > > Type use case: > > sudo ./gcrud | sort -u > out.log > > Examine out.log for things you can delete. There are absolutely zero > calls to delete files from the machine in my code and never will be any > kind of automation support. > > If anyone tries it out I certainly would like to see your output and get > some bug reports or suggestions. The main feature planned is reading > from a configuration file for exact file paths and regexs. > > -- > Andrew Hi, So I tested it, and I was surprised how many /etc files weren't put into whitelist. Actually, most of /etc shouldn't be suggested for deletion if the packages are still installed. Portage stuff like repositories could be whitelisted in a dynamic manner, or at least bing able to tell what directorie(s) are used to store them. I also caught some wrongly listed files because of the multilib system with /lib symlink. For example, dhcpcd declared /lib/dhcpcd/dhcpcd-hooks, thus the realpath /lib64/dhcpcd/dhcpcd-hooks was listed in the removal suggestion. This should be fixed with profile 17.1 The log is so huge at the moment it is useless for me :/ % wc -l out.log 461575 out.log -- Corentin “Nado” Pazdera
[gentoo-user] Re: Replacement for gcruft: gcrud
On 08/16/18 02:07, Andrew Udvare wrote:
> gcruft seems to have died off (https://www.google.com/search?q=gcruft
> only returns ebuild results).
It might (not really sure) be active but it appears to still be around
as ebuilds::
eix -R gcruft
* app-portage/gcruft
Available versions: ~0.1-r1^m[1] ~0.1-r1^m[2] ~0.1.1^m[1] ~0.1.1^m[2]
Homepage:http://www.genoetigt.de/site/projects/gcruft
Description: helps finding orphaned files on a gentoo system
> I was using it quite a lot and wrote many
> exception files. It's gone now with no way for my or anyone else's
> ebuild to get the original source. I did preserve it though, here:
> https://gitlab.com/Tatsh/gcruft
Thanks for caring!
> I wrote a replacement in C named gcrud. It only needs GLib2 installed to
> work. It's much faster than gcruft ever was. The code is here:
>
> https://gitlab.com/Tatsh/gcrud
> https://github.com/Tatsh/gcrud
It's going to take me a while to get aroud to testing, but I really
really like admin codes in "C" so it is automatically on my short list
>
> I am placing preference in GitLab for issues and merge requests, but I
> will accept PRs from GitHub.
I really like the like gitlab for a variety of reason. I sure wish some
would put together a gitlab-meta ebuild for gentoo. I'd like to house
codes locally, and export relevant open source codes to a online
location, or distributed among a collective of gitlab-gentoo sites.
Complementary to github and our github-centric-dev community.
>
> The whitelist https://gitlab.com/Tatsh/gcrud/blob/master/whitelist.c is
> currently hard-coded and limited but the results are satisfactory for
> now in my use cases.
>
> Type use case:
>
> sudo ./gcrud | sort -u > out.log
>
> Examine out.log for things you can delete. There are absolutely zero
> calls to delete files from the machine in my code and never will be any
> kind of automation support.
That your choice and I respect that call. However (and it's a big
however), my gentoo-centric HPC cluster do need automated system
cleanup. So, initial, it's be an army of scripts, similar to your code,
that is mandatory in a "loosely coupled" heterogeneous clusters, not to
mention first-line security related cleanup.
> If anyone tries it out I certainly would like to see your output and get
> some bug reports or suggestions. The main feature planned is reading
> from a configuration file for exact file paths and regexs.
Yes, but, it'll be while for me. Offer and automated clean up option,
and I have dozens of systems to test.
>
> --
> Andrew
Thank you Andrew for your work. It can also be very useful to my DAG
efforts for compiling, verifying, and clean up of cluster codes.
GLEP 64 was on the path to systematically solve what you you are doing
after the fact::
https://wiki.gentoo.org/wiki/GLEP:64
More refs for your convenience
http://asic-linux.com.mx/~izto/checkinstall/
http://gittup.org/tup/
("It will automatically clean-up old files.")
hth,
James
Re: [gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 08/16 09:26, Nikos Chantziaras wrote: > On 16/08/18 09:24, Nikos Chantziaras wrote: > > On 15/08/18 20:24, tu...@posteo.de wrote: > > > 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 > > > > Click "Advanced" and then "add exception". If you uncheck the > > "permament" checkbox, the exception will not be saved and be only valid > > for this session. > > Or use this URL instead: > > https://www.nvidia.com/drivers > > ...my comment about the not so well implemented NVIDIA homepage was only a sligtly ironic/cynic additonal "sigh" in all that trouble...
[gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 16/08/18 09:24, Nikos Chantziaras wrote: On 15/08/18 20:24, tu...@posteo.de wrote: 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 Click "Advanced" and then "add exception". If you uncheck the "permament" checkbox, the exception will not be saved and be only valid for this session. Or use this URL instead: https://www.nvidia.com/drivers
[gentoo-user] Re: "No CUDA device found" with nvidia-drivers newer than nvidia-drivers-396.24-r1(
On 15/08/18 20:24, tu...@posteo.de wrote: 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 Click "Advanced" and then "add exception". If you uncheck the "permament" checkbox, the exception will not be saved and be only valid for this session.
[gentoo-user] Replacement for gcruft: gcrud
gcruft seems to have died off (https://www.google.com/search?q=gcruft only returns ebuild results). I was using it quite a lot and wrote many exception files. It's gone now with no way for my or anyone else's ebuild to get the original source. I did preserve it though, here: https://gitlab.com/Tatsh/gcruft I wrote a replacement in C named gcrud. It only needs GLib2 installed to work. It's much faster than gcruft ever was. The code is here: https://gitlab.com/Tatsh/gcrud https://github.com/Tatsh/gcrud I am placing preference in GitLab for issues and merge requests, but I will accept PRs from GitHub. The whitelist https://gitlab.com/Tatsh/gcrud/blob/master/whitelist.c is currently hard-coded and limited but the results are satisfactory for now in my use cases. Type use case: sudo ./gcrud | sort -u > out.log Examine out.log for things you can delete. There are absolutely zero calls to delete files from the machine in my code and never will be any kind of automation support. If anyone tries it out I certainly would like to see your output and get some bug reports or suggestions. The main feature planned is reading from a configuration file for exact file paths and regexs. -- Andrew signature.asc Description: OpenPGP digital signature
