| danuan | looking at /etc/cron.daily/locate which has OPTIONS set and then sources secondary options file if exists from /etc/updatedb.findutils.cron.local and just does export OPTIONS , would that append to previosly set options or just overwrite them ? | 08:53 |
|---|---|---|
| gnarface | danuan: i don't have either file here to verify, but assuming i understand what you're seeing correctly, export would overwrite the previous content of the OPTIONS variable, not append | 09:09 |
| danuan | thanx , was wondering if i had to set everything or just new stuff if i started using secondary options file | 09:13 |
| danuan | and you could not append as with path PATH=$PATH,/newpath since it is sources under same VARNAME , would have to source under a NEWVARNAME to append right ? | 09:19 |
| gnarface | if danuan comes back let him know that yes, that works in bash, and direct him to: https://www.gnu.org/software/bash/manual/bash.html | 11:15 |
| gnarface | should work like that except i think $PATH entries have to be delimited with : | 11:17 |
| nemo | hm... 30 minutes before my daughter's first class of the day was definitely the wrong time to do a devuan beowulf kernel update | 15:15 |
| gnarface | indeed | 15:18 |
| nemo | gnarface: happy daughter dancing around me asking questions. me begging her to be quiet as I try to initially get the AMD properietary driver working with a kernel that no longer quite matches Ubuntu 18.04, then desperately backing it all out and throwing in FOSS one and crossing fingers | 15:21 |
| nemo | she doesn't need her games working for class anyway | 15:22 |
| gnarface | nemo: there's a non-free firmware package you also need that is packaged separately from the kernel (in debian and devuan anyway) and the version has to be the right | 15:28 |
| gnarface | nemo: *has to be right | 15:28 |
| gnarface | i dunno what ubuntu does | 15:28 |
| mason | I never do updates the day before I have to use my workstation to actually work. | 15:54 |
| mason | nemo: You shouldn't need the AMD proprietary driver, unless the hardware is bleeding-edge-new and the upstream driver won't work. It's a very different situation than what nVidia presents, where the proprietary driver is worlds better. | 15:55 |
| nemo | mason: https://m8y.org/tmp/amdgpu.html to avoid having this discussion again ☺ | 15:57 |
| nemo | but I just reinstalled the FOSS one plus closed firmware this morning | 15:58 |
| nemo | when she's done having her classes I'll see what got detected and what didn't | 15:58 |
| mason | nemo: Alright, hardware's too new. I spoke to that. :P | 15:58 |
| mason | Ooh. At the end of that post... So, I can say for sure that the free AMD drivers are fine for gaming. My son uses an AMD GPU in his rig, using the free drivers, and he's able to play anything and everything, including pretty demanding/AAA games. | 15:59 |
| mason | nemo: That said, good practise there, gathering notes like that in a shareable form. | 16:03 |
| mason | nemo: FWIW, I posted a note to dng last night and it links to some kernel-building instructions. You could fairly easily build a very-new kernel using similar instructions. | 16:05 |
| mason | That's why I used to build my own kernels. Now I'm just doing it to build in ZFS, but the theory would still work. | 16:06 |
| nemo | mason: I've had mixed results with free driver. | 16:44 |
| nemo | mason: it depends a LOT on the game | 16:44 |
| nemo | mason: I try to spotcheck a few of the more demanding ones | 16:44 |
| mason | I can believe that. | 16:44 |
| nemo | mason: and... keep in mind this is the main living room family machine, it's not just her playing stuff, it's me too | 16:44 |
| nemo | or me playing and kids spectating | 16:44 |
| mason | I've heard people report that, also, just haven't seen it here yet, and my son plays way more games than I do. | 16:44 |
| nemo | mason: even old stuff | 16:45 |
| nemo | for example, I used the nvidia free driver for a long time, and it worked on, for example... Planetary Annihilation. No problem. | 16:45 |
| nemo | by contrast, Witcher 2. no love | 16:45 |
| mason | I don't really have a horse in the race, but I'll note that I'm looking at AMD for future kid machines based on the strength of my son's experience with his latest machine. That said, I quite like nVidia. | 16:45 |
| nemo | that with a 5 year old card | 16:45 |
| nemo | mason: this is my first pure AMD machine. CPU and GPU | 16:46 |
| nemo | and was a little bleeding edge since it was intended to be our snazzy glass sided LED thing | 16:46 |
| nemo | and I ran into a few fun issues like Devuan not having firmware as noted in that article | 16:46 |
| nemo | another one was the AMD rdrand bug | 16:46 |
| nemo | that one is funny 'cause thanks to Devuan I didn't notice I had a problem for months | 16:46 |
| nemo | until I tried a QT app that generated a guid and it was always {fffff-ffff etc | 16:47 |
| mason | hrm | 16:47 |
| nemo | mason: I tried following some instructions for updating firmware manually but did not work | 16:50 |
| nemo | or at least did not fix the rdrand bug | 16:50 |
| onefang | What rdrand bug? | 16:50 |
| nemo | mason: sooooo actually, if you know of anyone out there who has successfully done this on Devuan Beowulf. Like I said it's low priority for me, but I bet it's annoying if one uses say KDE | 16:50 |
| nemo | https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/ | 16:51 |
| nemo | onefang: ↑ | 16:51 |
| nemo | onefang: it totally effed systemd up 'cause they used rdrand as exclusive source of randomness *and* had an infinite loop that checked that a new value was issued, apparently. | 16:52 |
| nemo | well, it checked for rdrand support, then used it, and when validating values did not break out of loop | 16:52 |
| nemo | they patched it. | 16:52 |
| nemo | but still sucks if you're trying to setup a system I guess, and your install media has the bug | 16:52 |
| nemo | mason: s/firmware/microcode/ | 16:52 |
| nemo | mason: hmmmm lemme recheck real quick to see if latest update I did, the one that killed my GPU acceleration, maybe had the microcode fixes | 16:53 |
| onefang | I just built a Threadripper 3990X and Radeon RX 5600 XT BE desktop. | 16:54 |
| mason | nemo: You can oftentimes get the latest microcode from your motherboard vendor. Alternately, you can get it upstream from AMD (or Intel) and supply it via the (in this case) amd64-microcode package. | 16:54 |
| nemo | {ffffffff-ffff-4fff-bfff-ffffffffffff} ← guid in a qt app in latest beowulf. so nope | 16:54 |
| nemo | mason: yeah. the package thing was what I'd tried. or at least I thought I was trying | 16:54 |
| nemo | mason: some debian "latest stable microcode package" thing that I thought had this fix, but clearly didn't | 16:55 |
| mason | nemo: You should be able to see kernel buffer messages that confirm you've got the version in you want, but it's been a while. I did this stuff a bunch when the Spectre vulnerabilities first came to light. | 16:55 |
| nemo | gotta look at it again, just been low priority since the only thing it is visibly breaking right now is Hedgewars random seed for maps since it is a qt5 app | 16:55 |
| nemo | mason: yeah, that's the surprising thing. debian was super good at getting patches out for spectre/meltdown | 16:55 |
| nemo | mason: this one seems serious too, so you'd think I wouldn't have to do anything | 16:56 |
| onefang | I don't do gaming though, but I do 3D virtual world development. I did have to mess around with backports and an external repo to get 3D working. | 16:58 |
| onefang | http://ppa.launchpad.net/kisak/turtle/ubuntu bionic main and a tiny hack. | 16:59 |
| onefang | I don't have this rdrand bug. | 17:04 |
| nemo | onefang: what CPU? | 17:22 |
| onefang | I said Threadripper 3990X. | 17:22 |
| nemo | ok | 17:22 |
| nemo | $ ssh 10.3 'cat /proc/cpuinfo' | grep "model name" | head -n 1 | 17:22 |
| nemo | model name : AMD Ryzen 5 3600 6-Core Processor | 17:22 |
| nemo | onefang: it may well have been fixed by now... | 17:23 |
| nemo | I mean it was discovered a year ago | 17:23 |
| onefang | model name : AMD Ryzen Threadripper 3990X 64-Core Processor | 17:24 |
| nemo | onefang: quick testcase just to verify | 17:46 |
| nemo | $ g++ -fPIC -I /usr/include/x86_64-linux-gnu/qt5/ -I /usr/include/x86_64-linux-gnu/qt5/QtCore/ quuid.cpp -lQt5Core | 17:46 |
| nemo | ./a.out | 17:46 |
| nemo | {ffffffff-ffff-4fff-bfff-ffffffffffff} | 17:46 |
| nemo | https://m8y.org/tmp/quuid.cpp | 17:46 |
| nemo | onefang: but it is entirely possible that AMD fixed this before release of the 3990X | 17:47 |
| nemo | (the a.out above is on latest debian) | 17:48 |
| nemo | er. latest devuan | 17:48 |
| nemo | hmmm odd. 3990X shows up in list of impacted models | 17:52 |
| nemo | onefang: you're definitely using beowulf? | 17:52 |
| onefang | Yep, a debootstrappd Devuan Beowulf. | 18:25 |
| onefang | Kernel and firmwares from beowulf-backports. | 18:27 |
| clort | there's a newish 5.9 kernel for khadas vim3 - going to do a conversion to devuan soon | 19:53 |
| clort | it's fun to take 'whatever' kernel and switch OS to devuan without rebooting | 19:53 |
| clort | the fact that this is doable is very enjoyable to me | 19:54 |
| suavedandy | So I added a new LUKS1 device to crypttab. Started cryptdisks_start and got warnings about crypttab not having hash, size and something else I forgot. Why is this happening? Added the device to crypttab with luks.discard option. | 20:00 |
| suavedandy | Ah, it's cipher. | 20:02 |
| suavedandy | Cipher, size and hash. | 20:02 |
| suavedandy | Or is it unimportant because cipher, size and hash get default values? | 20:03 |
| clort | idk | 20:24 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!