14[00:07:07] <jadax> well, yeah, but I get this: E: Unable to locate package virtualbox-dkms
15[00:07:13] <zykotick9> After kernel update my zfs pool is not working. Debian stable using 4.19.0-10-amd64 everything works as expected - booting 4.19.0-11-amd64 kernel results in zfs module(s) not being loaded. Should I be running some dkms update process between kernel updates? What info would be useful to diagnose the issue?
25[00:08:14] <jadax> but my kernel still claims no module has been inserted
26[00:08:28] <sney> zykotick9: check in /lib/modules/$(uname -r)/updates to see if the module was built. if it was, you may need to add it to the initramfs
27[00:08:32] *** Quits: black_ant (~antilope@replaced-ip) (Quit: simplicity does not kill)
41[00:13:14] <jadax> but when I try to insert it, I get back "ERROR could not insert vboxdrv, exec format error"
42[00:13:14] <sney> what happens if you load it directly with modprobe?
43[00:13:19] <sney> ah.
44[00:13:24] <sney> how big is that file?
45[00:13:35] <jadax> [1229725.038519] module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 00000000d713a76d, val ffffffffc0fe84cf
46[00:13:37] <jadax> that's dmesg
47[00:13:45] <zykotick9> sney: I think might be onto something. in /lib/modules/4.19.0-11-amd64 (broken) there is no updates, there is in the working /lib/modules/4.19.0-10-amd64 and it has zfs related stuff.
52[00:14:10] <splinterz> user added to vboxusers group?
53[00:14:22] <genr8_> invalid relocation target is a serious compilation error
54[00:14:45] <jadax> should I rebuild?
55[00:15:12] <genr8_> i guess youll have to ?
56[00:15:15] <sney> zykotick9: make sure your kernel headers are installed for that 4.19.0-11 and 'dpkg-reconfigure zfs-dkms' will trigger the build, if it doesn't happen automatically
99[00:25:38] <jadax> There were problems setting up VirtualBox. To re-start the set-up process, run
100[00:25:38] <jadax> /sbin/vboxconfig
101[00:25:38] <jadax> as root. If your system is using EFI Secure Boot you may need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them. Please see your Linux system's documentation for more information.
102[00:25:52] <sney> jadax: just in case the vbox build script is stupid, could you delete vboxdrv.ko before triggering the rebuild? \
103[00:25:56] <jadax> do I need to sign these modules manually somehow?
104[00:25:59] <jadax> I could, yeah
105[00:26:01] <sney> are you using secure boot?
106[00:26:06] <sney> it's not required in efi
107[00:26:17] <genr8_> jadax, thats very old
108[00:26:34] <jadax> I think I am
109[00:26:35] <genr8_> the vbox6-1 likely is incompatible with such an old kernel
110[00:26:45] <jadax> my kernel is old?
111[00:26:54] *** Quits: paulgrmn (~paulgrmn@replaced-ip) (Remote host closed the connection)
112[00:26:59] <genr8_> yes
113[00:27:05] <genr8_> thats 6 versions old by now
114[00:27:06] <sney> buster is on 4.19.0-11 now, and backports has a 5.7 or 5.8
186[00:36:07] <sney> stability and long uptimes are great, though you should reboot for point releases at least. and anything involving dkms will often require reboots anyway, so there's your choice
187[00:36:46] <genr8_> the issue is youve installed the newest kernel headers but then didnt reboot into the newest kernel
188[00:36:53] <genr8_> so its telling the module to build for something newer that doesnt exist
199[00:39:48] <dpkg> You want to reboot for WHAT?? If it's not a new kernel or a hardware change, you probably don't need to reboot. Ask me about <qotd2>.
216[00:43:27] <sney> well, the live image has a standard debian text-only OS on it, while the netinst just has some busybox stuff and glue to get packages installed from the internet
231[00:49:02] <Emil> Well I mean there are seriously small linux images, and I doubt a functioning Debian installation requires that much more program to run
341[01:42:09] <genr8_> users tend to _install_ their debian, or pick a version thats 2.4GB and has a GUI
342[01:42:54] <genr8_> these packages seem to be coming out of "live-task-base" and "live-task-standard" and "live-task-recommended" and a few other ones.
353[01:49:52] <genr8_> which has "console-setup" and "keyboard-configuration" in it
354[01:51:35] <ghormoon> hi, is there some tool to convert snap package to deb? or some manual way to not to have to install snap store for one package?
362[01:59:03] <genr8_> picking finnish sets locales=fi_FI.UTF8 on the kernel command line, and LANG=fi_FI.UTF8 but the unicode shows up garbled in the console
363[02:00:15] <Mazhive> some one in for a test drive of my preseed file on a vm to get some feedback ?
370[02:09:58] <genr8_> apparently "it's a real 80x25 textmode terminal, so you can't use more than 256 characters. Use framebuffer console if you want real utf-8."
373[02:13:15] <A|an> If you intend to install the later version of GnuPG, there is an onboard version of gpg, to verify signatures, does that version need to be removed via dpkg?
374[02:13:42] <A|an> latest <- later
375[02:14:46] <genr8_> it will handle itself
376[02:15:14] <genr8_> onboard /usr/bin/gpg is actually gnupg
380[02:16:06] <A|an> I just got through installing gnupg_2.2.23 and checked the version...it's the correct version but using an older libgcrypt, not the version I installed...
433[02:32:47] <genr8_> I hate this shit. my grasp on it is not ideal, but: they either need to be in /usr/local/lib/x86_64-linux-gnu/ , /lib/x86_64-linux-gnu/ , /usr/lib/x86_64-linux-gnu/ , or you need to edit your ld.so.conf file to add the actual /usr/local/lib/dir they're in, then re-run "ldconfig" so it finds them. - or modify your LD_LIBRARY_PATH or LD_RUN_PATH env variables for your user
437[02:37:00] <genr8_> My conclusion is that, since the Makefile uses the system's compilers, the LDFLAGS that are already pre-set, and it links it with the system's /lib/x86_64-linux-gnu/ dir , then installs it somewhere else. likely to the /usr/local/lib/ root dir, which is not a valid location on debian for LD, it needs the subdir of the Triplet ARCH
439[02:37:23] <genr8_> if you run "sudo ldconfig -p | grep libgcrypt" you will see it pointing to the old system's library. Thats likely taking precedence.
440[02:37:32] <A|an> I was trying to upload the installation notes to pastezone, but too large
441[02:37:55] <genr8_> just search for ".so" and look where it went
442[02:38:11] <sney> !termbin
443[02:38:11] <dpkg> you can paste to termbin.com from terminal via: cat /path/to/file | nc termbin.com 9999
444[02:38:20] <genr8_> or find / -name libgcrypt.so
445[02:38:27] <genr8_> or find / -name libgcrypt.so*
450[02:42:21] *** Quits: victorpr (~victorpr@replaced-ip) (Remote host closed the connection)
451[02:42:30] <A|an> I'm not finding it. that's bizarre
452[02:42:51] <A|an> there were no problems running the installations
453[02:43:14] <A|an> I'll have to figure this out
454[02:43:18] <A|an> great
455[02:44:18] <genr8_> are you sure you built that lib itself? like I said its two different things. I dont have the source here to investigate for you
505[03:05:34] <A|an> so it wasn't finding the proper library, correct
506[03:06:18] <genr8_> yes. like I said, the /usr/local/lib/ root dir is not automatically valid on debian. only the subdir /usr/local/lib/x86_64-linux-gnu is, and it did not put them in that for some reason
508[03:07:34] <genr8_> so you could also make that dir and move all those files there. but thats more work than adding the root dir and I dont think it matters.
509[03:07:46] <A|an> ok
510[03:08:08] <genr8_> <genr8_> I would do "nano /etc/ld.so.conf.d/usr-local-lib.conf" and put "/usr/local/lib" inside it - then rerun "ldconfig" as root
511[03:08:51] <genr8_> after that, ldconfig should detect that 20.2.6 > 20.2.4 (again that corresponds to 1.8.6 and 1.8.4 for some reason) = and use the new one.
602[03:29:54] <genr8_> themill, its a good thing you mentioned that. I checked my terminal logs, i meant to read all those files, but it looks like I opened the same .conf file twice by accident and never checked libc.conf
776[04:49:10] *** Quits: ashka (~postmaste@replaced-ip) (Quit: En fait, le BSDiste, c'est comme l'homme politique, tu lui dis de quoi t'as besoin, il t'explique comment t'en passer)
785[04:50:44] <inerkick> I'm trying to install MagicFountain on my debain machine , it's app image isn't working. I am not sure how to do with the source file the developer provider. Please help replaced-url
849[05:30:22] <longears> Heh. :P I haven't been dealing with images for some time. I remembered the loop/bind, but couldn't really remember which one it was and how it was supposed to be used. :D
858[05:39:24] <longears> Probably. I just wanted for system to see that image is a block device. Then I can start messing with zfs. `losetup` did the job, so now I'm trying to figure out how to make zfs work on Debian. Going to be a fun evening.
859[05:40:44] <ryouma> great it worked. (maybe losetup makes a block device wherease mount -o loop bypasses that whole step?)
860[05:41:29] <longears> I guess so. I remember doing `mount -o loop` with ext[234] devices.
893[06:10:02] <willow> i installed the buster-backports linux-image-5.8.0-0. when i try to install the corresponding headers it says "Error! The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch"
894[06:10:54] <willow> the message is from /usr/src/aufs-4.19+20190211/dkms.conf which has line: BUILD_EXCLUSIVE_KERNEL="^4.19.*" aufs is needed for docker so i wonder if docker won't run with the 5.8 kernel?
938[07:13:25] <willow> genr8_: aufs-dkms which creates /usr/src/aufs-4.19+20190211/
939[07:13:43] <willow> genr8_: unfortunately there's not a bpo version available
940[07:15:13] <willow> running a docker container now and it's giving errors. i think aufs module needs to be built for the 5.8 kernel for docker to work
1117[10:08:57] <ksk> TuxCrazy: a) the entity developing it can supply Debian Packags b) you can build your own c) a debian maintainer can choose to integrate it into debian
1118[10:09:22] <ksk> None of these are "ready to use" solutions for you.
1120[10:09:35] <ksk> If you want to use the software, I suggest going for an *buntu server.
1121[10:09:41] <TuxCrazy> ksk, then, what's the solution, for me?
1122[10:10:03] <TuxCrazy> ksk, you mean I should switch to Ubuntu?
1123[10:10:10] <ksk> that depends on your needs. Use Ubuntu. Dont use the softare. Install from Source.
1124[10:10:36] <TuxCrazy> ksk, ok
1125[10:11:22] <ksk> (( It might be possible to just install the ubuntu .deb on your debian system, but without a solid understanding of Debian GNU/Linux you cannot really tell, so I am totally not encouraging you to do that.. ))
1126[10:11:47] <ksk> (and it can theoreticly end up breaking your system)
1161[10:30:51] <afidegnum> ehlo , anyone familiar with cloudflare? for the past 3 days, i tried in vain to make this SSL thing works, with no success... can you please give a hand ? this is the error i'm getting replaced-url
1167[10:36:08] <ksk> The error indicates that curl and the server do not have a cipher in common. I would suppose you just have to revert whatever you setup in CF to standard, and it will work..
1173[10:42:09] <ratrace> afidegnum: you asked this yesterday, maybe in another channel? you said that wasn't CF but direct connection. did you fix that part?
1174[10:43:25] <afidegnum> it works on direct connection not on SSL
1175[10:43:43] <ratrace> by "direct" I mean bypassing CF servers, and directly to your server's IP
1176[10:44:15] <ratrace> so direct can be SSL or plain http, those are two different things here. You have to give us full details of your problem, otherwise we cannot help.
1177[10:45:05] <afidegnum> ratrace: yes, that's what i did when the SSL seems not to work but when i switched back to SSL, i have a handshake error
1178[10:45:45] <ksk> afidegnum: your sentence does not logically match with what ratrace asked..
1179[10:45:46] <ratrace> so... right now... your pastebin... is that direct connection to your server, or via Cloud Flare? you're not making that clear.
1180[10:46:28] <afidegnum> ratrace: i have this error when switched to CF ssl
1181[10:46:57] <ksk> afidegnum: and what do you get if you directly connect to your server? Does the handshake work then?
1182[10:47:00] <ratrace> afidegnum: okay, so minimize variables, check one thing at a time. can you make a successful SSL connection to your server directly?
1194[10:54:02] <afidegnum> connecting directly resutls in the same issue,
1195[10:55:22] <ratrace> afidegnum: so back to the question I asked you yesterday, can you check nginx error log, it should be logging TLS handshake failures and reasons
1196[10:55:43] <ksk> 08:54 < afidegnum> manifest: i have this in my nginx configuration could it also be a factor?: server_tokens off; ssl_protocols TLSv1 TLSv1.1 TLSv1.2
1197[10:58:12] <ratrace> afidegnum: if you add these options to curl, does it work then? --tlsv1.2 --tls-max 1.2 ?
1202[11:00:49] <ratrace> yeah your server config is definitely busted. please pastebin: 1) /etc/nginx/nginx.conf 2) whatever file defines the isodec.org server{} stanza 3) entries in /var/log/nginx/error.log associated with this failed connection
1206[11:01:49] <ratrace> afidegnum: also, what's on the client side? which distro and version? which curl version? did you alter /etc/ssl/openssl.cnf cipher lists or something?
1207[11:01:52] <afidegnum> the issue is, i migrated from an old server to a new one and followed the same procedure, everything was working before
1208[11:02:21] <ratrace> afidegnum: same question for "old" and "new" server. distro, version, ...
1234[11:13:48] <ratrace> afidegnum: something's not right there. you have two server{} blocks with the same server_name; nginx wouldn't allow that. are you sure nginx is even running?
1237[11:15:05] <ratrace> and are you looking at the correct error log? apparently you have isodec.error.log as well
1238[11:15:24] <ksk> imho having nginx set to "anything but 1.3" and CF set to "only 1.3" looks problematic (granted, I dont know anything about CF)
1239[11:16:12] <ratrace> ksk: it's debian stretch. tlsv1.3 is unavailable. and <TLS1.0 is very much not recommended; I'd say anything <TLSv1.2 isn't either but that's a much less important issue now
1240[11:17:09] <ratrace> as for CF config... I don't know if that applies to backend connections (eg, CF allowing 1.3 only on the front end, but a wider range on back end), but that's also secondary now if direct connection (bypassing CF) doesn't work yet
1242[11:17:26] <afidegnum> ratrace: nginx is running ok so far, i have restarted several times with no errors. apparent errors were corrected
1243[11:18:11] <ksk> ratrace: you are right, that is different. Here is the list of "origin ciphers" (used to connect to your server): replaced-url
1244[11:18:24] <ratrace> afidegnum: you definitelly cannot have two server blocks with the same server_name. check the other error log, it must've complained about that
1247[11:20:07] <ratrace> ksk: right, so one potential problem is limiting ciphersuites to 1.3 but limiting tls to <1.3. according to the pastes, ciphersuites are not explicitly set unless there's another file sourced by nginx where they might be.....
1248[11:20:12] <afidegnum> that's for isodec.error.log: /etc/letsencrypt/live/isodec.org/fullchain.pem
1249[11:20:26] <ratrace> afidegnum: in which case, is there anything in /etc/nginx/conf.d/ that forces ciphersuites list?
1250[11:21:09] <ratrace> afidegnum: what do you meant by "that's for isodec.error.log"?
1251[11:21:30] *** Quits: cryptic (~cryptic@replaced-ip) (Remote host closed the connection)
1252[11:21:31] <afidegnum> you were requesting for nginx error logs for isodec.error.log
1253[11:21:55] <ratrace> yes, so what does that letsencrypt path have to do with that?
1254[11:22:01] <ksk> there is no way an nginx.error log only contains the path you pasted, and nothing else..
1255[11:22:13] <ksk> !pastebinit
1256[11:22:13] <dpkg> A command-line tool to send data to a <pastebin>. To paste e.g. your sources.list do "apt-get install pastebinit; pastebinit /etc/apt/sources.list"; to paste the output of a program do e.g. "dmesg 2>&1 | pastebinit". For a list of pastebin sites do "pastebinit -l". See also <pastebinit config>, <nopaste>.
1257[11:23:45] <afidegnum> i was using letsencrypt initially, and later switched to CF on my old server and everyting worked. i just transposed the same configuration to the new server
1259[11:25:21] <efloid> i have the source for aufs which i need to build to match the bpo 5.8 kernel. however "dpkg-buildpackage -rfakeroot" fails with error "Unmet build dependencies: linux-kbuild-5.2"
1274[11:29:59] <efloid> ksk: the issue is that aufs-dkms won't build with buster-backport linux-image-5.8.0-0
1275[11:30:20] <efloid> ksk: so not able to run docker, etc. using the 5.8 bpo kernel
1276[11:30:41] <ksk> efloid: I see, I am trying to understand the context. Did you take a look at overlayfs already? From what I read its the aufs replacement of sorts
1277[11:31:17] <efloid> ksk: no not yet. if that works that would be great.
1278[11:31:20] <ksk> ps: for docker, you really want to use the upstream packages, not the one coming from debian.
1279[11:31:42] <ratrace> afidegnum: those are 404 not found logged as errors (you can disble 404s going into error log with server wide log_not_found off;)
1282[11:32:27] <ksk> efloid: "lsmod | grep overlay" should tell you if its shipped with your kernel.
1283[11:32:40] <efloid> ksk: yes am using download.docker.com/linux/debian
1284[11:32:41] <ratrace> afidegnum: so at this point something tells me you're not actually hitting that nginx with your curl. can you verify that with access.log? does it list your curl requests? maybe even with tcpdump?
1285[11:33:06] <efloid> ksk: yes it's there!
1286[11:33:09] <ksk> efloid: kk. I did not run it with backported kernel, but on sid docker from upstream is doing fine for me.
1287[11:33:20] <ksk> (not saying you should run sid)
1288[11:34:00] <ratrace> the IP in your first paste indicates it's not CF but Hetzner, with rdns of mail.teleconso.com. is that what it should be?
1291[11:35:17] <ksk> afidegnum: one first thing to check could also be using curl on the server, to connect to the server ( as in "curl --resolve example.com:443:127.0.0.1 replaced-url
1308[11:41:06] <ksk> But in general: Start fresh with your config, only putin some hosts, leave out any ssl_configuration apart from "listen foo ssl" and defining certs, and it should just work..
1309[11:42:22] <ratrace> afidegnum: also that first server{} stanza with IFs is terribly wrong. if certbot is creating those, I have no words...
1310[11:42:55] <ratrace> remove it anyway because it's in conflict with the second server{} stanza. I think nginx actually takes the _first_ one, complaining about duplicates, so definitely remove it for testing
1311[11:43:19] <ksk> correct.
1312[11:43:44] <afidegnum> i've added that config from ajenti interface,
1313[11:43:47] <afidegnum> i just removed it,
1314[11:44:13] <ratrace> afidegnum: for example, this is what nginx says on nginx -t if you have duplicate server_name stanzas (tested for "localhost"): nginx: [warn] conflicting server name "localhost" on 0.0.0.0:80, ignored
1315[11:44:31] <ratrace> so yeah, it's a warning, not error, nginx starts, but ignores the second stanza. I bet that's your problem here.
1321[11:50:59] <afidegnum> ok, the issue, is, when switching CF encryption mode tu Flexible, assets pointing via http are blocked. except https, the handshake error is happening on full mode. I have deleted `server{...}`
1325[11:52:36] <ratrace> afidegnum: I did not. I asked if that IP is the correct one for your testing, and just named the rdns I found on it
1326[11:53:09] <ratrace> afidegnum: also........... FORGET CloudFlare. You first have to test proper connections to your server directly. No CF in between. OK?
1336[11:58:43] <ksk> afidegnum: You wont get anything more than "ciphers do not match". Also, you did not share your config as advised by ngxbot in #nginx, did you?
1339[11:59:13] <afidegnum> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
1340[11:59:13] <afidegnum> nginx: configuration file /etc/nginx/nginx.conf test is successful
1341[11:59:38] <ksk> nice. Now read again what ngxbot wrote.
1342[12:00:45] <ksk> Should you not want to disclose your config publicly, I suggest getting paid support. Without it we cannot really say anything about your problem.
1352[12:07:44] <ratrace> afidegnum: that's one giant fail of nginx config. every server stanza is duplicated. you have to stop doing that, or using whatever piece of ... is doing that.
1353[12:08:28] <ratrace> (duplicated = multiple stanzas with same server_name)
1354[12:08:53] <afidegnum> ok, let me locate and try clearing
1355[12:10:02] *** Quits: dselect (~dselect@replaced-ip) (Quit: ouch... that hurt)
1356[12:10:11] <ratrace> afidegnum: the proper way to do redirects is to have tiny server{} stanza with return 301 URL; or 302, whatev. no if ($host ...), that's wrong. yes I see now the server_names are commented out, but in that first post you did, they were not.... so check that twice, three times over. nginx -t will complain on duplicates.
1367[12:14:40] <ksk> afidegnum: If I asked you, "why did you set sendfile, tcp_nopush" or any other option, do you have a reason? If not, remove them..
1370[12:15:43] <ratrace> afidegnum: but you now have server{} blocks with no server_name ... look. disable it all if you can. have only one, testing server {} with proper server_name, certificate, and run against that only. it's very hard and time consuming to go through 1965 lines of your config, 99% of which is not needed for this case.
1371[12:16:23] <ksk> this. just found the server without server_name. See another faqtoid I spawn for you in #nginx regarding nginx matchingorder..
1405[12:47:10] <codedmart> How do I debug my computer not waking up from sleep? It has happened twice now where at night my laptop suspends, but then in the morning I can never get it to wake up. I have to hold the power button down to turn off then turn back on.
1417[12:50:56] <Haohmaru> i don't know about laptops, but on some machines here, mice/keyboards have no power during suspend, so i have to press the power button to wake it up
1433[13:00:45] <codedmart> Interesting I just read something about d3cold_allowed for the nvme driver. `cat /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed` shows 1.
1434[13:01:00] <Haohmaru> those should react immediately when the machine figures you wanna wake it up, then it may take a long time before it actually comes to life
1484[13:48:43] <Haohmaru> waking up from hibernation would take more time.. that would be powering on from a power off state, booting as usual (BIOS/whatever) then debian should see that this is a wake up from hibernation and it'll load previously saved RAM state from disk into RAM and then your session (hopefully) is resumed
1485[13:49:18] <Haohmaru> roughly.. i don't know.. i only use Suspend, and my computers don't have batteries
1486[13:50:16] *** Quits: skme9 (~skme9@replaced-ip) (Remote host closed the connection)
1489[13:50:42] <Haohmaru> codedmart you could check out if manual "suspend" works on your machine btw.. log into the desktop, open up some silly text editor and write some "kjashdkajsh" text in it, then do a Suspend, observe what happens, then try to wake it up and see if/how that works
1490[13:51:33] <nvz> codedmart: does it wake back up?
1491[13:52:07] <codedmart> nvz I have not been able to wake it up twice now.
1504[13:55:31] <codedmart> Haohmaru I just tried manually and it went to sleep fine and woke up fine by pressing the space bar.
1505[13:55:57] <Haohmaru> so, there ya go.. that's an interesting clue
1506[13:55:59] <nvz> codedmart: any difference? like it only wakes when you manually suspend, but doesnt when it does it itself based on power mangement?
1523[14:01:38] <premoboss> hi debian Linux debian 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux, videocard nvidia geforge RTX 2070 super. driver nvidia 440. Perfect resolution at 1920x1080. After update/upgrade/dist-upgrade/reboot i got driver at 450, resolution fallin down to 1024x768. any suggestion how to solve and have back 1920x1080?
1525[14:02:40] <codedmart> nvz Haohmaru: this is the last set of messages from syslog last night before I had to hard powerdown this morning because I couldn't get it to wake up. replaced-url
1526[14:04:18] <Haohmaru> is that from one of the "working" ones?
1532[14:06:33] <nvz> codedmart: I'd also like to know if you have any knowledge of if this does/does not occur consistently in either the case of manual/auto suspend or on battery/ac
1533[14:06:45] *** Quits: kreyren (~kreyren@replaced-ip) (Remote host closed the connection)
1536[14:07:32] <nvz> codedmart: if you are unsure, then perhaps in addition to the above information a look at your power management data might be useful
1537[14:07:44] <timur_davletshin> shit... FF 78.3 has been rolled out to Debian Stable
1538[14:07:50] *** Quits: skme9_ (~skme9@replaced-ip) (Remote host closed the connection)
1547[14:11:18] <nvz> codedmart: my thoughts here is that your system is not actually sleeping.. the software thinks it is for the most part cause it goes through all the motions, but something is keeping it from actually reaching the sleep state. the info you provided should give more clues as to what sorts of hardware you have and what they are set to do in this state
1548[14:12:21] <nvz> I however am really f'n stressed lately, so it may take me more time to make any sense of this info.. so if anyone else notices something, feel free to chime in :P
1549[14:12:48] <codedmart> nvz No worries at all. I appreciate all your help so far.
1550[14:13:20] <codedmart> I don't expect you to solve it for me. I hope your stress level goes down.
1551[14:14:13] <nvz> yeah me too, if only all problems were as trivial as this one :D
1554[14:15:28] <nvz> codedmart: if you want to help here too.. the commands first two are listing your hardware and ids.. 3rd is listing what the kernel is set to do on the S3/S4 sleep states for various hw, and the 4th is showing what is actually happening.. we're lookin for a smokin gun here as to something that is keepin the system awake
1556[14:17:12] <nvz> codedmart: this may just require some trial and error.. so you may want to explore the unanswered questions and see if you can assure that for the time being that you can either reproduce the issue manually or not
1557[14:17:33] <nvz> codedmart: if you can consistently get it to hang like this manually, then we can just toggle some things until it works
1560[14:18:15] <timur_davletshin> nvz, sure, suddenly everything breaks. No more XUL.
1561[14:19:25] <nvz> timur_davletshin: hmm. you make me fear tryig to reproduce your issue.. but I do have a desktop here I can throw under the bus if you can be more specific about something I could do to see this problem myself
1562[14:19:44] <codedmart> nvz I will see what else I can figure out later possibly. Gotta do some work for now. Thanks again.
1563[14:19:47] * nvz only really uses FF for netflix and this machine is the one on the living room tv.. :P
1564[14:20:09] <codedmart> Haohmaru: Thanks for your help as well.
1565[14:20:24] <nvz> codedmart: well my thoughts are fwiw, toggling things in /proc/acpi/wakeup to see if they solve the issue
1566[14:20:42] <nvz> codedmart: likely disabling things that are set to enabled.. like the USB or such that may be preventing the sleep
1567[14:21:25] <nvz> codedmart: keep track of this paste you made on termbin and preferably use the same nick when you come back for further assistance
1573[14:26:27] * nvz notes pci 0000:00:1c.0: claimed MacBook Pro poweroff workaround [mem 0x7fa00000-0x7fbfffff] and usb: port power management may be unreliable
1598[14:32:12] <nvz> dka-: well if you're using backports your plan for upgrade should include removing such things first
1599[14:32:13] *** gay837 is now known as S3xyL1nux
1600[14:32:28] <dka-> how can I know what waS installed from backport ?
1601[14:32:42] <dka-> I never touch those servers because they are sensitive to my development
1602[14:32:55] <nvz> dka-: you need to plot out a course for upgrade which includes taking stock of all non-official packages and also what you need on these machines to ensure the target suite has what you need
1603[14:33:26] <dka-> can you define "plot out a course" and "taking stock" ?
1605[14:34:04] <dka-> this is what I have when I run apt-get update
1606[14:34:10] <dka-> -update+upgrade
1607[14:34:37] <nvz> dka-: plotting your course is carefully planning the upgrade, as you are several releases behind now and these are machines you rely on and probably remote.. and taking stock means making a note of all packages you got from backports or third parties so you can remove them to make the upgrade go well, and reinstall them after
1613[14:36:12] <nvz> dka-: these sorts of things are described in the release notes.. I'd first further explore your needs to see if this makes sense.. cause first off for wiregaurd your best bet is to get to buster.. and really being current would probably be in your best interest for other reasons
1614[14:36:27] <dka-> after disabling source.list.d/docker.list I am able to apt update, also after disabling backport, I believe now I must remove all things that was installed from over repo
1615[14:36:28] <nvz> dka-: what sorts of things do you have/need on this machine?
1616[14:36:34] <dka-> but I don't feel great cutting the docker process
1620[14:37:34] <nvz> you can't expect backports and 3rd party packages to upgrade smoothly, they are one of the most common problems people incur with dist-upgrades
1621[14:38:00] <dka-> how can I know what was installed on backport ?
1653[14:46:46] <nvz> dka-: you need to upgrade twice.. first to stretch, then to buster.. and given that these are production type machines with backports and possibly 3rd party packages I can't recommend you doing this without understanding what I'm telling you and the release notes section 4.2* describe
1654[14:47:07] <nvz> the upgrade process is suppose to go smoothly, but as that section says only from "pure" systems
1655[14:47:21] <dka-> Ok, I am not installing aptitude on the 3 hosts
1656[14:47:23] <nvz> your system is not "pure" that much is clear
1657[14:47:24] <dka-> one is failing with : E: Package 'aptitude' has no installation candidate
1658[14:47:44] <nvz> dka-: thats likely due to stale cache
1659[14:48:02] <dka-> This may mean that the package is missing, has been obsoleted, or...
1660[14:48:06] <dka-> What's stale cache?
1661[14:48:07] <nvz> dka-: you will want to apt-get update and resolve any repo issues
1662[14:48:16] <ksk> crossposting all day. shalalala.
1663[14:48:27] <nvz> dka-: yes, that the package cache on the system is not current with the mirror its looking to fetch aptitude from
1674[14:49:45] <nvz> dka-: you have only security and volitile
1675[14:49:50] <nvz> you have no main mirror
1676[14:49:52] <ksk> !archive
1677[14:49:52] <dpkg> An archive is a collection of files. 'tar', 'ar', 'cpio' are all archiving tools. This is *not* the same as compression, which is a separate operation. Debian Archives is the repository for old Debian releases, see replaced-url
1678[14:50:00] <ksk> thats because "Jessie" was moved into archive, no?
1679[14:50:05] <ksk> !jessie archive
1680[14:50:07] <ksk> mhhm
1681[14:50:09] <tohoyn> I installed debian stable from the firmware version. When the system boots it opens a command line interface to grub. how do I boot the system?
1682[14:50:16] <nvz> ksk: irrelevant to the fact they have no actual mirror
1683[14:50:31] <nvz> ksk: they only have updates showing there no actual package mirror
1684[14:50:38] <ksk> mhmkay..
1685[14:50:46] <dka-> got it thanks, it's fixed now
1686[14:50:57] <nvz> there are 3 repos required, a main one, and two for different kinds of updates
1687[14:51:08] <ksk> tohoyn: that is grub telling you "I was started by bios, but could not find kernel/devices/etc accoring to my config" -- not really a quick fix for that
1688[14:51:11] <nvz> they are missing the regular mirror
1689[14:51:13] <ksk> !grub-repair
1690[14:51:36] <ksk> !fixmbr
1691[14:51:37] <dpkg> To reinstall <GRUB> boot to your Debian install disk/live CD, switch to the other console (Alt-F2), mount your root filesystem (mount -t ext4 /dev/whatever /target ; mount --bind /dev /target/dev ; mount -t proc none /target/proc ; mount -t sysfs none /target/sys), chroot into it (chroot /target), run "mount /boot/efi" on EFI and "update-grub && grub-install /dev/whatever". See also <rescue mode>, <dual boot guide>, <supergrub>.
1692[14:51:44] <ksk> tohoyn: ^
1693[14:51:56] *** Quits: magic_ninja (~sparkie1@replaced-ip) (Remote host closed the connection)
1701[14:54:06] <dka-> This is the result of the two command to get all the backports package installed, run on the 3 hosts, the last one is having a weird format compare to the 2 first, any clue why? => replaced-url
1702[14:54:33] <dka-> Are you absolutely SURE that I need to remove DOCKER to perform the upgrade :'[ ?
1706[14:55:32] <dka-> yes that's what I am just seeing, it look quite clean
1707[14:55:48] <nvz> dka-: removing docker wouldn't remove your docker containers I wouldnt think
1708[14:55:58] <nvz> dka-: and you'd put it back after you complete your upgrade path
1709[14:56:30] <nvz> thing is anything from backports or such you probably wont need anymore cause the buster version will be newer and you can just install the official package when complete
1710[14:56:31] *** Quits: tohoyn (554c6247@replaced-ip) (Remote host closed the connection)
1711[14:56:32] <dka-> so I am think I am safe to remove nodejs, openjdk-8, ca-certificates-java, but docker-ce, linux-base and linux-image-3.16.0.4 , how can I do that without downtime?
1712[14:56:58] <dka-> removing docker would need to remove docker service and no container will be able to run
1713[14:57:27] <dka-> linux-base (4.5) [Debian: 4.5~deb8u1 3.5] and linux-image-3.16.0-4-amd64 (3.16.43-2+deb8u5), why are these installed and is it safe to remove them now?
1714[14:57:40] <dka-> That look like the core
1715[14:57:43] <ksk> dka-: how about getting a consultant? Kind of crazy you seem to be in charge of a production grade system and dont know ansers to these questions :X
1716[14:58:04] <dka-> Well, I am learning. That's how you learn isn't it?
1717[14:58:05] <ksk> dka-: there is "aptitude why $pkg" which tells you why something was installed
1718[14:58:27] <nvz> dka-: well you dont have /many/ things it seems.. and the ones most likely to cause problems from what you shown are things like nodejs which has MANY dependencies and the java crap.. anything you have thats not official has potential to screw up an upgrade, it doesn't necessarily mean it /will/
1719[14:58:29] <ksk> I suppose it will just not give you anything meaningful on kernel packages.
1720[14:58:41] <ksk> if that are not kernels currently running, you can remove their packages.
1723[14:59:13] <nvz> dka-: as for the kernel as long as you have something like a linux-image-amd64 metapackage it should result in you getting a new kernel on each dist-upgrade without issue
1724[14:59:28] <ksk> The sane thing to do, imho: Rent three other machines, install software. migrate, upgrade. Kill old machines afterwards.
1725[14:59:46] <nvz> dka-: and there is going to be /some/ downtime regardless as services will be restarted during the process, and you're going to need to make two upgrades to get to buster..
1726[14:59:47] <ksk> even more so, should you desire to keep the downtimes minimal. Also: Testing, Desaster-recovery?
1727[15:00:16] <ksk> you should also totally reboot after you did a dist-upgrade (or even updated libs, or the kernel)
1728[15:00:45] <nvz> dka-: with a reasonable connection and reasonably fast machine, the upgrades aren't going to take too long.. the main thing that will drag it out is hitting snags cause you got some kinda crap in there that doesnt upgrade cleanly
1729[15:01:10] <dka-> the host with the linux-image runs on 4.11, but dpkg -l | grep linux-image show only 3.16, so they must be in use right? replaced-url
1730[15:01:41] *** Quits: victorpr (~victorpr@replaced-ip) (Remote host closed the connection)
1732[15:01:42] <ksk> maybe something in between, that your superiors could manage to find money for: Clone one machine of that cluster, and upgrade it standalone. This way you will notice any upcoming problems before actually upgrading the production cluster.
1733[15:01:43] <dka-> I am thinking to upgrade HOST one by one, so the two other master can keep the state, I believe it will work because the system that run mesos are in docker and will work together
1740[15:03:30] <ksk> dka-: what do you do though, if that single machine does not upgrade? How do you test inter-machine communication without also updating the other two? Questions after questions :P
1744[15:04:24] <dka-> what do you do though, if that single machine does not upgrade? => well, if it can run docker after failing the update, then that's ok.
1745[15:04:50] <dka-> How do you test inter-machine communication without also updating the other two? => well, the panteras container that run the platform is a fixed ubuntu version image, so it will still be the same system in docker and they should connect together
1746[15:05:02] <nvz> dka-: buster has openjdk11, not openjdk8, do you know what your needs are for openjdk8 on that one machine?
1747[15:05:12] <dka-> I think I don't need openjdk
1748[15:05:17] <dka-> I don't know why it's there at the first place
1749[15:05:25] <nvz> check aptitude why to be sure
1750[15:05:27] <dka-> I checked and apparently it's visualvm that require it, i dont know why it's there
1753[15:06:30] <nvz> dka-: and while I'm not experienced with docker, I think your assessment of that situation is fairly accurate that its the content that matters
1754[15:06:40] <nvz> your containers are compatible now, and won't change
1822[15:17:09] <dka-> ok but that's super weird, why 1 host does have this linux-base and why the over 2 don't even have a package with linux in it? => replaced-url
1829[15:18:03] <nvz> dka-: that is my question, why apt-forktracer showed this.. it may be due to pinning.. which you'd know if you moved on to the next steps in teh release notes
1830[15:18:24] <nvz> because it doesnt appear to be an unofficial package yet apt-forktracer tagged it for a reason
1833[15:21:04] <dka-> cat: /etc/apt/preferences: No such file or directory and cat: /etc/apt/preferences.d/*: No such file or directory
1834[15:21:21] <nvz> dka-: you can figure out which package provided that kernel by locating a file from the kernel like /boot/vmlinuz-4.19.0-5-amd64 or such and doing dpkg -S on that file
1835[15:21:39] <nvz> it will tell you which package it belongs to
1836[15:22:16] <dka-> i have in /boot bzImage-4.11.0-xxxx-std-ipv6-64 bzImage-3.14.32-xxxx-grs-ipv6-64 , System.map-3.14.32-xxxx-grs-ipv6-64 and System.map-4.11.0-xxxx-std-ipv6-64 + grub folder
1852[15:26:46] <nvz> the one thing I think the rest of you commenting on this need to take stock of, is that apparently these are 3 dedicated servers (baremetal I presume) from the same provider and only one of the 3 has this custom kernel configuration
1853[15:27:25] <nvz> dka-: as for you, I'd think about who else may use/maintain these machines and why they did this on this one machine
1854[15:27:27] <ksk> Sounds like you should ask them that.
1855[15:27:30] <dka-> but the 2 that doesn't use the custom kernel have no kernel
1856[15:27:38] <dka-> I mean no linux-image deb installed
1861[15:28:43] <dka-> All use 4.11.0-xxxx-std-ipv6-64
1862[15:29:03] <sigint> Note that running a kernel built by OVH probably just means that the person who installed theses servers went through the installation wizzard without changing the default value.
1863[15:29:05] *** Quits: dvs (~hibbard@replaced-ip) (Remote host closed the connection)
1864[15:29:05] <ksk> that is a customkernel, and all three of them are using it.
1865[15:29:41] <nvz> dka-: if these are all using custom kernels from the provider, I'd check with them and ask them why and what this may mean for upgrades before proceeding, however that kernel should work for stretch and buster I'd imagine as stretch uses a 4.9.0 and buster a 4.19 iirc
1866[15:29:47] <sigint> If the hardware is old enough, running a stock debian kernel is probably better
1867[15:30:12] <nvz> dka-: I'd ask them about just using a stock debian kernel if that would cause any problems
1868[15:30:28] <dka-> what is a stock debian kernel?
1869[15:30:36] <dka-> It's the ovh a custom kernel?
1870[15:30:44] <nvz> the actual linux-image-* packages from Debian
1871[15:30:56] <nvz> that would be pulled in my linux-image-amd64 metapackage
1872[15:31:19] <nvz> which is what you'd normally want for upgrades so the kernel upgrades with the rest of the system
1873[15:32:02] <nvz> the only real problems I forsee with a custom kernel dpkg isn't aware of is if it caused problems with systemd or something.. but that kernel seems new enough to work with stretch/buster if for some reason its required for their hardware
1874[15:32:12] <nvz> or network configuration
1875[15:36:37] <dka-> Ok, I just opened the ticket at OVH, they have no phone standard for dedicated anymore
1876[15:36:53] <dka-> Meanwhile, can I remove the linux-image-3.16.0-4-amd64 safely?
1877[15:37:05] <dka-> on the host that is having it for I don't know why
1878[15:37:06] <nvz> dka-: doesnt seem like you're actually using it, so yeah..
1888[15:38:13] * dpkg removes linux-image-amd64; dpkg -r linux-image-amd64; dpkg -P linux-image-amd64; dpkg -P linux-image-amd64 along with a pound of flesh from dka-'s body, then staples dka- back up with a staple gun.
1889[15:38:27] <alex11> lol
1890[15:38:36] <nvz> dpkg: shaddup
1891[15:38:36] <dpkg> No, I won't, you shaddup, you
1904[15:42:47] <nvz> I have nfc what their bootloader or such setup is at OVH
1905[15:42:55] <ksk> dka-: Seems then the OVH kernel is "running" but debian does not know if it. Since you remove the only kernel it know, it wants to install another one, so you do not end up without a kernel.
1906[15:43:07] <sigint> Former OVH employee here, as I said it is very unlikely that the custom kernel is actually needed. It is just the default because OVH sometimes sells exotic hardware.
1907[15:43:10] <ksk> really out of scope for #debian though, as we do not know how/why OVH set it up this way
1916[15:43:58] <dka-> sigint, ok, but will that work on the old jessie?
1917[15:44:12] *** rgdgnfnfgh is now known as S3xyL1nux
1918[15:44:14] <nvz> sigint: yes well these are 3 servers this user has in production use for some time it seems, so they dont wanna wind up in a FUBAR/SNAFU situation
1919[15:44:43] <sigint> nvz, understood but upgrading jessie to buster is a wild ride anyway
1920[15:44:57] <nvz> sigint: do you think we should maybe check some sort of kernel messages, lspci or such to see if they have such "exotic hardware" ? :P
1921[15:45:24] <sigint> even without considering kernels, his servers are likely to need to be started in rescue at some point to fix something
1924[15:45:46] <dka-> sigint, I will gladly get more information on that last comment
1925[15:45:59] <sigint> dka-, about rescue?
1926[15:46:04] <nvz> I've done jessie->buster remotely on my fathers machine
1927[15:46:14] <dka-> why upgrading debian will require a rescue step?
1928[15:46:24] <nvz> if you do it as I been cautioning, as is described int he release notes its doable
1929[15:46:41] <nvz> you just gotta be sure not to hit snags with 3rd party crap
1930[15:47:13] <dka-> in the link you shared from debian, they say to make sure we are using the latest upgrade for all deps before performing the upgrade
1931[15:47:55] <dka-> So the main question is, can I run `apt remove linux-image-3.16.0-4-amd64` on the host that has it? I am pretty sure jdk can be removed, so then docker, I can remove it and reinstall it after the upgrade I believe
1932[15:47:58] <nvz> my father had crossover and MS Office on a desktop among other things and I did the jessie->stretch stretch->buster remotely without any major issues
1934[15:48:12] <sigint> dka-, an upgrade from two versions ago can go wrong. More so on 3 different machines running a custom kernel and custom software.
1935[15:48:20] <dka-> So it's pretty safe, I didnd't understood all the mess with the OVH kernel, but you seemed to say that it is compatible with the latest debian already
1936[15:48:35] <sigint> So just be ready to boot your server in rescue IF something goes wrong to fix a thing or two. That's it
1937[15:48:51] <dka-> sigint, well, can jessie, today, install an original kernel ?
1938[15:48:57] <nvz> sigint: you can do the rescue stuff remotely via web on your own?
1941[15:49:27] <dka-> nvz yes I think, and there's a ssh mode
1942[15:49:43] <sigint> nvz, yes you go to the admin panel and reboot your server from the rescue distro
1943[15:49:47] <nvz> dka-: ah, well my main concern would be that you'd have to wait on contacting staff there
1944[15:49:57] <dka-> I don't know if you have looked at replaced-url
1945[15:50:17] <nvz> yeah it looks like a fairly straighforward upgrade path to me
1946[15:50:20] <dka-> Ok we don't know, but I think it is, as nvz said, a common step for all those debian jessie host that needs to upgrade, it should not fail unless ovh hw issue ?
1947[15:50:24] <nvz> you dont have a lot of weirdness there
1948[15:51:09] <nvz> my only conern was noting that the openjdk8 isnt available in buster as we delt with this issue many times in support channels people complaining they coulndt use openjdk11
1949[15:51:18] <sigint> dka-, I'm not saying it will go wrong. But your plan should not be hopping that it goes right, you need to prepare for plan B.
1950[15:51:20] <nvz> but thats only on one of the 3 systems
1951[15:51:34] <dka-> sigint, got it
1952[15:51:49] <dka-> nvz I think I don't need jdk, I don't know why it's there, probably a mistake
1954[15:52:05] <dka-> all the running services are within docker and jre should be installed in those docker systems not the guest system
1955[15:52:08] <dka-> so I am safe to delete it
1956[15:52:27] <dka-> The one that I am not safe about, is the linux-image-3.16.0-4-amd64
1957[15:52:29] <nvz> so if we got the idea of whats unofficial, checked pinning, disabled 3rd parts sources.. sounds like your close to ready for jessie->stretch
1958[15:52:40] <dka-> Can you please confirm that the apt output for removing this is not wrong?
1959[15:52:42] <nvz> dka-: you need to decide if you're gonna go stock or not for that
1960[15:52:54] <dka-> you mean stock kernel?
1961[15:53:00] <nvz> dka-: if you're gonna go stock you just need linux-image-amd64 on all machines
1962[15:53:01] <dka-> Yeah I will wait for OVH answer first.
1963[15:53:12] <nvz> and I'd kinda recommend for smoothest upgrade you do that
1964[15:53:16] <dka-> Yeah, so apt install linux-image-amd64, reboot, check it's stock, then upgrade?
1973[15:55:12] <nvz> dka-: only concern with stale kernels laying around you're not using is if you have limited space on /boot or such
1974[15:55:46] <dka-> I can't confirm that command myself, since it's written: The following extra packages will be installed: linux-image-3.16.0-11-amd64 linux-image-amd64 AND The following NEW packages will be installed: linux-image-3.16.0-11-amd64 so it does not look like a deletion to me
1975[15:55:59] <nvz> dka-: simply removing it, if its not the running kernel is fine, but removing it without also removing the metapackage, resulting in it installing another kernel would result in changes to the bootloader
1977[15:56:19] <dka-> ok, so I should wait for this one also for OVH answer regarding their kernel
1978[15:56:42] <dka-> All make sens, nvz sigint thanks for these precious information
1979[15:56:44] <nvz> dka-: so if you're not willing to just install the metapackage and go stock, I'd wait to do anything with the kernel or just remove the metapackage also for now
1980[15:57:18] <nvz> if you can confirm either from OVH or by testing it, that stock works, I'd just say install the metapackage on all of em and move on with upgrade
1983[15:58:17] <nvz> dka-: one other consideration is we started down all this talking about wiregaurd which has both kernel and userland components.. so it may be the case that the custom kernels on there don't even have wiregaurd or that you don't have headers to build wiregaurd stuff
1984[15:58:25] <nvz> dka-: so you'd need a stock kernel anyhow for that
1985[15:59:06] <sigint> The anwser from the support will most likely tell you that the hardware is known to work with the custom kernel and that you're on your own with distro kernels.
2046[16:10:33] <s_> its an SBC with an 8GB emmc and armhf achitecture
2047[16:10:52] <s_> well not just 1 of them. heh
2048[16:11:01] <nvz> ah.. and you can't upgrade cause you are reliant on some kinda kernel?
2049[16:11:33] <s_> upgrading would require touching it which is expensive at this juncture
2050[16:11:47] <nvz> s_: well there is another option, but still the space contraint is a concern
2051[16:12:31] <nvz> s_: you could probably save additional space by removing all the python3 crap you have now as your stretch system likely isnt reliant on python3 anyhow, most the system stuff is probably reliant on python2
2052[16:13:17] <nvz> s_: then perhaps try something like replaced-url
2053[16:13:29] <nvz> s_: to get you a newer python3
2059[16:14:34] <s_> nvz: hitting some rough patches with pandas and scipy builds.
2060[16:14:50] <nvz> s_: that is probably my best recommendation for your needs and constraints.. remove python3* from apt, use pyenv to get a new python3.. use pip to install what you need for python3
2061[16:15:12] <nvz> removing the python3* stuff will free up more space for you to work
2062[16:15:13] <s_> which are initiated by pip and since there are no wheels, requires toolchain for gcc and fortran, and a bunch of numerical libs, and cython, and still having issues
2097[16:39:33] <teo7> Hi, i just installed the proprietary nvidia drivers for my 950m, but if i go to open nvidia-settings, it won't open. here's what appears in the terminal:
2098[16:39:47] <teo7> $ nvidia-settings
2099[16:39:47] <teo7> ERROR: NVIDIA driver is not loaded
2100[16:39:48] <teo7> ERROR: Unable to load info from any available system
2119[16:50:16] <s_> if I am stretch do I use buster-backports ?
2120[16:50:20] <s_> confused by the naming
2121[16:50:26] <greycat> No. You use stretch-backports.
2122[16:50:53] <fireba11> so it's actually pretty straight forwared -D
2123[16:51:30] <netcrash> Hello, a good way to get recent packages in debian to have the system more updated like ubuntu is to use the testing version? (for desktop)
2124[16:51:53] <greycat> *sigh*
2125[16:51:57] <dotcom> apt update/ upgrade?
2126[16:52:15] <greycat> If you want ubuntu, just run ubuntu. We choose Debian *because* it is stable, meaning unchanging, well-tested, robust, mature.
2127[16:52:26] <netcrash> got it
2128[16:52:39] <alex11> you can often get newer versions of packages via other means
2129[16:52:45] <alex11> without upgrading the whole system
2130[16:52:48] <netcrash> ubuntu comes with a lot of packages that I will have to uninstall like snap
2131[16:52:53] <alex11> meanwhile debian will give you a base yo build on
2132[16:52:58] <alex11> s/yo/to
2133[16:53:08] <netcrash> alex11: ok
2134[16:53:18] <alex11> can you even uninstall snaps in ubuntu? AFAIK that's a huge pain in the ass because it forces it down your throat
2136[16:53:40] <greycat> if there's a specific newer version that you actually need, for an actual *reason* (not just "to have higher numbers"), then you can use a backported package, or upstream
2184[17:12:58] <b1ack0p> after updating to 10.6 i realized grub menu colors changed, is it new for new version?
2185[17:13:01] <b1ack0p> or something corrupted?
2186[17:13:51] <b1ack0p> i updated 32bit to 10.6 to another machine and grub colors didnt changed but on other machine which runs 64bit grub colors changed
2207[17:26:07] <teo7> alex11: thanks, now it works. But the screen sporadically does graphical glitches. These consist of flickering, until I move the mouse abruptly. I tried to migrate from xorg to wayland, but the latter is blocked by default when installing proprietary drivers. So what can I do?
2233[17:56:05] <khelair> is there any possible way that somebody could help me find a debian package of xf86-input-synaptics? I'm having trouble locating one and I can't get the touchpad on this new notebook working under debian without it :(
2234[17:56:12] <khelair> sorry, my google-fu is not the best
2235[17:56:46] <greycat> xf86 would be *really* old... aren't they all named xorg-* now?
2243[17:58:13] <otyugh> I wonder if there is a way to execute a script at shutdown and eventually make shutdown get dalayed on certain condition, display certain stuff... Any idea ?
2247[17:59:01] <greycat> buster is 10, yes. current point release is 10.6.
2248[17:59:02] <otyugh> (what I have in mind is how a looot of people get stuck on their system because of a stupid reboot while apt is doing installing)
2249[17:59:20] <afidegnum> hi, from possible diagnosis, i believe my ssl is broken somewhere but i don't know how, i have inspected my nginx configuration settings and everythings seems ok, can you please give a hand ?
2253[18:00:06] <khelair> um, another quick additional question here.. after installing that package, do I need to modify something in xorg.conf or should it just work?
2293[18:27:47] <dka-> nvz, I asked the mailing ling ovh for dedicated server and one said: "Que ce soit sous Jessie, stretch ou buster les kernels distributeurs debian officiel fonctionnent sans soucis ", which means official debian kernels works without issue
2294[18:28:01] <dka-> I am still waiting for the official OVH answer
2305[18:35:26] <nvz> dka-: I suspect what was said earlier may be the result, that they'll just generically disclaim support for distributions rather than give a definitive answer
2329[19:00:54] <ctcx> If one has web browser with opened login sessions (gmail, yahoo, twitter, forum...), an IRC client, and an opened terminal session as the root user, *all* running at same time, am I becoming at risk of hacks or exploits?
2330[19:02:02] <greycat> you mean, is there a risk that an exploit of your browser session will be able to inject typed characters into the root shell? REALLY unlikely.
2333[19:03:11] <kline\0> ctcx: depends if you're running exploitable software
2334[19:03:21] <Poster> Anytime you run code and/or are connected to any type of network you're running some risk, the scenario you describe, if combined with supported/updated software is pretty unlikely but still possible
2335[19:03:21] <kline\0> see the latest kensington hack for an example of that
2338[19:05:22] <kline\0> the only "real" risk, ctcx, i see in your position you posted is that there is a root shell open. if you have an exploitable bit of software running under your user, thats one thing. if it can somehow deduce that you have a root shell just lying around for abuse, that does possible mean it can jump to a higher set of privs
2339[19:05:30] <kline\0> i dont think thats at all likely though
2340[19:05:52] <kline\0> but generally its not a bad thing to minimise the time that you have escalated privileges in general
2341[19:06:05] * kline\0 salutes general general
2342[19:06:18] <ctcx> So the scenario I described, is it really a bad practice which should be avoided like pest?
2343[19:06:37] <greycat> I'd say it's extremely common.
2344[19:06:44] <kline\0> if you routinely leave an open root terminal around, i would hope to avoid that
2345[19:06:57] <greycat> But kline\0 has a good point -- minimize the time you spend with the root shell open.
2347[19:07:02] <kline\0> try to do what you can with sudo, which escalates privs on a per-process level
2348[19:07:26] <kline\0> in fact, the biggest risk of leaving an open root shell is someone hopping in your seat if you wander off to the toilet, honestly
2349[19:07:34] <ctcx> I do minimize the time I spend as root. Only for few tasks such as updating, etc.
2350[19:07:46] <kline\0> you should mostly be able to do these without a root shell with sudo
2351[19:08:03] <Poster> always utilize least priviledge (a root shell is the opposite of this), keep software updated, exhibit caution with what you interact with
2359[19:10:28] <kline\0> the chances of this being remotely abused are slim, but its simply good practice to try to use sudo instead of a root shell where possible
2360[19:10:49] <kline\0> if nothing else, it will be useful if you absentmindedly use the wrong terminal and make a mistake
2362[19:11:28] <kline\0> if you're in a normal shell, your mistake might kick back because you dont have privs to break something, but if you accidentally plug your mistake into a root shell its much more likely to be able to do harm
2363[19:12:06] <n4dir> you mean besides deleting all your data as user?
2370[19:13:26] <kline\0> deleting all your data as a user, thats bad
2371[19:13:36] <n4dir> greycat: lol. Yes.
2372[19:13:37] <kline\0> deleting everything on the drive is worse
2373[19:14:04] <kline\0> (esp if it starts trying to walk into mounts like backups that are on other users)
2374[19:14:11] <n4dir> why would that be worse? I can easily reinstall in 20 minutes and re-configure in 20. rsync all the backups back takes at minimum 2 hours
2375[19:14:53] <kline\0> n4dir: being able to bring back up a system in 40 mins puts you fairly outside the bracket of users who routinely leave loaded guns/open root shells hanging about
2376[19:15:01] <kline\0> your models are different
2377[19:15:11] <n4dir> and i don't recall in those 15 years i ever forgot i was root at the time and did something harmful related to that
2378[19:15:20] <kline\0> exactly
2379[19:16:12] <ctcx> Then, are there times when I should use sudo, and others when should be su - ? Or better always sudo?
2380[19:16:15] <kline\0> but deleting everything as root is strictly as-bad-as-or-worse than deleting everything just you own
2382[19:17:14] <kline\0> ctcx: where possible, use sudo. understand that there are times where a root shell is appropriate and dont be afraid to use them, just try not to leave them hanging around
2383[19:17:17] <n4dir> hence the strict recommendation for sudo, as far its me, isn't that convincing.
2384[19:17:43] <kline\0> n4dir: thats ok, im not trying to convince you
2385[19:17:46] <n4dir> "imho" would be a different thing.
2386[19:18:43] <n4dir> but this sure isn't written in stone
2389[19:19:16] <ctcx> So even with a root shell, I shouldn't need to forcibly first close gmail, IRC, or others, as long as I don't leave the root shell opened?
2394[19:21:00] <hannes_> i have a Wheezy server in my hands. how feasible is upgrading that to buster? can i go straight from wheezy to buster or would i need to take intermediate steps?
2403[19:22:45] <kline\0> greycat: how common is it that there will be breaking changes that would need to be found and remediated between them? im sure even though my experience in upgrading has been generally good, there are probably a package or two that break because upstream changes over such a long period of time that might be best remediated after spending some time on an intermediate version?
2404[19:22:54] *** Quits: ikus060 (~ikus060@replaced-ip) (Remote host closed the connection)
2408[19:25:37] <greycat> Depends on what you've got installed. At least one of those upgrades, for example, may require serious rewriting of apache config files. One of them may break network interface names/configuration if you don't prep for it.
2421[19:34:27] <greycat> nginx upgrades have been smooth in my experience, but I don't use a lot of its advanced features; about the only thing you might want to do is changing the ssl_ciphers config to disable the obsolete ones
2422[19:34:38] <greycat> and that only matters if you're using TLS
2423[19:34:48] *** Quits: rsx (~rsx@replaced-ip) (Remote host closed the connection)
2424[19:35:11] <sigint> dob1, how long your process was actively running (in the R state)
2428[19:37:28] <hannes_> dob1: try "man htop" in your terminal, then press / to enter search mode, enter "time", hit enter to search. use "n" to go to the next result. it is a bit technical but the explanation might help you understand it better
2429[19:37:53] <hannes_> ciphers should be perfect already, that is one part of the system i did not neglect over the years :)
2430[19:38:53] <greycat> I meant ssl_protocols and ssl_ciphers, but cool. If you've already turned off SSL 1.0 and similar, you're ahead of the game.
2431[19:39:29] <hannes_> yeah i proudly did update that in the past
2433[19:40:17] <ctcx> So while having gmail, IRC and others opened, I could also run Synaptic for update tasks without much danger?
2434[19:40:24] <greycat> Yes.
2435[19:40:40] <ctcx> Thanks
2436[19:40:41] *** Quits: phunyguy (~blaahchm@replaced-ip) (Remote host closed the connection)
2437[19:41:50] <hannes_> you might have firefox refusing to open new tabs if that updated in the background while you were using it but that's not a big issue
2438[19:42:33] <greycat> ctcx was being paranoid about a browser exploit somehow reaching through X11 or Wayland and taking control of other apps
2439[19:43:14] <hannes_> ah ok
2440[19:43:24] *** Quits: zapatista (~zapatista@replaced-ip) (Remote host closed the connection)
2457[20:01:27] <Jonas_> I just ran "apt full-upgrade" on my prod server and at 97% i wants an answer if i want to keep mariadb conffile. I type N and enter and i just get newlines it doesent take my no!
2484[20:08:57] *** Quits: yans (~yans@replaced-ip) (Remote host closed the connection)
2485[20:09:42] <Jonas_> jelly yes new empty lines and all other text scrolls up
2486[20:09:45] <Ede|Popede> had to ping my modem yesterday to see if it was back up again. as usual it didn't return for a while, i did already C-z followed by a kill in the past
2487[20:10:03] *** zalt_ is now known as zalt
2488[20:10:28] <jelly> Jonas_, did you have a mysql database with some data before this?
2489[20:11:00] <Jonas_> jelly yes
2490[20:11:37] <jelly> that /usr/bin/mysql_install_db invocation seems weird but maybe that's normal for a mariadb package upgrade
2498[20:13:55] *** Guest6574 is now known as joaquinito01
2499[20:14:23] <afidegnum> hi, anyone care to assist on the SSL issue ?
2500[20:14:40] <dvs> !ask
2501[20:14:41] <dpkg> If you have a question, just ask! For example: "I have a problem with ___; I'm running Debian version ___. When I try to do ___ I get the following output ___. I expected it to do ___." Don't ask if you can ask, if anyone uses it, or pick one person to ask. We're all volunteers; make it easy for us to help you. If you don't get an answer try a few hours later or on debian-user@lists.debian.org. See <smart questions><errors>.
2512[20:17:26] <afidegnum> when i telnet the domain port, the connection drops
2513[20:17:33] <ratrace> you had a lot of vhosts there and it was hard to read and so many variables in it... so, you need just one simple test case, no php, nothing but a simple html hello world and a ssl setup for it.
2514[20:17:35] <afidegnum> ratrace: i couldn't create
2515[20:17:39] <ratrace> why not
2516[20:17:39] <greycat> you tried to telnet to port 53 ?!?
2519[20:18:00] <greycat> so NOT the domain port. the https port.
2520[20:18:02] <ratrace> you can't telnet port 443, you need 4-way TLS handshake
2521[20:18:09] <Jonas_> jelly if i run fg i get back to the install but i cant continue
2522[20:18:12] <ratrace> you _can_ telnet 3-way tcp handshaked port 80
2523[20:18:46] <afidegnum> ratrace: how do i telnet it ?
2524[20:18:49] <ratrace> afidegnum: and you _can_ use openssl s_client to "telnet" to port 443
2525[20:19:28] <afidegnum> this is what i'm having so far from this log, replaced-url
2526[20:19:30] <greycat> Jonas_: I would imagine that you make a rough guess of how long you should wait before you give up on it. When you feel it's time, go ahead and kill whatever mariadb process is the bottom-most leaf of the process tree.
2544[20:23:37] <ratrace> afidegnum: most importantly, your nginx.conf must no source anything else from conf.d or sites-enabled , or anywhere else. just ONE server{} in one http{}
2545[20:24:19] <afidegnum> oh, that's what i was doing
2568[20:40:15] <jelly> one would think moving to systemd with its cgroups isolation would make killing leftover process dead simple and easy and service definitions more robust
2586[20:50:51] <hannes_> dowwie: prices are probably still insane but i always had great experiences with logitechs, i.e. Logitech C920 and its successors. widely used in linux-powered projects everywhere
2587[20:51:17] <dowwie> I'm looking at a C920 from target for 70
2588[20:51:42] <dowwie> hannes_: this is helpful info, though -- thanks for confirming
2603[20:59:12] <jelly> ratrace, eh, replacing a buggy init script that I need to fix with a buggy unit that I need to fix doesn't seems like much of an improvement
2604[20:59:21] *** Quits: dvs (~hibbard@replaced-ip) (Remote host closed the connection)
2606[20:59:56] <ratrace> jelly: where's the bug tho. majority of issues I had was from bad distro defaults. all the units I wrote myself to full systemd functioanlity advantage, works as expected.
2607[21:00:18] <jelly> you had to write them yourself.
2608[21:00:20] <ratrace> (sure there were trials and errors and learning, but eventually...)
2609[21:00:29] <ratrace> jelly: because the maintainer broke it
2610[21:00:52] <ratrace> I'm all for pointing fingers, but lets be real here. systemd doesn't deserve the flak caused by maintaner decisions
2611[21:00:55] <jelly> you could have written init scripts yourself as well
2612[21:01:18] <ratrace> yes, I could. 10x more time spent and debugging around featureless monkeypatched shell scripts
2613[21:01:37] <jelly> after 20 scripts you spend a bit less
2614[21:01:40] <ratrace> you mentioned cgroups. I can already imagine the fun wrangling cgroups manually from shellscripts
2615[21:01:59] <jelly> I wrote socket polling dependency resolving init scripts.
2616[21:02:35] <ratrace> I'd ditch the complexity of systemd back to shell scripts if I could technically achieve the same functionality that I need, and I can't
2623[21:03:24] <jelly> rather than "I sent a signal so that something may be starting"
2624[21:03:42] <jelly> I can do it with both.
2625[21:04:16] <jelly> I don't WANT to have to do it with either.
2626[21:04:19] <ratrace> in my case, the functionality I can't do without systemd is named apparmor profiles and all the hardening options we have in units
2627[21:04:27] <ratrace> something like openrc for example can't do that.
2628[21:04:53] <ratrace> last time I checked, s6 couldn't either, but things may've changed since I last checked
2633[21:05:33] *** Quits: Vizva (~Vizva@replaced-ip) (Remote host closed the connection)
2634[21:05:41] <ratrace> a fully functional alternative to systemd would be awesome, yes. I dislike the complexity of systemd and developer attitude etc... but girl, that thing does the work!
2641[21:08:24] <ratrace> afidegnum: yeah something in that convoluted spaghetti mess of certbot if($host) abomination and you mentioned a control panel adding its own..... something in there breaks everything.
2662[21:20:36] <whatsthecraic> I'm trying to connect to a VPS, the ssh connection times out. If it's not the firewall, what else can it be?
2663[21:20:36] <afidegnum> i mean wipe hte server
2664[21:20:52] *** Quits: Waggie (~Waggie@replaced-ip) (Quit: The bits and the bytes, they are taking over!)
2665[21:21:07] <sponix> whatsthecraic: could be you don't even have sshd installed
2666[21:21:25] <sponix> OR, it is running on a non default port
2667[21:21:31] <ratrace> afidegnum: that's terrible. please be careful.
2668[21:21:33] <whatsthecraic> then the connection should be simply rejected
2669[21:21:36] <greycat> if sshd isn't installed, you would not get a timeout. you would get an immediate connection refused.
2670[21:21:55] <sponix> greycat: good point
2671[21:22:22] <greycat> if you can ping the box, but you get a timeout on ssh to port 22, then there *is* a firewall somewhere, but not necessarily on the Debian host
2673[21:22:50] <sponix> whatsthecraic: ufw iptables and nft are the 3 ways I know firewall rules can be done that I am aware of on Debian 10
2674[21:22:51] <ratrace> whatsthecraic: if there's firewall on the server, it's implemented either with nft or iptables frontend. iptables -L -n and nft list tables (and further listing tables for rules...) would show you that. you can't check like that if there's a firewall in front of the server though.
2681[21:29:47] <jhutchins> whatsthecraic: The ssh client has a -v option that can tell you more about what's happening. It can be repeated up to 3 times for more detail (-vvv).
2682[21:30:20] <jhutchins> whatsthecraic: You can also use the nmap tool to determine what ports you can reach on the target.
2683[21:30:22] <greycat> you shouldn't need that to diagnose a timeout, though. just "telnet my.ip.add.ress 22" and watch.
2706[21:38:33] *** Quits: yans (~yans@replaced-ip) (Quit: chaos is the only true answer)
2707[21:39:01] *** debhelper sets mode: +l 1160
2708[21:39:37] <Onyx47> dconf editor? I think? Someone correct me if I'm wrong, been ages since I dealt with Gnome and derivatives in any extended capacity
2757[22:17:58] <hannes_> hm, i skipped the mysql -> mariadb upgrade it seems =(
2758[22:19:24] *** Quits: mezzo (~mezzo@replaced-ip) (Quit: leaving)
2759[22:19:35] <avri> I've setup a debian server on linode.com and registered a domain name with namecheap.com. I added the hostname to /etc/hosts and restarted the server. I added an A record for a custom server name in linode's DNS management panel. Running 'hostname -f' keeps showing linode's FQDN as li****.members.linode.com. I checked the DNS propagation and
2760[22:19:35] <avri> everything seems to be fine. What else do I need to do in debian to get the server to learn it has a new hostname? Should I modify resolv.conf? (it currently has search and domain set to members.linode.com, but I read it gets it from DHCP)
2766[22:20:25] <greycat> debian gets the hostname from /etc/hostname
2767[22:20:42] <avri> so why does it not update for me?
2768[22:20:44] <jelly> !hostname
2769[22:20:44] <dpkg> Use «hostname foo» to set the hostname, $EDITOR /etc/hostname to set it for the next boot (create /etc/hostname if it does not exist) and $EDITOR /etc/hosts to set up local translations for a FQDN. See also 'man 1 hostname', or ask me about <mailname>. replaced-url
2770[22:21:04] <greycat> normally you'd reboot if you altered /etc/hostname, because there are a LOT of daemons out there that may have cached the old value
2771[22:21:31] <greycat> I don't know why people run "hostname -f" at all, ever, for any reason.
2772[22:21:32] <avri> I rebooted many times and it didn't have any effect
2773[22:21:42] <greycat> you run "hostname" and it says...?
2774[22:21:52] <jelly> if there's systemd, hostnamectl might be used and perhaps it saves the value somewhere else?
2775[22:22:03] <avri> li1**-**
2776[22:22:05] <jelly> (but I know it also reads it from the usual debian's place)
2777[22:22:13] <greycat> avri: and is that different from the content of /etc/hostname?
2791[22:25:28] <avri> they all seem to point to the fact that I need to have an A record in the DNS for the record I put in /etc/hosts
2792[22:25:39] <greycat> A records in DNS have NOTHING to do with the system's local hostname.
2793[22:26:02] <greycat> A system can have a dozen different DNS names in several different domains, and they might all be different from what's in "hostname".
2794[22:26:11] <jhutchins> avri: You might ask linode support about it. After all, you're paying them.
2795[22:26:18] <avri> also read this: replaced-url
2796[22:26:39] <avri> jhutchins: I guess you're right :/
2797[22:26:43] *** Quits: gelignite (~gelignite@replaced-ip) (Quit: Stay safe! Stay at home! Stop the chain reaction!)
2798[22:26:44] <jhutchins> avri: How/where are you seeing the old hostname?
2806[22:28:10] <ratrace> because in the past, if you knew linode internal number, you could haxx it. they had some big vulns there
2807[22:28:21] <greycat> :facepalm:
2808[22:28:24] <ratrace> I'm sure they fixed but..... once burned....
2809[22:28:49] <ratrace> I left them not because they were haxxed, but because they kept denying it despite overwhelming evidence presented by members.
2815[22:33:19] <greycat> If linode has some secret crap installed that sets the local hostname to a password that, if revealed, allows the system to be compromised, and cannot be overridden, then my strategy would be: ignore it completely. Just go on with your life having an ugly local hostname.
2820[22:35:13] <avri> so running 'hostname server1' actually set my hostname - where did it make the change and why simply setting it in /etc/hosts didn't do the trick?
2821[22:35:38] <greycat> The local hostname exists in memory. That's all. It is supposed to come from /etc/hostname at boot but apparently your system is not regular Debian.
2822[22:35:52] <avri> hmm
2823[22:35:57] <greycat> It has NO EFFECT on ANYTHING. It's just shown in shell prompts so you know which box you're on.
2825[22:36:26] <greycat> Some things might write it to log files, or something.
2826[22:36:40] <avri> well... as long as it showed me the old values I figured something must be broken and needs fixing
2827[22:37:11] <avri> I expected the value to change once I modified /etc/hosts and rebooted
2828[22:37:23] <greycat> It's not read from /etc/hosts.
2829[22:37:53] <chriswitt> hello i have trouble using looks with uuid like i already did on another machine. blkid doesn list the device. cryptsetup luksUUID /dev/sdb gives me the uuid. but when i try to use it with cryptsetup luksOpen UUID=6... name i get the error that the uuid is not present in /dev/disk/by-uuid/
2843[22:42:17] <greycat> IN DEBIAN, it is set by reading the file named /etc/hostnam at boot time. We have established that your system is not Debian though. At least not in this respect.
2859[22:47:39] <greycat> There's an interesting tidbit in hostnamectl(1): "If a static hostname is set, and is valid (something other than localhost), then the transient hostname is not used."
2860[22:47:39] <ratrace> hostnamectl binary, is using dbus to change and query hostname and other host name-ish bits
2861[22:47:46] *** Quits: barteks2x (~barteks2x@replaced-ip) (Remote host closed the connection)
2863[22:48:14] <greycat> apparently "localhost" is a special value here, and earlier, you (avri) stated that you had edited /etc/hostname yourself, but...
2870[22:49:39] <greycat> so, hostnamectl is redundant on Debian, unless the special value "localhost" is in the file?
2871[22:49:40] <Franciman> ok I have a strange issue with network connection. I configured my wlan interface through /etc/network/interfaces and wpa_supplicant
2911[22:55:52] <ratrace> jhutchins: I wouldn't be here now if that was the case. my rtl8169 has no firmware installed, kernel's complaining and yet I'm here :)
2912[22:55:53] <jhutchins> Franciman: What do the logs say?
2913[22:55:58] <Franciman> logs of ?
2914[22:56:06] <Franciman> dmesg doesn't say anything
2915[22:56:16] <ratrace> and I've seen that behavior with a few other nics too, at least one wifi
2929[23:00:29] <Franciman> if I don't start Xorg and use gui software it seems to not disconnect
2930[23:00:46] <ratrace> Franciman: check the journal. wpa_supplicant _should_ complain about dropped connections. I can't remember if it's all kern facility or userland too
2933[23:01:25] <Franciman> no, it only said: Starting WPA supplicant. Started WPA supplicant.
2934[23:01:30] <Franciman> I checked it
2935[23:02:42] <ratrace> Franciman: you haven't explained how you see it's not connected. you said the nic was up, dhclient running, wpa_supplicant not showing errors, so what's the actual symptom?
2936[23:02:46] <Franciman> ah sorry
2937[23:02:48] <Franciman> well
2938[23:02:52] <Franciman> hexchat disconnects
2939[23:03:02] <Franciman> and if I do ping -c 3 gnu.org
2940[23:03:10] <Franciman> it says: name temporarily not resolvable
2941[23:03:11] <Franciman> AND
2942[23:03:13] <ratrace> could there be a problem elsewhere in the network? access point? some other router?
2943[23:03:16] <Franciman> if I do ping -c 3 8.8.8.8
2948[23:03:31] <dpkg> The enter key is not a substitute for punctuation. Hitting enter unnecessarily makes it difficult to follow what you are saying. Consider using ',', '. ', ';', '...', '---', or ':' instead. If you hit enter too often, you will be autokicked by debhelper for flooding the channel.
2982[23:12:19] <ratrace> Franciman: "I should try to ping my gateway to rule it out" :: if you can ping your gateway but not outside, that's strong indication of the gateway issue. sure, you can "somehow" lose the default route, so your kernel knows how to ping the gateway but doesn't know where to route everything else
2983[23:12:34] <ratrace> but again, you need the full range of tests
3008[23:17:33] <ratrace> link local would be set if an attempt to obtain a routable IP fails, in some cases, but I'm not sure which ones (esp since there's apparently routable 192.168.1.179)
3009[23:17:34] <jhutchins> Franciman: Ah, different. I've had some problems loosing ipv4 lately. Have to reset modem/router/PCs.
3012[23:18:35] <ratrace> Franciman: so if those two lines are all you get from `ip r`, it's possible you can route the gateway but not outside, and something's wrong on your machine as there's no default route, AND there's a link local IP set
3013[23:18:36] <Franciman> well, I'm PRETTY sure it's something in my debian config that is wrong
3014[23:18:44] <ratrace> you can *ping the gateway
3015[23:19:04] <Franciman> maybe I should use network manager, since I'm a noob
3016[23:19:06] <greycat> how does that system even communicate with the outside world without a default route?
3017[23:19:10] <dotcom> Franciman: what do you see when you type ' ip r | head -n 2 '