Control: tags -1 patch On Thu, 14 Nov 2024 16:04:27 +0000 Luca Boccassi <bl...@debian.org> wrote: > Source: libnvme > Version: 1.11-1 > Severity: grave > Justification: breaks autopkgtest of another package > Forwarded: https://github.com/linux-nvme/nvme-cli/issues/2573 > > Dear Maintainer(s), > > libnvme since version 2.11 does not work if it is built with keyutils > support, but runs on a kernel without CONFIG_NVME_TCP_TLS and > CONFIG_NVME_HOST_AUTH, as it unconditionally expects the .nvme keyring > to be available, and hard fails otherwise. > > https://github.com/linux-nvme/libnvme/blob/f1ddb968ce03a67a96e3f9069e9b758532cf67b9/src/nvme/linux.c#L1551 > > # nvme connect-all -t tcp -a 127.0.0.1 -s 16858 --hostid=158f4d7d- 6759-499e-b260-b152e49fa9a2 > Failed to set keyring > failed to add controller, error Required key not available > > On Debian the kernel does not enable the required kconfigs, so the > command is currently broken as the .nvme keyring doesn't exist. > > This is now breaking src:systemd autopkgtest, which has a test for an > nvme tcp server that uses nvme-cli, hence the severity: > > https://ci.debian.net/packages/s/systemd/testing/amd64/ > > Unfortunately there was no direct dependency in autopkgtest so the test > that was previously working wasn't rerun before nvme-cli migrated to > testing, I've fixed that now so that future regressions will be caught > by debci before migration. > > I've also reported this upstream: > > https://github.com/linux-nvme/nvme-cli/issues/2573 > > Ideally the userspace tool should not fail hard when the kernel doesn't > enable the required functionality, especially when the invocation > doesn't explicitly enable any tls option, but that will require > upstream to fix it.
Upstream has provided a fix: https://github.com/linux-nvme/libnvme/pull/914 And also released v1.11.1 that includes it. Could you please upload it at your earliest convenience? I'm happy to NMU it as well if you are short on time and would prefer some help. Thanks!
