MT#63024 Support mdadm array creation with mdadm versions >=4.4

mdadm upstream commit
e97c4e18c8
changed its behavior, now (pretty much) always promting the user for the
expected bitmap configuration. :(

Now with mdadm v4.4-11 as present in current Debian/trixie,
automatically creating a mdadm array fails for us:

  | (netscript.grml:704): set_up_partition_table_swraid():  echo y
  | (netscript.grml:704): set_up_partition_table_swraid():  mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: /dev/sda3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
  | mdadm: Note: this array has metadata at the start and
  |     may not be suitable as a boot device.  If you plan to
  |     store '/boot' on this device please ensure that
  |     your boot-loader understands md/v1.x metadata, or use
  |     --metadata=0.90
  | mdadm: /dev/sdb3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
  | mdadm: size set to 468218880K

Behavior with mdadm versions older than 4.4 (e.g. with mdadm 4.2-5 as
present with our previous deployment system):

  | (netscript.grml:703): set_up_partition_table_swraid():  echo y
  | (netscript.grml:703): set_up_partition_table_swraid():  mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | mdadm: /dev/sda3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
  | mdadm: Note: this array has metadata at the start and
  |     may not be suitable as a boot device.  If you plan to
  |     store '/boot' on this device please ensure that
  |     your boot-loader understands md/v1.x metadata, or use
  |     --metadata=0.90
  | mdadm: /dev/sdb3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
  | mdadm: size set to 468218880K
  | mdadm: automatically enabling write-intent bitmap on large array
  | Continue creating array? mdadm: Defaulting to version 1.2 metadata
  | mdadm: array /dev/md0 started.

Now with this mdadm behavior change, we seem to have the following
options to handle this:

1) Explicitly enable the `--bitmap=internal` command line option:

  | root@grml ~ # echo y | mdadm --create --verbose --bitmap=internal /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | mdadm: /dev/sda3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 09:26:41 2025
  | mdadm: Note: this array has metadata at the start and
  |     may not be suitable as a boot device.  If you plan to
  |     store '/boot' on this device please ensure that
  |     your boot-loader understands md/v1.x metadata, or use
  |     --metadata=0.90
  | mdadm: /dev/sdb3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 09:26:41 2025
  | mdadm: size set to 468218880K
  | Continue creating array [y/N]? mdadm: Defaulting to version 1.2 metadata
  | mdadm: array /dev/md0 started.

  This option enables an explicit choice, causing the bitmap to be
  stored with the metadata on the array (and so is replicated on all
  devices). While this might be the preferred option for now, mdadm
  internals might change over time, so I would prefer not to(tm) rely
  on this option.

2) Piping `yes` into mdadm

  | root@grml ~ # yes | mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: /dev/sda3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 09:25:35 2025
  | mdadm: Note: this array has metadata at the start and
  |     may not be suitable as a boot device.  If you plan to
  |     store '/boot' on this device please ensure that
  |     your boot-loader understands md/v1.x metadata, or use
  |     --metadata=0.90
  | mdadm: /dev/sdb3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 09:25:35 2025
  | mdadm: size set to 468218880K
  | Continue creating array [y/N]? mdadm: Defaulting to version 1.2 metadata
  | mdadm: array /dev/md0 started.

  This would be my preferred choice, but it still causes an error within
  mdadm, returning with exit 141 while not reporting an actual error:

  | root@grml ~ # set -o pipefail
  | root@grml ~ # yes | mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: /dev/sda3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 10:02:32 2025
  | mdadm: Note: this array has metadata at the start and
  |     may not be suitable as a boot device.  If you plan to
  |     store '/boot' on this device please ensure that
  |     your boot-loader understands md/v1.x metadata, or use
  |     --metadata=0.90
  | mdadm: /dev/sdb3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 10:02:32 2025
  | mdadm: size set to 468218880K
  | Continue creating array [y/N]? mdadm: Defaulting to version 1.2 metadata
  | mdadm: array /dev/md0 started.
  | 141 root@grml ~ #

  We could disable the pipefail option around the mdadm execution in our
  script, though this might have unindented side-effects for us with
  further failures. So I would prefer not to(tm) rely on this option,
  neither.

3) Enable mdadm's `--run` command line option:

  | root@grml ~ # echo y | mdadm --create --run --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | mdadm: /dev/sda3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 09:23:48 2025
  | mdadm: Note: this array has metadata at the start and
  |     may not be suitable as a boot device.  If you plan to
  |     store '/boot' on this device please ensure that
  |     your boot-loader understands md/v1.x metadata, or use
  |     --metadata=0.90
  | mdadm: /dev/sdb3 appears to be part of a raid array:
  |        level=raid1 devices=2 ctime=Thu Jun 19 09:23:48 2025
  | mdadm: size set to 468218880K
  | mdadm: creation continuing despite oddities due to --run
  | mdadm: Defaulting to version 1.2 metadata
  | mdadm: array /dev/md0 started.

  The `--run` option is documented as follows in mdadm(8):

  | Insist that mdadm run the array, even if some of the
  | components appear to be active in another array or filesystem.  Normally
  | mdadm will ask for confirmation before including such components in an
  | array.  This option causes that question to be suppressed.

  and under "CREATE MODE" it also says:

  | --run  insist on running the array even if some devices look like they
  | might be in use.

  It seems to be the only way to disable user prompting, so it seems to
  be our preferred choice.

BTW: not even the `--force` option prevents this question:

  | # mdadm  --create --force --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
  | To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? ^C

OH: "--run is the new --force"

Change-Id: I26bcef8f8e5da057ba3029e0bdbbb7cf527f0374

templates/scripts/includes/deployment.sh

@@ -701,7 +701,7 @@ set_up_partition_table_swraid() {
   get_pvdevice_by_label_with_retries "/dev/${SWRAID_DISK1}" "${partlabel}" "${max_tries}" raidev1
   get_pvdevice_by_label_with_retries "/dev/${SWRAID_DISK2}" "${partlabel}" "${max_tries}" raidev2
 
-  echo y | mdadm --create --verbose "${SWRAID_DEVICE}" --level=1 --raid-devices=2 "${raidev1}" "${raidev2}"
+  mdadm --create --run --verbose "${SWRAID_DEVICE}" --level=1 --raid-devices=2 "${raidev1}" "${raidev2}"
 
   echo "Creating PV + VG on ${SWRAID_DEVICE}"
   pvcreate -ff -y "${SWRAID_DEVICE}"