rbasak | $ sudo canonical-livepatch status | 12:03 |
---|---|---|
rbasak | uptime: 598h20m30s | 12:03 |
rbasak | ^ that's wrong - `uptime` reports 24 days, 22:21 | 12:03 |
rbasak | And also | 12:03 |
rbasak | patchState: apply-failed | 12:03 |
rbasak | Anything I should look at before I lose state by rebooting? | 12:03 |
rbasak | http://paste.ubuntu.com/p/gNKr4YPdhB/ | 12:04 |
=== himcesjf_ is now known as him-cesjf | ||
TJ- | rbasak: uptime seems correct; 24 days x 24 = 576 + 22 hours | 13:37 |
rbasak | TJ-: oh. Thanks. I saw 598 and didn't pay attention to the units. | 13:37 |
TJ- | :) | 13:37 |
TJ- | yeah, at first glance I thought "wow" ! | 13:38 |
rbasak | I found some logs (on "apply-failed"): https://paste.ubuntu.com/p/F4mYrd45Tc/ | 13:39 |
rbasak | It's been doing that a while. https://paste.ubuntu.com/p/td7qYQ9SjZ/ is when it seems to have started. | 13:41 |
rbasak | https://askubuntu.com/q/1152398/7808 is the only Google hit with the same problem - no answer currently. | 13:42 |
rbasak | Seems too much of a coincidence that both of us had it happen on exactly the same day. | 13:44 |
TJ- | we've been seeing a lot of reports of livepatch failures in #ubuntu for the last 2 weeks. Originally we thought it was a server connection issue but canonical-sysadmin couldn't see any problems. We asked some users to report bugs but I think they were lazy :) | 13:47 |
* rbasak is writing up a bug | 13:48 | |
rbasak | https://bugs.launchpad.net/canonical-livepatch-client/+bug/1833566 | 13:52 |
ubot5 | Launchpad bug 1833566 in Canonical Live Patch Client "Client stops applying patches with "cannot execute finitModule syscall: required key not available"" [Undecided,Confirmed] | 13:52 |
apw | ben_r: ^ | 15:10 |
* ben_r will take a look at it | 15:32 | |
ben_r | rbasak, I am confused, your text says 4.4.0.151.159, did you mean 151.178? Also, that is not the kernel that was running, you were on 4.4.0-148.174 at the time right? | 15:37 |
rbasak | ben_r: otp sorry, back in a bit | 15:38 |
ben_r | np | 15:38 |
rbasak | ben_r: ah, I see the confusion | 15:46 |
ben_r | rbasak, np I think I've figured it out. Is this system running with secure boot enabled? | 15:47 |
rbasak | ben_r: I think so. I have grub-efi-amd64-signed installed. Is there a way to verify? | 15:53 |
ben_r | rbasak, mokutil --sb-state | 15:55 |
ben_r | if that is enabled, did you enroll the livepatch key? | 15:55 |
rbasak | SecureBoot enabled | 15:55 |
rbasak | ben_r: I believe livepatch has been working correctly for a long time prior to that error | 15:56 |
rbasak | ben_r: eg: https://paste.ubuntu.com/p/xBQBZD7tpd/ | 15:56 |
rbasak | ben_r: so I think it was all enrolled correctly, yes. | 15:56 |
rbasak | ben_r: I recall seeing patches applied in previous calls to "status" (in previous boots) | 15:56 |
rbasak | your text says 4.4.0.151.159> because that's the kernel package currently installed, not the one running | 15:57 |
ben_r | rbasak, OK, that doesn't do anything to livepatch though. :) you can list the enrolled keys with "mokutil --list-enrolled". If there's a key enrolled you'll see one with the Subject field " Issuer: CN=Canonical Ltd. Live Patch Signing" | 15:59 |
rbasak | MokListRT is empty | 15:59 |
ben_r | rbasak, any chance the system's BIOS was updated recently? that can trash keys sometimes | 16:00 |
rbasak | I have only rebooted once in months, and I believe livepatch was working before the reboot. | 16:01 |
rbasak | The reboot itself seemed to be completely normal - I didn't enter the BIOS or anything. | 16:01 |
rbasak | The reason I rebooted was some kind of kernel bug though. | 16:01 |
rbasak | https://irclogs.ubuntu.com/2019/05/24/%23ubuntu-server.html#t18:29 was what happened that caused me to reboot | 16:03 |
rbasak | I suppose it's possible that fwupd might have done something though perhaps, and the reboot caused a new BIOS fw version to run? | 16:04 |
rbasak | I don't remember having done that though. | 16:04 |
rbasak | And on this machine I always update/upgrade manually | 16:04 |
rbasak | "Earlier I sent SIGSTOP to firefox and snap related process, so I can't run livepatch right now." | 16:06 |
rbasak | I did that before rebooting. | 16:06 |
rbasak | Could that have broken livepatch - by it not being able to "shut down" properly? | 16:06 |
rbasak | Also "canonical-livepatch status" hangs, but I don't know if I caused that by interfering with it earlier. <-- also before my reboot | 16:07 |
ben_r | rbasak, it's likely that it would have stopped it from doing anything else, but that wouldn't break livepatch. The next time the system boots it would have started normally. | 16:08 |
ben_r | I think the lack of keys is the problem here, on secure boot the kernel won't let you load anything that isn't signed with a key it recognises. I don't know where your keys went, but there should be at least the one used to boot the system listed | 16:10 |
=== Serge is now known as hallyn |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!