xrogaan | this is why we can't have nice things: https://github.com/mate-desktop/mate-terminal/blob/078d0b1fdac2e50dfa4411b612e78a4be134e47d/src/terminal-screen.c#L1431 | 00:49 |
---|---|---|
xrogaan | been trying to get colors properly setup, but mate is yet again being silly. | 00:49 |
xrogaan | https://github.com/mate-desktop/mate-terminal/issues/209 < yeah, I believe it is time for me to switch DE | 01:19 |
xrogaan | which terminal do you guys use? | 02:03 |
xrogaan | urxvt is a bit too raw for me. | 02:03 |
fsmithred | xfce4-terminal in xfce, lxterminal with openbox, and xterm is used by refractainstaller | 02:05 |
gnarface | what's wrong with urxvt? | 02:07 |
phogg | urxvt is the best. It has every feature you could want and a rather good amount of compatibility | 02:08 |
xrogaan | yeah, but xterm somehow doesn't set TERM to xterm-256color | 02:10 |
xrogaan | even though it should be compatible by default | 02:10 |
fsmithred | when do you use TERM? | 02:11 |
xrogaan | I don't. | 02:11 |
fsmithred | when does anyone use it? | 02:11 |
xrogaan | xterm use term | 02:11 |
fsmithred | mine is set to xterm, but xterm never comes up unless I call it | 02:11 |
xrogaan | and the bashrc thing use $TERM | 02:11 |
xrogaan | tput colors use TERM | 02:12 |
xrogaan | with just xterm, tput will output 8. | 02:12 |
MinceR | urxvt is slow as molasses | 02:12 |
phogg | MinceR: compared to what? | 02:12 |
MinceR | compared to just about everything else | 02:12 |
MinceR | very visible on a raspberry pi 1 | 02:12 |
MinceR | i use terminate, but that isn't perfect either | 02:12 |
xrogaan | So I can't detect if the current term is stupid or does support 256 colors. Which means I can't properly configure my bash prompt. | 02:13 |
MinceR | well, everything i had on raspbian7, anyway | 02:13 |
xrogaan | I installed guake from source, because for some reason its TERM env was overridden by something. | 02:14 |
xrogaan | It's quite frustrating. | 02:14 |
MinceR | yeah, i use guake for dropdown terminal where xfce4-terminal doesn't support that mode yet | 02:16 |
MinceR | but i only use it to launch stuff, pretty much | 02:16 |
MinceR | like a smarter run dialog | 02:16 |
xrogaan | what does echo $TERM in xfce4-terminal returns? | 02:20 |
MinceR | xterm-256color | 02:24 |
fsmithred | my xfce4-terminal says xterm | 02:25 |
xrogaan | huh | 02:33 |
xrogaan | apparently, xfce4-terminal shouldn't set the $TERM variable and thus use defaults? | 02:35 |
xrogaan | but it's weird that both of you get different results. | 02:36 |
fsmithred | xfce4-term and lxterm give me full palette of colors | 02:36 |
fsmithred | oh, that's for bg and fg | 02:37 |
xrogaan | really? Does `tput colors' returns 256? | 02:37 |
fsmithred | are you messing with the colors in bashrc? | 02:37 |
xrogaan | no | 02:37 |
fsmithred | 8 | 02:37 |
xrogaan | I'm trying to not override $TERM | 02:38 |
fsmithred | 8 in xfce and lx | 02:38 |
MinceR | i checked it on slackware though | 02:38 |
MinceR | that's where i have xfce4-terminal atm | 02:38 |
xrogaan | If I understand the source correctly, xfce4 inherit the environment variables. | 02:40 |
xrogaan | I had the same issue with guake, it was setting $TERM to xterm-256color yet the final value get set to xterm. | 02:41 |
xrogaan | probably something rotten in MATE | 02:43 |
xrogaan | or maybe not | 02:43 |
xrogaan | the gnome-terminal works just fine. And guake from pip works just fine too. | 02:44 |
xrogaan | fsmithred: htop makes use of xterm-256color | 03:49 |
xrogaan | actually, any cli app that make use of color will benefit from it. | 03:49 |
gnarface | it makes emacs super nice :) | 03:54 |
fsmithred | looks like I have 256 colors. | 03:56 |
fsmithred | 256-colors.sh says so | 03:56 |
xrogaan | yes, everybody does. | 04:12 |
xrogaan | unless you connect through putty or another weird use case that doesn't give you all the colors. | 04:13 |
DocScrutinizer05 | it's quite funny how $TERM comes up as a topic now that I asked | 09:07 |
DocScrutinizer05 | [2018-08-26 15:36:41] <DocScrutinizer05> damn, did "recent" ssh client updates (+ related libs) cghange the environment and/or behavior of *server* where I log in to with this ssh client? E.G. I can't start mc anymore, I get: | 09:07 |
DocScrutinizer05 | [2018-08-26 15:36:45] <DocScrutinizer05> IroN900:~# mc | 09:07 |
DocScrutinizer05 | [2018-08-26 15:36:45] <DocScrutinizer05> Error opening terminal: xterm-256color. | 09:07 |
DocScrutinizer05 | oops sorry, I hit "paste" instead of "edit" | 09:07 |
DocScrutinizer05 | AIUI there's a linux world wide move from TERM=xterm to TERM=xterm-256color, across all distros, maybe started by https://bugzilla.gnome.org/show_bug.cgi?id=740641 - alas some "old" systems don't like that move so you get hiccups when you log in to those from a system whose ssh exports a TERM=xterm-256color, see above old Iron900 maemo system | 09:12 |
DocScrutinizer05 | I wonder what's the canonical way to deal with this now. "Fix" my old systems that need TERM=xterm, with a [ "xterm-256color" == "$TERM" ] && TERM=xterm, somewhere in .profile or .bashrc or ssh logon or whatever (and what/where, then), or revert&fix back to plain TERM=xterm on all "new" systems, or only with ssh client of those "new" systems | 09:19 |
acdimalev | DocScrutinizer51: For dealing with large-scale infrastructure that I don't manage, I've found setting up an SSH alias that sets `TERM` to be very effective. For anything that I do manage, I would be tempted to either backport a package, or look ahead at where a future update will dump the terminfo file and just drop a copy there. | 09:46 |
DocScrutinizer05 | "future update" sounds a tad funny for this particular case: maemo5 | 09:47 |
DocScrutinizer05 | thanks, it sounds very reasonable approach | 09:48 |
DocScrutinizer05 | I gather I could deal with this in .ssh/vonfig too? | 09:50 |
DocScrutinizer05 | config even | 09:50 |
acdimalev | No problem. I've had to deal with this problem ever since I adopted a terminal emulator that doesn't set `TERM` to either `xterm` or `xterm-256color`. | 09:50 |
DocScrutinizer05 | I mean, _all_ my ssh logins have a record in my ssh config | 09:51 |
acdimalev | Not that I've been able to tell. The SSH config file controls which environment variables get forwarded, but I haven't seen any options for setting environment variables. | 09:51 |
acdimalev | I wish it did, and if anybody can point out an oversight on my behalf, I'd be delighted. | 09:52 |
DocScrutinizer05 | hmmm, I guess when I do NOT forward xterm-256color then the target system falls back to sane? | 09:52 |
acdimalev | Just run `unset TERM` on a local terminal and try a few things. | 09:52 |
acdimalev | I don't think the sane defaults are going to meet your expectations. | 09:53 |
DocScrutinizer05 | damn, I should write a ssh alias that copies my complete "environment" like ~/.profile ~/.aliases ~/bin etc pp, on *each* login ;-) | 09:53 |
DocScrutinizer05 | ;-) | 09:54 |
acdimalev | Not that I have time to look into it at the moment, but that does make me wonder how difficult it would be to add support for such an option to Open SSH. | 09:55 |
acdimalev | It would be incredibly useful to be able to specify environment variables for a specific SSH host. | 09:56 |
DocScrutinizer05 | "such an option" to set $ENV? | 09:56 |
DocScrutinizer05 | or to run a script during login? | 09:57 |
acdimalev | `SetEnv TERM xterm` in `~/.ssh/config` is what I'm thinking. | 09:57 |
DocScrutinizer05 | the latter should cover the former, sourcing instead of exec'ing the script | 09:58 |
acdimalev | It would be useful for way more than just setting up a term. | 09:58 |
acdimalev | In the days where my server logins were single digit and automated server builds were not a thing, it made sense to try and adjust everything server-side. | 09:59 |
DocScrutinizer05 | script for sure. I know you can define binaries to execute regardless of commandline, on ssh *server* side in the pubkey record | 10:00 |
DocScrutinizer05 | a pity that despite it sounds very similar, it doesn't apply at all for this usecase | 10:00 |
acdimalev | It sounds like you're dealing with a single device? In that case, definitely do not trouble yourself with an effort besides correcting that single instance. | 10:02 |
DocScrutinizer05 | hmmmmm, you could get a wrapper script around the `ssh` binary, to parse your ~/.ssh/config | 10:02 |
DocScrutinizer05 | acdimalev: ack, but I *love* solving problems for good. since I hate running into them a second time ;-) | 10:03 |
DocScrutinizer05 | a wrapper script should be versatle and simple enough to even be fun to implement | 10:06 |
DocScrutinizer05 | what sucks a bit is duplicating all the parameter&option parsing syntax/semantics of ssh cmdline | 10:07 |
acdimalev | Well... what all would you want to be able to modify about the runtime environment based on the contents of the SSH config? | 10:10 |
acdimalev | I have a use-case for setting environment variables, but I'm not too sure I have a solid use-case for anything else. | 10:11 |
DocScrutinizer05 | (parse) actually not that bad, only [-F configfile] needs special treatment, discard all other -options and catch the first non-option argument which is user@]host[:port] or [user@]hostname | 10:13 |
acdimalev | If I really wanted a "do anything" setup, it would involve executing a binary with the the original SSH command, but also with an additional command-line switch to exclude running the binary wrapper (to avoid recursive binary wrapper execution). | 10:16 |
DocScrutinizer05 | then parse ${configfile:-~/.ssh/config} for the $"[user@]hostname" you derived from step#1, and in that record find the new command "#!source <filename>" | 10:16 |
acdimalev | But I really can't think of a use-case that would require such a binary wrapper to do anything other than set environment variables to fixed values. | 10:17 |
DocScrutinizer05 | then `source <filename> && ssh $@` | 10:17 |
DocScrutinizer05 | I can't think of a usecase where I would bother to restrict the capabilities of such a wrapper | 10:18 |
acdimalev | I don't mean regarding restriction... it just seems excessive for what would otherwise be an option to set environment variables to fixed values. | 10:19 |
DocScrutinizer05 | after all it's pretty hard to come up with a shorter generic solution | 10:19 |
DocScrutinizer05 | for such "option to set environment variables to fixed values" you also need a wrapper, or patch the binary | 10:20 |
DocScrutinizer05 | for your convenience, I will add "#!setenv ENV=value" as valid new command, concurrently to "#!source <filename>" - will only cost an additional 4 LOC in that wrapper script | 10:22 |
DocScrutinizer05 | :-) | 10:22 |
DocScrutinizer05 | while the "#!source <filename>" prolly only costs 3 LOC | 10:23 |
DocScrutinizer05 | the rest is common to both approaches | 10:23 |
acdimalev | I would think a binary patch is likely to be upstreamed. | 10:23 |
DocScrutinizer05 | I'm sure a wrapper script isn't | 10:23 |
DocScrutinizer05 | but I'm also sure I don't feel like messing with ssh sourcecode | 10:24 |
DocScrutinizer05 | again and again for each update, until my patch actually gets upstreamed maybe, eventually | 10:24 |
DocScrutinizer05 | ;-) | 10:25 |
acdimalev | I have good news. | 10:31 |
acdimalev | You won't have to. | 10:31 |
acdimalev | https://anongit.mindrot.org/openssh.git/tree/ssh_config.5#n1435 | 10:31 |
acdimalev | We're now just waiting for a version of Open SSH to release that has this functionality. | 10:32 |
DocScrutinizer05 | umm what am I looking at? :-o | 10:33 |
acdimalev | Documentation for a `SetEnv` option in `ssh_config` for the master branch of upstream Open SSH. | 10:34 |
DocScrutinizer05 | documentation? ooooh | 10:35 |
DocScrutinizer05 | anyway, seems you're happy | 10:35 |
DocScrutinizer05 | while I know how to tackle my problem | 10:35 |
acdimalev | Sounds about right. | 10:37 |
acdimalev | Software fresh off the shelf... Open SSH made a release five days ago that has this new functionality. | 10:37 |
DocScrutinizer05 | ooh | 10:38 |
DocScrutinizer05 | you got a version string or whatever, to look for? | 10:39 |
acdimalev | 7.8p1 | 10:40 |
DocScrutinizer05 | ta! | 10:40 |
DocScrutinizer05 | OpenSSH_7.6p1, OpenSSL 1.1.0h-fips 27 Mar 2018 here, hmmmm | 10:41 |
acdimalev | As I said, five days ago. :) | 10:41 |
acdimalev | I'm sure it'll take a minute for even the rolling-release distros to push this out. | 10:42 |
acdimalev | Can always build from source if super-anxious. | 10:42 |
DocScrutinizer05 | that's what I wonder | 10:43 |
DocScrutinizer05 | for my distro, maybe there's sth in factory | 10:43 |
DocScrutinizer05 | https://build.opensuse.org/package/show/home%3Avicidial/openssh 7.7p1 | 10:47 |
acdimalev | Only one release behind. :) | 10:53 |
Centurion_Dan | the other way to do it is to include the command in the stanza in ~/.ssh/authorized_keys on the host that way it's run post login anyway. In fact you should be able to define this as an action in the ssh_dconfig on the server your connecting to for a universal setting specific to that server. | 11:28 |
Centurion_Dan | *sshd_config | 11:29 |
Centurion_Dan | DocScrutinizer05: ^^ | 11:29 |
DocScrutinizer05 | Centurion_Dan: yes, that's what I incorrectly(?) referred to as "define binaries to execute regardless of commandline, on ssh *server* side in the pubkey record" | 11:33 |
lead_dipper | what would need to happen to make debsecan work properly in devuan? it uses debian's security tracker, would devuan need something similar? Sorry if this has been asked before, I couldn't find any mentions on the forum or wiki. | 11:33 |
DocScrutinizer05 | Centurion_Dan: alas this isn't client specific unless you got a one unique key pair per client | 11:33 |
Centurion_Dan | lead_dipper: we have somebody working on this already... | 11:35 |
lead_dipper | nice | 11:35 |
acdimalev | Centurion_Dan: I assume this is where any security tracking will surface?: https://devuan.org/os/security/ | 11:45 |
Centurion_Dan | DocScrutinizer05: it is if you only set it up on the pubkey entry on the servers where you want it. I have several keys in use so it wouldn't be such an issue. For a start I have a different key for devuan servers then I use for my clients. And when you combine that with using ~/.ssh/config to direct which keys to use for which host - it's all good. | 11:47 |
Moane | hello/bonjour/hola | 12:45 |
DocScrutinizer05 | aloha | 13:49 |
levente | hey, I was wondering if I am able to install the proprietary nvidia drivers from the repos | 19:17 |
gnarface | yep, that's a thing | 19:21 |
gnarface | (they're in non-free) | 19:21 |
levente | how can I enable that? | 19:22 |
gnarface | you should also enable contrib at the same time | 19:23 |
golinux | In sources.list | 19:23 |
gnarface | it should be as easy as adding " contrib non-free" to the end of every line in sources.list | 19:23 |
gnarface | pastebin your sources.list if you want it proofread | 19:23 |
gnarface | (and don't forget you'll need to run `apt-get update` for changes to take effect) | 19:24 |
furrywolf | isn't sources.list management something that should have a pointy-clicky frontend by now? | 19:26 |
levente | https://pastebin.com/cN0MHuRW | 19:27 |
levente | Does this look good | 19:27 |
gnarface | i think so | 19:29 |
levente | thanks | 19:29 |
gnarface | if you need NEW nvidia drivers, you'll need them from backports | 19:30 |
gnarface | otherwise this should be fine | 19:30 |
levente | what are the main nvidia driver packages? | 19:30 |
levente | and do I have to manually disable nouveau | 19:30 |
gnarface | nvidia-driver | 19:30 |
gnarface | nvidia-driver-bin | 19:30 |
gnarface | libgl1-nvidia-glx | 19:30 |
gnarface | nvidia-settings | 19:30 |
gnarface | yea, you probably have to manually disable nouveau. | 19:31 |
levente | ah okay | 19:31 |
levente | thanks | 19:31 |
levente | so these packages should suffice? | 19:31 |
gnarface | yea, probably. it should get all the 64-bit stuff you need anyway. and just blacklist nouveau in /etc/modules.d if it isn't already when they're installed. | 19:31 |
gnarface | if you also need 32-bit stuff (like for wine and steam support) you'll need to also enable multi-arch | 19:32 |
levente | doesn't wine have a 64 bit version | 19:32 |
levente | I'm back, I rebooted | 19:36 |
levente | the resolution is wrong | 19:36 |
levente | I'm not sure where the logs are for this | 19:36 |
gnarface | it would probably be either /var/log/Xorg.0.log or ~/.local/share/xorg/Xorg.0.log | 19:38 |
gnarface | and yes, wine has a 64-bit version but a lot of windows software still requires 32-bit support even when it's 64-bit (i'll refrain from soapboxing about the stupidity and injustice of that, just accept that it's the case) | 19:39 |
levente | uhh nouveau loaded for some reason but the resolution is bad, it was fine before the reboot | 19:39 |
gnarface | you sure it actually loaded? | 19:40 |
gnarface | did you forget to blacklist nouveau? | 19:40 |
levente | (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so | 19:40 |
levente | where do I whitelist it again? | 19:40 |
gnarface | blacklist | 19:41 |
levente | yeah, that sorry | 19:41 |
gnarface | do me a favor and run this command | 19:41 |
gnarface | grep -rni 'blacklist.*nouveau' /etc/modprobe.d | 19:41 |
gnarface | see any output? | 19:41 |
levente | no, I didn't whitelist it just yet, I just disabled it with the grub config | 19:41 |
gnarface | *blacklist | 19:41 |
gnarface | there is an important difference in terminology here | 19:42 |
gnarface | pick any conf file in /etc/modprobe.d or add your own then add this line to it: | 19:42 |
gnarface | blacklist nouveau | 19:42 |
gnarface | (then reboot again) | 19:42 |
levente | I'm getting spammed with a few 'possible missing firmware' warnings, is that fine | 19:43 |
levente | when updating initramfs | 19:43 |
gnarface | it might be fine it might not | 19:43 |
gnarface | depends on which firmware it's missing | 19:44 |
levente | should I pastebin it | 19:44 |
gnarface | the nvidia drivers should have their own firmware. it's about some other hardware, isn't it? | 19:44 |
levente | something about rtl_nic | 19:44 |
gnarface | go ahead and pastebin it i'll see if i recognize it | 19:44 |
gnarface | yea you probably are missing the realtek firmware for gigabit ethernet links | 19:44 |
gnarface | that's a separate issue, stay on target | 19:45 |
levente | ah okay | 19:45 |
levente | rebooting again | 19:45 |
levente | It's still wrong | 19:47 |
levente | I've seen something about nvidia_drm not being able to load when booting | 19:47 |
gnarface | well that's not unexpected, but first we have to make sure nouveau didn't load first | 19:47 |
levente | okay | 19:47 |
gnarface | the resolution could be wrong for additional reasons. sometimes it still needs a manual configuration depending on your display type | 19:48 |
levente | nouveau was able to detect it, I don't see why the proprietary driver won't | 19:49 |
gnarface | sometimes blacklisting nouveau isn't enough and some other wrong driver just loads instead | 19:49 |
gnarface | but you shouldn't be super surprised that nouveau is better at playing nice with xorg | 19:49 |
gnarface | it's got worse hardware support but it's not made by people who support linux under duress | 19:50 |
gnarface | can you pastebin the Xorg log? | 19:50 |
levente | nvidia drivers suck, I don't know why they don't care about linx users | 19:50 |
levente | yes | 19:50 |
gnarface | the missing firmware for that ethernet device is probably in "firmware-realtek" (also in non-free) | 19:51 |
gnarface | but it may also be in the package firmware-linux-free which is in main | 19:51 |
levente | http://0x0.st/stm8.log | 19:52 |
levente | the log file | 19:52 |
gnarface | ugh | 19:52 |
gnarface | nope | 19:52 |
gnarface | not clickin on that | 19:52 |
gnarface | could you use paste.debian.net please? | 19:52 |
levente | oh, sorry | 19:52 |
levente | yes | 19:53 |
gnarface | that's not channel policy that's just my policy | 19:53 |
levente | but it's hard to paste from CLI and I can do that to 0x0.st with curl | 19:53 |
gnarface | there's a cli program called pastebinit | 19:53 |
gnarface | it's in the repo | 19:53 |
levente | http://paste.debian.net/1039688/ | 19:54 |
levente | got it, thanks | 19:54 |
gnarface | hmmm | 19:54 |
gnarface | still loading nouveau | 19:54 |
levente | I have blacklisted it | 19:54 |
gnarface | check this output: lsmod |grep nouveau | 19:55 |
levente | no output | 19:55 |
gnarface | do you have a log file in ~/.local/share/xorg? | 19:55 |
levente | root or my actual user | 19:56 |
gnarface | your actual user | 19:56 |
levente | nope, I don't even have a xorg directory | 19:56 |
gnarface | you're starting Xorg as your actual user, right? | 19:56 |
gnarface | or are you using a graphical login manager? | 19:56 |
levente | I don't know how slim starts it | 19:56 |
levente | yes | 19:56 |
gnarface | hmm. ok | 19:56 |
gnarface | so the log is /var/log/Xorg.0.log and you can tell by the datestamps that it's being replaced every time you reboot, right? | 19:57 |
levente | should I delete it and reboot? | 19:57 |
gnarface | no, but there's some cases where it might be changed to Xorg.1.log or something like that if you're running more than one xorg instance | 19:57 |
levente | I only have Xorg.1.log | 19:57 |
levente | no, I mean 0 | 19:57 |
levente | Xorg.0.log | 19:58 |
gnarface | hmm. ok | 19:58 |
gnarface | in your /etc/default/grub file, is it setting a console resolution at boot? | 19:59 |
levente | let me paste it | 20:00 |
levente | http://paste.debian.net/1039691/ | 20:00 |
gnarface | ok | 20:01 |
gnarface | only one thing is different there from mine | 20:01 |
gnarface | line #10 | 20:01 |
gnarface | change yours to this: GRUB_CMDLINE_LINUX="nomodeset" | 20:01 |
levente | okay | 20:01 |
gnarface | actually | 20:01 |
gnarface | i also removed quiet from line 9 | 20:02 |
gnarface | but that's not necessary | 20:02 |
levente | what does quiet do? | 20:02 |
gnarface | it just suppresses a lot of the console output at startup | 20:02 |
levente | by the way, what init system does devuan use by default | 20:02 |
gnarface | the old one that debian was using before systemd (wheezy and earlier) | 20:03 |
levente | systemvinit? | 20:03 |
gnarface | yes, but the other ones are all still present and available as options | 20:03 |
levente | Okay, I updated grub | 20:03 |
levente | should I reboot now | 20:04 |
gnarface | yea, just to try it. but we may still need to make an xorg.conf for you | 20:04 |
levente | I am back with a bad driver again | 20:07 |
gnarface | levente: i just remembered something. you also have to add that user to the "video" group | 20:07 |
levente | ah | 20:07 |
levente | done | 20:08 |
gnarface | you'll have to reboot, or at least restart slim] | 20:08 |
levente | rebooting is easier and faster | 20:08 |
levente | brb then | 20:08 |
levente | yup, still bad | 20:10 |
gnarface | hmm. drat | 20:10 |
levente | yeah | 20:10 |
gnarface | ok, let's see the new xorg.log | 20:10 |
gnarface | something should have changed at least | 20:10 |
gnarface | *Xorg.0.log | 20:10 |
levente | http://paste.debian.net/1039694/ | 20:11 |
gnarface | something's still not right | 20:12 |
gnarface | i'm missing something still | 20:12 |
gnarface | hmmmm | 20:12 |
gnarface | ok gimme 10 minutes i have to go AFK sorry | 20:12 |
levente | ye np, thanks for your help so far | 20:13 |
gnarface | we gotta figure out why this is still loading nouveau | 20:13 |
levente | I got used to gentoo, So I could rebuild the kernel | 20:13 |
fsmithred | update-grub after editing /etc/default/grub | 20:14 |
levente | I did | 20:14 |
fsmithred | ok | 20:14 |
fsmithred | maybe you need xorg.conf | 20:15 |
fsmithred | did nvidia make one for you? | 20:15 |
fsmithred | (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) | 20:15 |
levente | I'm not sure | 20:19 |
fsmithred | I think if you run nvidia-xconfig it will make a sample xorg.conf | 20:20 |
fsmithred | been a couple years since I've used nvidia | 20:20 |
levente | I don't have any command called nvidia-xconfig | 20:20 |
fsmithred | ok | 20:20 |
levente | I did have it on other distros though, which is weird | 20:20 |
fsmithred | it might be a separate package | 20:20 |
fsmithred | and you get it by default if you install the binaries downloaded from nvidia | 20:21 |
levente | I installed the drivers with apt | 20:21 |
fsmithred | yeah, I haven't done it that way as many times as I've done it the other way | 20:21 |
gnarface | levente: what's the card model? | 20:29 |
gnarface | levente: it occurs to me that nvidia has deprecated everything before the 600 series | 20:30 |
levente | I have a GTX 750 TI | 20:30 |
gnarface | that should still work | 20:30 |
levente | yeah... | 20:30 |
gnarface | is it an optimus laptop? | 20:30 |
levente | It's a desktop | 20:30 |
gnarface | ok. and the GPU isn't onboard? | 20:30 |
levente | No, it's a dedicated GPU | 20:31 |
gnarface | ok | 20:31 |
gnarface | so this should work and we're just overlooking something | 20:31 |
gnarface | it might be the xorg.conf but i feel like nvidia should at least LOAD without it... | 20:31 |
gnarface | it shouldn't be loading a blacklisted driver that's for sure | 20:31 |
gnarface | levente: when you blacklisted nouveau, did you create a new file or add to an existing one? | 20:32 |
levente | there was already a file named nvidia-blacklists-nouveau.conf | 20:32 |
gnarface | ok | 20:32 |
levente | it already had 'blacklist nouveau' in it | 20:32 |
gnarface | ok, that should be working | 20:32 |
gnarface | hmmm | 20:34 |
gnarface | levente: what if you run this as root? `X -configure` | 20:37 |
levente | server already active, let me stop it | 20:37 |
gnarface | it should generate an xorg.conf.new but i'm curious what i'll put in it | 20:37 |
gnarface | you'll have to stop slim too | 20:37 |
levente | yes | 20:37 |
levente | yeah, I did that | 20:38 |
levente | It didn't list nvidia when it listed all the drivers though | 20:39 |
gnarface | hmm | 20:40 |
gnarface | show me the output of: dpkg -l |grep nvidia -i | 20:40 |
gnarface | also, re-run `update-initramfs -u -k all` just for good measure | 20:41 |
levente | http://paste.debian.net/1039699/ | 20:42 |
gnarface | hmmm | 20:43 |
gnarface | looks fine | 20:43 |
gnarface | what about the contents of /etc/X11/Xsession.options? | 20:43 |
levente | http://paste.debian.net/1039700/ | 20:44 |
gnarface | same as mine | 20:45 |
gnarface | i feel like there's something i'm forgetting | 20:45 |
levente | hmm | 20:45 |
gnarface | but nothing comes to mind right now except my manual xorg.conf creation | 20:45 |
levente | nvidia drivers never liked me | 20:46 |
gnarface | so i guess that's what we should try next for you | 20:46 |
gnarface | in theory you shouldn't need the whole thing so we'll just start with a snippet | 20:46 |
gnarface | stand by i'll try to find a similar example here | 20:46 |
levente | also, what should I do with xorg.conf.new? | 20:47 |
levente | since you made me make one | 20:47 |
levente | X -configure listed all the drivers but nvidia wasn't among them | 20:47 |
gnarface | oh, i was gonna ask you to pastebin the xorg.conf.new if it used the nvidia driver by default | 20:47 |
levente | I doubt that, but I will paste it anyways | 20:48 |
gnarface | just hold onto it for now you still may need to reference it | 20:48 |
levente | xorg.conf.new: http://paste.debian.net/1039700/ | 20:48 |
levente | wrong paste | 20:48 |
levente | http://paste.debian.net/1039702/ | 20:49 |
gnarface | oh | 20:51 |
gnarface | interesting | 20:51 |
gnarface | that looks right actually | 20:51 |
gnarface | you might only actually need this much of it though: http://paste.debian.net/1039703/ | 20:52 |
gnarface | the critical point is that it should at least error about why it can't load the nvidia driver instead of just skipping it | 20:52 |
gnarface | we should see a change in the log file | 20:52 |
levente | someone posted a snippet from the file above | 20:52 |
levente | let me look for it | 20:52 |
levente | <fsmithred> (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) | 20:53 |
levente | from the X log file, that is | 20:53 |
gnarface | yea, i saw that but it's already loading nouveau by then which should be blacklisted | 20:54 |
gnarface | so something is going wrong before that | 20:54 |
gnarface | something on the order of "are you sure this is the machine your terminal is actually logged into" wrong | 20:55 |
gnarface | so part of making an xorg.conf snippet is just to see if the log output actually changes in an expected fashion whether it works or not | 20:55 |
levente | okay, let me put that in the config file | 20:56 |
gnarface | if you get literally no change to the log output, something is REAAALY wrong here | 20:56 |
levente | where is the main config file for X located? | 20:57 |
gnarface | by default it no longer exists. but it still belongs in /etc/X11 | 20:58 |
levente | so just in /etc/X11? | 20:58 |
levente | no subdirectories? | 20:58 |
gnarface | you can create the file at /etc/X11/xorg.conf or in the subdirectory /etc/X11/xorg.conf.d | 20:59 |
gnarface | there's a couple other places too | 20:59 |
levente | xorg.conf, right? | 20:59 |
gnarface | yes | 20:59 |
levente | I will symlink it to xorg.conf.d just to make sure, or is that a bad idea? | 21:00 |
gnarface | well if you're gonna use the whole thing make it /etc/X11/xorg.conf but if you're just going for a snippet make it something like /etc/X11/xorg.conf.d/10-snippet-for-nvidia.conf | 21:00 |
gnarface | no symlinks | 21:00 |
gnarface | the top of that log file will tell you what configs it actually picks up | 21:00 |
gnarface | so we'll know if it even reads it | 21:00 |
levente | so do I reboot now? | 21:00 |
gnarface | yea | 21:01 |
levente | something went horribly wrong, slim wouldn't even load | 21:06 |
levente | I saw a message from the init though, it said 'error running install command for nvidia# | 21:06 |
gnarface | hmmm | 21:07 |
gnarface | ok | 21:07 |
gnarface | i wonder if dkms went awry | 21:08 |
gnarface | you have a package called "nvidia-kernel-dkms" installed, right? | 21:08 |
gnarface | if you do, run `dpkg-reconfigure nvidia-kernel-dkms` if not, install it. | 21:08 |
gnarface | first install the "dkms" package if it's not present too | 21:08 |
levente | Module build for kernel 4.9.0-6-amd64 was skipped since the | 21:09 |
levente | kernel headers for this kernel does not seem to be installed. | 21:09 |
levente | I think that may be the root of the problem | 21:09 |
gnarface | oh | 21:09 |
gnarface | yea, that's it | 21:10 |
gnarface | that would have made dkms fail, which would have meant your initrd.img won't have the nvidia module at boot time | 21:10 |
gnarface | that doesn't really explain how it loaded nouveau inspite of being blacklisted but it explains why nvidia didn't load | 21:10 |
gnarface | make sure you've installed 'linux-image-amd64' and 'linux-headers-amd64' then they'll both stay current with updates | 21:10 |
levente | I've installed them | 21:12 |
levente | It still says that the kernel headers are not installed | 21:13 |
levente | but it's building something | 21:13 |
levente | so I guess that's good | 21:13 |
gnarface | did the kernel update when you just did that? | 21:13 |
levente | DKMS: install completed. | 21:13 |
levente | No, it's still 4.9 | 21:13 |
gnarface | it's possible the headers and kernel you installed were not matching to the running one | 21:13 |
gnarface | that might have been the cause of the complaint | 21:14 |
levente | Haven't updated my kernel at all | 21:14 |
gnarface | well, either way, reboot agian to see if it worked | 21:14 |
levente | okay, brb | 21:14 |
levente | That seemed to fix it, my screen is back to normal now | 21:16 |
levente | thanks | 21:16 |
gnarface | whew | 21:16 |
gnarface | what amess | 21:16 |
gnarface | glad it works again though | 21:16 |
levente | I'm writing this down jesus christ, this was certainly a mess | 21:17 |
levente | yes, and it uses the nvidia driver now | 21:17 |
levente | tysm | 21:17 |
gnarface | no problem. it's not supposed to be that hard but nobody is really reaching the rest of the way across the aisle on this one | 21:17 |
gnarface | if you need to support 32-bit components of wine or steam you should just need to add libgl1-nvidia-glx:i386 | 21:19 |
gnarface | (after enabling multi-arch of course) | 21:19 |
levente | okay, thanks | 21:20 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!