Jan. 2017 - Mit dem bisherigen (Teil-) Wissen über UUIDs und Device- Bezeichnungen habe ich erst mal die original webtropia Grund-Installation angesehen und hier dokumentiert. Je länger ich bezüglich UUIDs suche, desto mehr Tools und Hilfsmittel und Konzepte zur Reparatur und zur Sicherung solcher Partitonen finde ich. Nicht alle Tools sind offiziell für opensuse verfügbar, man muß es überhaupt erst mal wissen und dann akribisch (weiter-) suchen - wie zum Beispiel der "grub-customizer". Was YAST bei grub2 nicht kann, kann der sehr gut.
.

In der Datei "/boot/grub2/grub.cfg" finden Sie unter anderem Folgendes:
..............
  insmod part_msdos msdos
  insmod diskfilter mdraid1x
  insmod ext2
  set root='mduuid/73805d888640090206512b82829bff5a'
  if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint= 'mduuid/73805d888640090206512b82829bff5a'  652a2a86-65cb-425c-9760-bba641245f0d
  else
..............
und nochmal hier:
..............
set root='mduuid/cc32f60dda3320f216990c050b6fa77d'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint= 'mduuid/cc32f60dda3320f216990c050b6fa77d'  77506b7e-c0d2-4712-8461-e94f0ffe1c78
else
  search --no-floppy --fs-uuid --set=root 77506b7e-c0d2-4712-8461-e94f0ffe1c78
fi
..............
und grub2 startet dann mit diesem vorgefertigten "Boot-"Image
'Loading Linux 3.16.6-2-default ...' von dieser boot-Platte hier (.....b6fa77d)

### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-652a2a86-65cb-425c-9760-bba641245f0d' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos msdos
        insmod diskfilter mdraid1x
        insmod ext2
        set root='mduuid/cc32f60dda3320f216990c050b6fa77d'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='mduuid/cc32f60dda3320f216990c050b6fa77d'  77506b7e-c0d2-4712-8461-e94f0ffe1c78
        else
          search --no-floppy --fs-uuid --set=root 77506b7e-c0d2-4712-8461-e94f0ffe1c78
        fi
        echo    'Loading Linux 3.16.6-2-default ...'
        linux   /vmlinuz-3.16.6-2-default root=UUID=652a2a86-65cb-425c-9760-bba641245f0d   resume=/dev/md0 splash=silent quiet showopts
        echo    'Loading initial ramdisk ...'
        initrd  /initrd-3.16.6-2-default
}
Es werden also 2 Partitionen (beide mit ext4) im Bootloader erkannt, die (mit dem search-Befehl) auf boot-code abgefragt werden:

1. set root='mduuid/73805d888640090206512b82829bff5a' und
2. set root='mduuid/cc32f60dda3320f216990c050b6fa77d'

.

Hier sehen Sie (nur) die beiden (den grub2 Loader und die uns) interessierenden "ext4" Partitionen - es sind bereits RAID1 gebündelte "md" Partitionen (die beiden physikalischen 1TB Platten sda und sdb kommen hier gar nicht vor):

[xen9.ipw.net - root] /boot/grub2 $ blkid (ist eine verkürzte Darstellung !!)

/dev/md2: UUID="652a2a86-65cb-425c-9760-bba641245f0d" TYPE="ext4"
/dev/block/9:2: UUID="652a2a86-65cb-425c-9760-bba641245f0d" TYPE="ext4"
/dev/block/8:3: UUID="73805d88-8640-0902-0651-2b82829bff5a" LABEL="any:2" TYPE="linux_raid_member"
/dev/block/8:19: UUID="73805d88-8640-0902-0651-2b82829bff5a" LABEL="any:2" TYPE="linux_raid_member"

/dev/md1: UUID="77506b7e-c0d2-4712-8461-e94f0ffe1c78" TYPE="ext4"
/dev/block/9:1: UUID="77506b7e-c0d2-4712-8461-e94f0ffe1c78" TYPE="ext4"
/dev/block/8:2: UUID="cc32f60d-da33-20f2-1699-0c050b6fa77d" LABEL="any:1" TYPE="linux_raid_member"
/dev/block/8:18: UUID="cc32f60d-da33-20f2-1699-0c050b6fa77d" LABEL="any:1" TYPE="linux_raid_member"

(der Swap Bereich md0 ist fürs Booten unwichtig)

/dev/md0: UUID="f735ff65-bc3c-4685-b987-204b3a5a97aa" TYPE="swap"
/dev/block/9:0: UUID="f735ff65-bc3c-4685-b987-204b3a5a97aa" TYPE="swap"
/dev/block/8:1: UUID="0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c"
/dev/block/8:17: UUID="0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c"
.

Sie sehen hier also noch keine UUIDs !!!

.

(hd1)   /dev/sdb
(hd0)   /dev/sda

das sind unsere beiden physikalischen 1 TB SATA Platten.
.

den Zusammenhang zwischen der logischen "Device-" Bezeichnung unserer drei primären RAID1 Partitionen und der zugehörigen UUID (nach UUID sortiert) :

[xen9 - root] ~ $ ls -l /dev/disk/by-uuid

.

root@grml ~ # cat /proc/mdstat

Personalities : [raid0]
md0 : active raid0 sdb1[1] sda1[0]
      16785384 blocks super 1.0 4k chunks

md1 : active raid0 sdb2[1] sda2[0]
      2105320 blocks super 1.0 4k chunks

md2 : active raid0 sdb3[1] sda3[0]
      1934630888 blocks super 1.0 4k chunks

unused devices: <none>
(Eigentlich müsste hier auch "raid1" stehen.)
.

drei physikalischen Partitionen auf den beiden SATA Platten und den drei "darüber liegenden" logischen RAID1 Partitionen (md0, md1 und md2) :

.

Die aktuelle Größe einer physikalischen oder logischen Partition wird zur Boot-Zeit aus den aktuellen Partitionstabellen extrahiert und in den temporären /dev/ Einträgen eingetragen. In keiner residenten Betriebssystem-Datei auf der Festplatte ist die Partitonsgröße zu finden. Und damit wäre solch ein System ohne UUIDs recht einfach (von alter zu neuer Platte) transportabel. - So weit die Theorie.
.

Wenn wir also solch eine "Installation" von einem (Quell-)Sever (1) nach (Ziel-)Server (2) übertragen wollen, dann muß (müsste) das unabhängig von den UUIDs der Festplatten bzw. der RAID-Systeme funktionieren.
.

und darum sollen/müssen folgende Änderungen gemacht werden :
Änderungen in "/etc/default/grub"

GRUB_DISABLE_LINUX_UUID=true
GRUB_ENABLE_LINUX_LABEL=true

und so gehts:

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

# neu dazu gekommen ist :
GRUB_ENABLE_LINUX_LABEL=true

# Uncomment to disable generation of recovery mode menu entries - ja abschalten
GRUB_DISABLE_LINUX_RECOVERY=true
.

Wir lernen dazu, nicht alles funktioniert wie versprochen !!! - Auf jeden Fall müssen erstmal - so oder so - die alten uns bekannten UUIDs (auf dem Quell-Server) gesichert werden, wie auch immer - und zwar Nachhause gesichert auf die lokale Administrator-Maschine oder auf das lokale NAS im Büro. Und so bekommt man die komplette UUID Liste :

blkid -o list
.

.

Da wir hier zwei "ext4" Partitionen (je Festplatte) haben, wäre das der Befehl zum Überschreiben einer UUID mit dem alten abgespeicherten UUID-Inhalt/Wert - natürlich offline im Rescue-Modus :

tune2fs -U NEUER_UUID /dev/sda"x"

Wobei sda0 bis sda2 bei uns die physikalischen Platten-Partitionen sind, mit denen wir aber gar nicht (direkt) arbeiten. Ob das also auch für die Raid1 Partition md1 und md2 gilt, sagt der Autor nicht. Ich werde es aber auf meinem Spielserver ausprobieren.

Laut FAQs kann man auch das mdadm Werkzeug (multiple disk administration) benutzen ?? Muß aber auch noch ausprobiert werden.

mdadm /dev/md0 --add /dev/disk/by-partuuid/NEUER_UUID

WIe gesagt, das muß ausprobiert werden -  Hier eine Hilfe zum Abfragen der UUIDs:
.
https://wiki.ubuntuusers.de/blkid/
.

gefunden : ein Beispiel

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdX1 /dev/sdY1

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
.
dann formatieren : mkfs.ext4 -v /dev/md0
.
und abfragen :
mdadm --misc --detail /dev/md0

hier steht noch mehr :
The first command wipes the super blocks and the second command creates a new array but assumes the devices are clean. I have just performed this and everything appears to be ok. I would definitely recommend a backup before doing this. I had no data to loose and therefore no integrity to check. I just wanted to avoid another 4 hours resync.

mdadm --zero-superblock /dev/sd[a-z]1

mdadm --create /dev/md0 --assume-clean --level=10 --raid-devices=10 /dev/sd[a-z]1 --metadata=0.90
.
Creating an array with assume-clean and inconsistent metadata as suggested above certainly has potential to damage existing data, as 0.90 and 1.2 metadata blocks not only differ in size but also location.

it may work for 0.90 <-> 1.0, which is an exception.
.
Check both hard drives have the same layout:

fdisk -l /dev/sdd /dev/sde

was das laufende online RAID1 anzeigen sollte

cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd1[1]
976759672 blocks super 1.2 [2/1] [_U]
unused devices: <none>
.

muß ein neuer Bootloader ohne diese UUIDs aber mit logischen Partitions-Bezeichnungen geschrieben werden.

Macht er aber noch nicht ???? Warum ?? - Wir brauchen noch einen Ausweg ......
.