Comment 13 for bug 1867366

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 ?