=== zenlinux9 is now known as zenlinux === JanC_ is now known as JanC [07:13] Good morning [11:28] First kernel panic of my young life, should I have to make a wish ? \o/ [12:35] remhaze: should be a tradition already; please do! [12:35] Actually I cry, but maybe later [12:50] So I expose my problem here if someone have an idea. [12:52] (ubuntu-server 20.04) I got kernel panic on my VPS, I reboot into rescue mode, I can't found any log about kernel panic in /var/log/. I tryed to do some command, but a lot end by this error : /lib/libcrypt.so.1: version `XCRYPT_2.0' not found === afoo is now known as avu [13:17] remhaze: What about "journalctl -t kernel" [13:22] Only UFW logs.. [13:48] many machines log that unattended-upgrades ran and had nothing to do, when there is something to do...but it didn't do `apt-get update` so it didn't know. What's with that ...shouldn't it obviously do that? is that a bug, or intentional (:D)? Can I configure it to always run before? [13:50] wat ? [13:51] 2021-03-26 06:06:43,872 INFO No packages found that can be upgraded unattended and no pending auto-removals [13:52] and then lookat `apt-cache policy openssl` and it shows no new package...then apt-get update and it's there and then unattended-upgrade will actually install it [13:52] Not sure, I dont use unattended-upgrades [13:52] I have it enabled for security-only ...and it failed at that in 18.04; I haven't seen this problem in 16.04 or before [13:53] 16.04 had lots of ways for it to disable itself or miss the kernel (the meta package sometimes goes missing) which I solved, but it wouldn't log that it ran and do nothing [13:53] is the openssl fix out already ? [13:53] yes it was out yesterday [13:54] I manually put it on all public facing machines since unattended-upgrades only runs once a day...and today I figured unattended-upgrades would do them, but only did a few because it didn't apt-get update [13:56] s/them/the rest/ [14:06] peetaur: what does "apt-config dump|grep Update-Package-Lists" say? [14:06] Should be: APT::Periodic::Update-Package-Lists "1"; [14:06] Then "apt-get update" runs when apt-daily.timer fires I think (see "systemctl status apt-daily.timer") [14:07] rbasak: APT::Periodic::Update-Package-Lists "1"; [14:08] https://bpa.st/6MYQ [14:09] in this case, you can see the apt-cache policy shows the new package, but it's not installed... the apt-get update ran at some point automatically, but not before the unattended-upgrades ran [14:09] there are also many cases where `apt-cache policy ...` doesn't show t he .9 package [14:11] Hypothesis: your mirror didn't see the update when apt-daily.timer last ran, but something else has run "apt-get update" since. [14:11] Maybe look at timestamps in /var/lib/apt/lists vs. systemctl status output for apt-daily.timer? [14:12] There's also /var/log/unattended-upgrades/ [14:12] You can run "sudo unattended-upgrades" by hand if you want [14:12] Including with "--dry-run". [14:13] Ah [14:13] There's also apt-daily-upgrade.timer [14:13] Maybe those ran out of order? [14:13] yes unattended-upgrades by hand works well if I first did apt-get update [14:14] I suspect you're noticing an ordering thing, and that's something that hasn't been thought about too hard because the goal of unattended-upgrades is to get it done "soon" without a particular deadline. [14:16] (it's also insufficient without something like checkrestart if you're thinking about the OpenSSL CVE) [14:19] does this actually say the last run time? https://bpa.st/ZOCA [14:20] Sorry, I'm not following a link to a pastebin site I don't recognise [14:21] You might find the "pastebinit" command helpful [14:21] here's again with the upgrade timer too https://bpa.st/DUSA [14:22] that's bpaste.net ...it's the simplest best I know [14:22] and for whatever reason they went with the fad of butchering the url so it has a shorter less sane domain name [14:23] what pastebin do you want? I don't want to use a cli one for this [14:24] paste.ubuntu.com please [14:27] https://paste.ubuntu.com/p/xWzwY3xFCf/ [14:29] Maybe journalctl -u apt-daily.timer (and apt-daily-upgrade.timer) [14:33] https://paste.ubuntu.com/p/yx4djYkmDT/ [14:33] december? [14:34] does this actually log runs of the timer, or just when the timer is running(waiting) [14:34] I think you're right. It's not runs of the timer. [14:34] I'm not sure how to get that [15:13] so since the problem is related to systemd, for which there are no solutions (anything you configure is still not trustable), the solution is to reimplement it ...and done === j is now known as jess === Napsterbater is now known as Guest61945 === Napsterbater_ is now known as Napsterbater === Napsterbater is now known as Guest1613 === Napsterbater_ is now known as Napsterbater === Napsterbater_ is now known as Napsterbater === remhaze_ is now known as moimoimoi === rfm_ is now known as rfm