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 '