OpenShift Container Platform 4.13 introduces a RHEL 9.2 based RHCOS. With this update, symbolic disk naming can change across reboots. This can cause issues if you apply configuration files after installation or when provisioning a node that references a disk which uses symbolic naming, such as /dev/sda, for creating services. The effects of this issue depend on the component you are configuring. It is recommended to use a specific naming scheme for devices, including for any specific disk references, such as dev/disk/by-id.

We have customers who are using naming like /dev/vdc via MachineConfig but how can we fix/migrate this to /dev/by-id or /dev/by-path in a supported method?

Specifically in our doc of 4.12 we state the example with /dev/vdc:
https://docs.openshift.com/container-platform/4.12/installing/installing_bare_metal/installing-bare-metal.html#installation-user-infra-machines-advanced_disk_installing-bare-metal

In our doc of 4.13 we changed this to /dev/disk/by-id/<device_name>:
https://docs.openshift.com/container-platform/4.13/installing/installing_bare_metal/installing-bare-metal.html#installation-user-infra-machines-advanced_disk_installing-bare-metal

    4.12 upgrade to 4.13 or 4.14

    100%

MachineConfig:
±±±   
apiVersion: machineconfiguration.openshift.io/v1


kind: MachineConfig


metadata:


  labels:


machineconfiguration.openshift.io/role: worker
  name: 99-worker-var-log-partition


spec:


  config:


ignition:

  version: "3.2.0"

storage:

  disks:

    -

      device: /dev/vdc

      partitions:

        -

          label: log

         # sizeMiB: 10000

         # startMiB: 0

  filesystems:

    -

      device: /dev/disk/by-partlabel/log

      format: xfs

      path: /var/log

systemd:

  units:

    -

      contents: |

          [Unit]

          Before=local-fs.target

          [Mount]

          Where=/var/log

          What=/dev/disk/by-partlabel/log

          [Install]

          WantedBy=local-fs.target

      enabled: true

      name: var-log.mount     
±±±

    possibility of inconsistent naming for the devices

    Provide a way how to migrate with clear steps on existing cluster without having to rebuild