Latest upstream release: 1.9 Current version/release in rawhide: 1.8.1-2.fc31 URL: https://github.com/linux-nvme/nvme-cli Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/9074/
An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry!
Hi Andy, Would you please pull v1.9 into Fedora? Thanks.
Hi Andy, Would you please pull in v1.9? It needs to be Fedora before we can use it in RHEL releases. Thanks for you help, David
I pushed out a spec update in the master branch and kicked off a scratch build. One thing I'm a bit uneasy about: the new dracut rule references the new udev rule, but how exactly are the systemd units that are referenced by the udev rule expected to exist in the dracut environment?
(In reply to Andy Lutomirski from comment #4) > I pushed out a spec update in the master branch and kicked off a scratch > build. One thing I'm a bit uneasy about: the new dracut rule references the > new udev rule, but how exactly are the systemd units that are referenced by > the udev rule expected to exist in the dracut environment? Hi James, will a change to dracut be needed? Thanks.
I'd also like to confirm that everything still works with /etc/nvme/hostid and /etc/nvme/hostnqn removed. I *could* autogenerate them on install, but I'd much rather see nvme-cli just work correctly without those files. See: https://github.com/linux-nvme/nvme-cli/pull/415 Ideally, the code that reads /etc/nvme/hostid and /etc/nvme/hostnqn would notice that the files don't exist (or perhaps notice that they exist and contain a string like 'auto') and generate the contents on the fly.
Here's what I have right now. I doubt it works, but it's probably not a regression from 1.8. I could attempt to patch it up, but I'd rather see an upstream fix that makes everything work without hostid and hostnqn files. This would be much nicer for Silverblue or whatever it's called these days. https://src.fedoraproject.org/rpms/nvme-cli/c/b308a8c2587de5bf4eebd960072045fdd012a9cb?branch=master
Hi Andy, (In reply to Andy Lutomirski from comment #6) > I'd also like to confirm that everything still works with /etc/nvme/hostid > and /etc/nvme/hostnqn removed. I *could* autogenerate them on install, but > I'd much rather see nvme-cli just work correctly without those files. See: > > https://github.com/linux-nvme/nvme-cli/pull/415 > > Ideally, the code that reads /etc/nvme/hostid and /etc/nvme/hostnqn would > notice that the files don't exist (or perhaps notice that they exist and > contain a string like 'auto') and generate the contents on the fly. The hostid and hostnqn are used for NVMe over Fabrics, the original request to populate /etc/nvme on installation was so they didn't change across reboots. To auto-generate would require more nvme-cli changes, they would need to be persistent. Thanks.
(In reply to David Milburn from comment #8) > The hostid and hostnqn are used for NVMe over Fabrics, the original request > to populate /etc/nvme on installation was so they didn't change across > reboots. > To auto-generate would require more nvme-cli changes, they would need to be > persistent. Thanks. Like this? https://github.com/linux-nvme/nvme-cli/pull/588
Hi Andy, (In reply to Andy Lutomirski from comment #9) > (In reply to David Milburn from comment #8) > > The hostid and hostnqn are used for NVMe over Fabrics, the original request > > to populate /etc/nvme on installation was so they didn't change across > > reboots. > > To auto-generate would require more nvme-cli changes, they would need to be > > persistent. Thanks. > > > Like this? > > https://github.com/linux-nvme/nvme-cli/pull/588 Looks like Keith pulled the patch in, I setup a couple of Fedora systems, pulled the latest from https://github.com/linux-nvme/nvme-cli On target system [root@rdma-dev-00 nvme-cli (master)]$ uname -a Linux rdma-dev-00.lab.bos.redhat.com 5.3.2-300.fc31.x86_64 #1 SMP Tue Oct 1 20:44:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@rdma-dev-00 nvme-cli (master)]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 464.8G 0 part └─fedora_rdma--dev--00-home 253:2 0 761.5G 0 lvm /home nvme0n1 259:0 0 372.6G 0 disk └─nvme0n1p1 259:1 0 372.6G 0 part ├─fedora_rdma--dev--00-root 253:0 0 70G 0 lvm / ├─fedora_rdma--dev--00-swap 253:1 0 5.9G 0 lvm [SWAP] └─fedora_rdma--dev--00-home 253:2 0 761.5G 0 lvm /home [root@rdma-dev-00 nvme-cli (master)]$ ./nvme show-hostnqn nqn.2014-08.org.nvmexpress:uuid:3b1e25ab846d402d943f29ec6c2c318a On initiator system [root@rdma-dev-01 nvme-cli (master)]$ uname -a Linux rdma-dev-01.lab.bos.redhat.com 5.3.2-300.fc31.x86_64 #1 SMP Tue Oct 1 20:44:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@rdma-dev-01 nvme-cli (master)]$ ./nvme discover -t rdma -a 172.31.0.230 -q nqn.2014-08.org.nvmexpress:uuid:3b1e25ab846d402d943f29ec6c2c318a Discovery Log Number of Records 1, Generation counter 2 =====Discovery Log Entry 0====== trtype: rdma adrfam: ipv4 subtype: nvme subsystem treq: not specified, sq flow control disable supported portid: 1 trsvcid: 4420 subnqn: testnqn traddr: 172.31.0.230 rdma_prtype: not specified rdma_qptype: connected rdma_cms: rdma-cm rdma_pkey: 0x0000 [root@rdma-dev-01 nvme-cli (master)]$ dmesg [ 704.437714] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 172.31.0.230:4420 [ 704.448925] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" On target system: $ dmesg 160960.190926] nvmet: creating controller 2 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:3b1e25ab846d402d943f29ec6c2c318a.
Hi Andy, (In reply to Andy Lutomirski from comment #4) > I pushed out a spec update in the master branch and kicked off a scratch > build. Is your scratch build available for testing? Will you be updating the Fedora version soon? Thanks.
There are still some issues: https://github.com/linux-nvme/nvme-cli/pull/594 I'd rather do this right rather than sending some not-entirely-done stuff to Fedora.
Hi Andy, (In reply to Andy Lutomirski from comment #12) > There are still some issues: > > https://github.com/linux-nvme/nvme-cli/pull/594 > > I'd rather do this right rather than sending some not-entirely-done stuff to > Fedora. Any progress towards getting v1.9 pulled into Fedora? Thanks.
Hello Andy, Any progress towards getting v1.9 pulled into Fedora? Thanks.
I'm submitting builds of my somewhat nerfed v1.9. Any chance you could look at the github issue above or my posting to linux-nvme and comment on it? I'd really like to get this fixed for real upstream and be done with it.
Sigh, temporarily blocked due to a mysterious koji problem.
Latest upstream release: 1.10.1 Current version/release in rawhide: 1.9-1.fc32 URL: https://github.com/linux-nvme/nvme-cli Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/9074/
Created attachment 1650627 [details] [patch] Update to 1.10.1 (#1742764)
the-new-hotness/release-monitoring.org's scratch build of nvme-cli-1.10.1-1.fc29.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=40274956
Hi Andy, can you pull in Keith's latest v1.10.1? This would keep up-to-date with the latest fixes. Thanks.
I submitted updates. (The updates aren't linked to the bug because Bodhi appears to be failing to locate the bug. Maybe it's just me, but the Fedora tooling seems to be getting less and less functional, and I'm getting a bit sick of packaging Fedora given the state of the tooling. It should not take minutes to find my builds and apparently forever to find bugs when I go to bodhi.fedoraproject.org.)
Closing manually because the magic Fedora infrastructure didn't associate this bug with the actual update.