Support OPAL 2 self-encrypting NVMe disk drives (fix #2475)

[OliverO2]

This patch enables support for OPAL 2 self-encrypting NVMe disk drives.

I will amend this PR and/or propose merging it as soon as testing results come in (cf. progress in #2475).

[jsmeix]

"$device"n[0-9] matches only up to namespace number 9 i.e. /dev/nvme...n9
so e.g. /dev/nvme0n10 and higher namespace numbers are ignored.

To be more on the safe side I suggest

# consider all namespace block devices up to /dev/nvme...n99 (NOTE: relies on nullglob)
echo "$device"n[1-9] "$device"n[1-9][0-9]

I think more than 9 namespaces might happen in practice
while more than 99 namespaces never happen in real world.

But the latter is probably only wishful thinking because
https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf
reads (excerpts)

... namespace ID (NSID) ...

6.1.2 Valid and Invalid NSIDs
...
Any NSID is valid, except if that NSID is 0h or greater than the
Number of Namespaces field reported in the Identify Controller
data structure (refer to Figure 247).
NSID FFFFFFFFh is a broadcast value that is used to specify
all namespaces. 

so it seems any number up to FFFFFFFFh could appear in real world.

[jsmeix]

The next question is how namespaces > 9 block device nodes are shown:
As decimal numbers like /dev/nvme0n12
or as hex numbers like /dev/nvme0nc or /dev/nvme0nC or /dev/nvme0n0c

[OliverO2]

So far, I have not seen namespace IDs beyond 1 being used in the wild. But I don't mind if we extend the scheme.

The kernel will use decimal digits:

	sprintf(disk_name, "nvme%dn%d", ctrl->instance, ns->head->instance);

[jsmeix]

@OliverO2
thank you for your improvement in
48669d2

It is such a pleasure for my eyes!
Perfect code that is 100% to the point with a complete explanatory comment
and that with even the same number of characters as my clumsy attempt before.

Have a nice and relaxed weekend!

[OliverO2]

@jsmeix
My pleasure, I just happend to cross-check and found out that extglob is actually enabled throughout ReaR. :-)

Have a nice weekend, too!

[jsmeix]

Yes, there are some well hidded 'secrets' (like the global extglob) in ReaR.

Right now I adapted the "Beware of the emptiness" section in
https://github.com/rear/rear/wiki/Coding-Style
so that it now at least mentiones that also extglob is globally set as follows:

There is a global 'shopt -s nullglob extglob' setting in usr/sbin/rear
where the 'nullglob' setting means that ...

[enzolis]

@OliverO2
Thanks for providing these patches.
Previously, the disks were unlocked but "unlocked_device_count" did not increase due to failing partprobe. Thus the password prompt was showing up again.
Your patches fix the issue for me (NVMe disks using UEFI boot).

I would like to make you aware that at least in my PBA environment the shell options nullglob and extglob are NOT set (contrary to the situation in the booted OS). Thus the shell was complaining about incorrect syntax.
Adding "shopt -s nullglob extglob" to the top of "unlock-opal-disks", re-creation and upload of PBA fixed this issue, but I am not sure if it is the correct place to put it.

[OliverO2]

@enzolis
Thank you so much for your feedback. Good to hear that it works in general. I'll take care of safely integrating shopt -s nullglob extglob. It is my plan to come up with a ready-to-merge solution within 7 days.

[OliverO2]

With the successful test report by @enzolis and the fix for missing 'nullglob extglob' options I'd consider this patch ready to merge.

[jsmeix]

@rear/contributors
please have a look.
Perhaps you see some obvious issues.
If there are no objections I would like to merge it on Thursday (05.Oct.2020) afternoon.