Let's say someone created a hostnqn by hand and kept the same hard-coded uuid. This upgrade would brake this scenario.
+ if [ "$2" = "1.9-1" ]; then + # the hostid was hardcoded into the binary package, so if the + # local file matches the 1.9-1 version hardcoded value, + # remove the file so it is properly generated below + if [ -s /etc/nvme/hostid ] && [ "$(cat /etc/nvme/hostid)" = "9ce77162-5a3e-439b-a73f-cdf2449521b6" ]; then + echo "REMOVING non-unique /etc/nvme/hostid value" + rm -f /etc/nvme/hostid + fi + + # bug in 1.9-1 build caused hostnqn to contain only a newline, + # which fails the "! -s" check below, so just remove the almost-empty + # file, so it is properly generated below + if [ -s /etc/nvme/hostnqn ] && [ -z "$(cat /etc/nvme/hostnqn)" ]; then + rm -f /etc/nvme/hostnqn + fi + fi Perhaps we could change it with what I said in last comment: If no hostnqn is given, then there is no way a fabric was configured, and you're safe to delete both files. If there is a hostnqn file, you issue a warning saying for the user the UUID should be changed (if default) and the fabric should be reviewed. How does that sound ? What about Bionic ? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1867366 Title: hostnqn fails to automatically generate after installing nvme-cli To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1867366/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
