Sie sind hier : Homepage →  > hier stehen die veralteten Seiten→  Linux (6) Ein Webtropia root-Server→  Die UUIDs retten bei "grub2"

Zum Verständnis - die 13.2 Grund-Installation (Raid1)

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.
.

Ein Blick in die originale "grub.cfg"

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'

.

Die "Benennung" aller "md" RAID Partitionen mit den UUIDs

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"
.

In der "/etc/fstab" stehen ursprünglich Device-Bezeichnungen :

Sie sehen hier also noch keine UUIDs !!!

/dev/md0 swap swap defaults 0 0
/dev/md2 / ext4 defaults 1 1
/dev/md1 /boot ext4 defaults 1 2

.

In der "/boot/grub2/device.map" steht ursprünglich :

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

das sind unsere beiden physikalischen 1 TB SATA Platten.
.

Mit dem Befehl "ls -l /dev/disk/by-uuid" sehen Sie . . . .

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 9 Dec 13 2018 652a2a86-65cb-425c-9760-bba641245f0d -> ../../md2
root 9 Dec 13 2018 77506b7e-c0d2-4712-8461-e94f0ffe1c78 -> ../../md1
root 9 Dec 13 2018 f735ff65-bc3c-4685-b987-204b3a5a97aa -> ../../md0

.

Mit dem Befehl "cat /proc/mdstat" ein Blick auf die Blockgrößen

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.)
.

Mit "lsblk" sehen Sie den Zusammenhang zwischen den

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

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk  
sda1 8:1 0 8G 0 part  
md0 9:0 0 16G 0 raid0 [SWAP]
sda2 8:2 0 1G 0 part  
md1 9:1 0 2G 0 raid0 /boot
sda3 8:3 0 922.5G 0 part  
md2 9:2 0 1.8T 0 raid0 /
             
sdb 8:16 0 931.5G 0 disk  
sdb1 8:17 0 8G 0 part  
md0 9:0 0 16G 0 raid0 [SWAP]
sdb2 8:18 0 1G 0 part  
md1 9:1 0 2G 0 raid0 /boot
sdb3 8:19 0 922.5G 0 part  
md2 9:2 0 1.8T 0 raid0 /

.

Zum Verständnis ganz wichtig, nirgendwo (in den conf-Dateien) stehen die aktuellen Gigabyte Zahlen

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.
.

Und diese Zusammenhänge müss(t)en erhalten bleiben

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.
.

Das bedeutet für den Hypervisor - möglichst keine UUIDs

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
.

Wenn es nun aber doch nicht geht, hier noch ein Trick zur Restauration der alten UUIDs auf die neuen Platten

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
.

Das wäre die alte Installation (unbedingt aufheben)

device fs_type label mount point UUID
/dev/sda1 linux_raid_member any:0 (inuse) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sda2 linux_raid_member any:1 (inuse) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sda3 linux_raid_member any:2 (inuse) 73805d88-8640-0902-0651-2b82829bff5a
         
/dev/sdb1 linux_raid_member any:0 (inuse) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sdb2 linux_raid_member any:1 (inuse) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sdb3 linux_raid_member any:2 (inuse) 73805d88-8640-0902-0651-2b82829bff5a
         
/dev/md0 swap   <swap> f735ff65-bc3c-4685-b987-204b3a5a97aa
/dev/md1 ext4   /boot 77506b7e-c0d2-4712-8461-e94f0ffe1c78
/dev/md2 ext4   / 652a2a86-65cb-425c-9760-bba641245f0d

.

Und ganz wichtig: der Befehl, UUIDs zu überschreiben !!!!!

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/
.

Kontrolle der Metadaten einer RAID1 Partition

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>
.

Nach der Änderung in "/etc/default/grub"

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 ......
.

Startseite -- © 2001/2022 - Copyright by Dipl.-Ing. Gert Redlich / Germany - D-65191 Wiesbaden - Telefon-Nummer - Impressum