Sie sind hier : Homepage →  Linux (6) Ein Webtropia root-Server→  Der Webtropia Rescue-Modus→  Auf 13.2 (webtropia) aufbauen.→  RAID Partition verkleinern II

Aktuell funktionieren mehrere Konzepte nicht.

Unser webtropia Rescue-System ist ein Debian 9.0. Dort bekomme ich die aktuelle gparted Version 0.27.0 aber nicht zum Laufen, weil dieses debian 9.0 angeblich "zu alt" sei. Das ist natürlich Unsinn, im Januar 2017 war "stretch" noch in der Testphase. Wie gesagt, die gparted Version 0.19.0 hat noch nicht diese verbesserten Eigenschaften bezüglich RAID1 und mdadm und 0.27.0 läuft nicht.
.

Also muß Konzept 3 angegangen werden.

Die gparted live Version 0.27.0 als 250MB ISO image in die KVM laden und ausprobieren und die kommt von :
http://downloads.sourceforge.net/gparted/gparted-live-0.27.0-1-amd64.iso

Diese gparted Live Version 0.27.0 benutzen wir nur, um die RAID1 Partition zu verkleinern. Angeblich soll es jetzt mit der 0.27 funktionieren.

Zuerst installieren wir innerhalb des Rescue-Systems wieder die KVM, die "virtuelle Maschine" und ein temporäres 6GB Filesystem im RAM, dann holen wir die gparted live in diese KVM.

wget -O /tmp/image.iso downloads.sourceforge.net/gparted/gparted-live-0.27.0-1-amd64.iso

dann die KVM starten - wie das genau geht, steht bereits hier.

kvm -enable-kvm -hda /dev/sda -hdb /dev/sdb -m 1024 -vnc :0 -cdrom /tmp/image.iso -boot d

Auch hier wieder, die aktuelle gparted 0.27.0 kann die große 922GB RAID1 Partiton, die dort immer noch als 1.8 TB Partiton (also mit der doppelten Größe) angezeigt wird, nicht verkleinern.

Damit ist auch diese gparted Variante im Januar 2017 ausgereizt.
.

Jetzt kommt das theoretische Konzept 4 dran . . . . .

die händische Variante, nämlich md2 komplett löschen und dann kleiner neu anlegen.

Mit den zur Zeit verfügbaren grafischen Tools klappt das nicht, YAST2 geht nicht, weil die (eigene) root Partition natürlich "in use" ist. Gparted 0.19.0 aus der debian Distribution kann es auch nicht. Gparted Live 0.29.0 kann es auch (noch) nicht und die aktuelle Webmin- Programm Sammlung bekomme ich auf diesem debian 9.0 auch nicht zum Laufen.

So bleibt nur der mdadm im Kommandozeilen-Modus übrig und damit die russische (Lösch-) Methode.
.

Die große vorhandene 3. Partition komplett löschen

(1) Die RAID1 Partition md2 killen

das hier gar nicht erst anfangen !!!
mdadm --zero-superblock /dev/md2 (geht nicht !!)

mdadm --stop /dev/md2 (hat funktioniert)

mdadm --zero-superblock /dev/sda3 /dev/sdb3 (hat funktioniert)

Ein Test mit df -h
und
ein Filecheck mit e2fsck -f /dev/sda3 wirft nur Fehler aus, also unbrauchbar

die RAID Partitionen prüfen mit

cat /proc/mdstat

und nochmal aptitude update

(2) dann einzeln aufrufen :

aptitude install gparted

aptitude install tightvncserver

und den tightvncserver starten

(3) dort gparted im Menü starten und ein letzter Versuch, nicht die RAID1 Partiton "md2", sondern die verbliebene Plattenpartition "sda3" auf 22 GB schrinken - geht nicht, dauert ewig und bleibt dann hängen

(4) sda3 und sdb3 komplett löschen -
das hat endlich aber auch nur mit Mühe funktioniert.
.

Am Ende : Die 30GB root-Partitionen neu anlegen

Zum Booten des opensuse 13.2 Systems brauchen wir erst mal nur die gespiegelten beiden (sicherheitshalber jetzt) 30GB Partitionen auf den beiden Patten sda und sdb. Beide bekommen wieder die (alte) gleiche UUID wie vorher auch. Damit nichts schief läuft, wird mit dem gparted auch gleich die große vierte Extended Partition - aber völlig leer - angelegt, also der gesamt Plattenplatz ist damit belegt.

Das sieht dann so aus:

(5) sowohl auf sda und sdb je 30 GB als 3. "primary Partition" anlegen
und
(6) sowohl auf sda wie auch auf sdb den verbleibenden Rest von jeweils 893GB als 4. (extended) Partition anlegen
.
Den Rest machen wir wieder mit dem mdadm.
.

Die Partitionen sda3 und sdb3 vorbreiten

Das ist der jetzige Zustand der beiden Platten nach dem Neuanlegen der jetzt kleinen sda3 und sdb3 Partitionen mit je ca. 30 GB.

root@grml ~ # ls -l /dev/disk/by-uuid
total 0
root root 10 Jan 13 22:36 2a7bcb5f-15fb-4aba-ba59-c3f5bc613f45 -> ../../sda3
root root 10 Jan 13 22:36 62dce29f-524f-4aea-a6c9-a1d4fe43b95f -> ../../sdb3
root root  9 Jan 13 20:42 77506b7e-c0d2-4712-8461-e94f0ffe1c78 -> ../../md1
root root  9 Jan 13 20:42 f735ff65-bc3c-4685-b987-204b3a5a97aa -> ../../md0

Zuerst müssen wir wieder die alten (gesicherten) UUIDS in den beiden physikalischen Platten-Partitonen sda3 und sdb3 wieder eintragen. Beide physikalischen Platten-Partitionen haben dann wieder die gleiche UUID !!!!

root@grml ~ # tune2fs -U 73805d88-8640-0902-0651-2b82829bff5a /dev/sda3
tune2fs 1.42.12 (29-Aug-2014)
root@grml ~ # tune2fs -U 73805d88-8640-0902-0651-2b82829bff5a /dev/sdb3
tune2fs 1.42.12 (29-Aug-2014)

Das erste Ergebnis sieht dann (noch ohne RAID1) so aus :
root@grml ~ # blkid -o list

device fs_type label mount- point UUID
/dev/sda1 linux_raid_member any:0 (in-use) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sda2 linux_raid_member any:1 (in-use) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sda3 ext4     73805d88-8640-0902-0651-2b82829bff5a
         
/dev/sdb1 linux_raid_member any:0 (in-use) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sdb2 linux_raid_member any:1 (in-use) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sdb3 ext4     73805d88-8640-0902-0651-2b82829bff5a
         
/dev/md0 swap     f735ff65-bc3c-4685-b987-204b3a5a97aa
/dev/md1 ext4     77506b7e-c0d2-4712-8461-e94f0ffe1c78


Wichtige Zeilen sind zu erkennen :
Die gespiegelten Partitonen 1 und 2 und 3 auf den beiden Platten sda und sdb haben die gleichen UUIDs. Die dritte RAID1 Partition md2 ist noch nicht da.
.

Und nochmal formatieren

Sicherheitshalber formatieren wir die beiden neuen Partiton nochmal mit ext4- Die UUIDs hatten wir bereits mit dem tune2fs Befehl korrigiert.

mkfs -t ext4 /dev/sda3
mkfs -t ext4 /dev/sdb3

.

Jetzt wird erst mal das RAID1 erzeugt - aufpassen - der metadata Default stimmte so nicht !!

Mit dem mdadm wird die gespiegelte RAID1 Partition "md2" erzeugt.

Dieser erste Versuch ging nämlich schief : die originale Kommandozeile :

mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3

root@grml ~ # mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
............ der Output hier ist nicht relevant ..............
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata

- das hier macht "mdadm" automatisch bei neuen RAIDs ohne Option !!!!
also aufpassen es muß "die richtige" metdata Version ausgewählt werden.
(Bei uns hatte opensuse 13.2 die Version 1.0 installiert, also weder die 1.2 !!! noch die 0.9 - das wußte ich aber erst viel zu spät.)
.

Die mdadm- Korrektur mit der Option "--metadata"

HIER GEHT ES WEITER mit der Option "--metadata"

Hier habe ich also nachgebessert :

mdadm --create /dev/md2 --level=1 --raid-devices=2/dev/sda3 /dev/sdb3

und habe dann "--metadata=1.0" hinten dran gesetzt (also auch nicht die überall empfohlene Version 0.9 !!!)

und nochmal nachgebessert :

mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 --metadata=1.0 -N any:2


So sieht jetzt die Block-Liste nach der Formatierung erst mal aus:

Ein Zwischenschritt - mit einer neu erzeugten UUID

root@grml ~ # blkid -o list

device fs_type label mount point UUID
/dev/sda1 linux_raid_member any:0 (in-use) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sda2 linux_raid_member any:1 (in-use) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sda3 linux_raid_member grml:2 (in-use) 4f2ca1c7-db78-f71c-ba6f-ee40f99bed01
         
/dev/sdb1 linux_raid_member any:0 (in-use) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sdb2 linux_raid_member any:1 (in-use) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sdb3 linux_raid_member grml:2 (in-use) 4f2ca1c7-db78-f71c-ba6f-ee40f99bed01
         
/dev/md0 swap     f735ff65-bc3c-4685-b987-204b3a5a97aa
/dev/md1 ext4     77506b7e-c0d2-4712-8461-e94f0ffe1c78
/dev/md2 ext4     507e54af-4c1e-4a75-8eea-49e3ace7b1ff

.

Wir brauchen für unser md2 aber die alte UUID

Die RAID Partition md2 hat bei der Neuanlage natürlich eine neue UUID bekommen (weil ich nicht aufgepaßt hatte), aber wir brauchen die alte UUID :652a2a86-65cb-425c-9760-bba641245f0d

Und das geht so : (also nicht mit dem mdadm) :
Hier steht es genau :
http://manpages.ubuntu.com/manpages/precise/man8/mke2fs.8.html
Option -U UUID
Create the filesystem with the specified UUID.

also nochmal formatieren :

mkfs.ext4 -v /dev/md2 -U 652a2a86-65cb-425c-9760-bba641245f0d

Endlich das Ergebnis
root@grml # mkfs.ext4 -v /dev/md2 -U 652a2a86-65cb-425c-9760-bba641245f0d
/dev/md2 contains a ext4 file system
        created on Fri Jan 13 23:07:02 2017
fs_types for mke2fs.conf resolution: 'ext4'
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1921360 inodes, 7675904 blocks
383795 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
235 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Filesystem UUID: 652a2a86-65cb-425c-9760-bba641245f0d
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Formatiere ich also die RAID Partition "md2" wie mit dem Befehl oben, schreibt "
mkfs.ext4" die gewünschte (unsere alte) RAID UUID in die beiden Superblocks auf die Platte.

Und das prüfen wir gleich mal :

Jetzt muß bei "md2" die alte UUID wieder da sein !

root@grml # blkid -o list

Fast fertig mit der alten UUID

device fs_type label mount point UUID
/dev/sda1 linux_raid_member any:0 (in use) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sda2 linux_raid_member any:1 (in use) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sda3 linux_raid_member grml:2 (in use) 4f2ca1c7-db78-f71c-ba6f-ee40f99bed01
         
/dev/sdb1 linux_raid_member any:0 (in use) 0ab0005c-f4e0-03a1-4c63-d6ca0162ef6c
/dev/sdb2 linux_raid_member any:1 (in use) cc32f60d-da33-20f2-1699-0c050b6fa77d
/dev/sdb3 linux_raid_member grml:2 (in use) 4f2ca1c7-db78-f71c-ba6f-ee40f99bed01
         
/dev/md0 swap     f735ff65-bc3c-4685-b987-204b3a5a97aa
/dev/md1 ext4     77506b7e-c0d2-4712-8461-e94f0ffe1c78
/dev/md2 ext4     652a2a86-65cb-425c-9760-bba641245f0d

.

Nachtrag : es stimmt immer noch nicht

Wenn man in die Liste oben genau hin schaut, sieht man, md0 und md1 haben ein Label (name=any:0 und any:1) und md2 hat keines bzw ein falsches Label. Ganz genau sieht man das, wenn man endlich weiß, worauf man alles achten soll hier:

root@grml / # mdadm --detail --scan

Type Device Version Name UUID  
ARRAY /dev/md/2 metadata=0.90   UUID=da722777:916406dc:d8b78f65:99226e41  
ARRAY /dev/md/0 metadata=1.0 any:0 UUID=0ab0005c:f4e003a1:4c63d6ca:0162ef6c  
ARRAY /dev/md/1 metadata=1.0 any:1 UUID=cc32f60d:da3320f2:16990c05:0b6fa77d  

.

Wie kommt man auf solche Feinheiten ?

Wie ich darauf gekommen bin ? Die installierte opensuse Installation erkennt die Partition "md2" nicht !!! Auch nicht in der virtuellen Maschine des Rescue Systems. Zumindest müsste sie dort bis zum "Login" booten, auch wenn die falsche Netzwerkarte installiert ist. Der Boot-Vorgang landet aber (nach einem !!! sehr langen !!! Timeout) im sogenannten "dracut", weil das Betriebssystem fehlt.
.

Also Nachbessern ist angesagt :

Wir prüfen, was mdadm dazu auswirft : mdadm -v --assemble /dev/md2

mdadm: looking for devices for /dev/md2
mdadm: no recogniseable superblock on /dev/md/1
mdadm: no recogniseable superblock on /dev/md/0
mdadm: no recogniseable superblock on /dev/md/2
mdadm: no recogniseable superblock on /dev/loop0
mdadm: Cannot assemble mbr metadata on /dev/sda4
mdadm: /dev/sda3 is busy - skipping
mdadm: /dev/sda2 has wrong uuid.
mdadm: /dev/sda1 has wrong uuid.
mdadm: Cannot assemble mbr metadata on /dev/sda
mdadm: Cannot assemble mbr metadata on /dev/sdb4
mdadm: /dev/sdb3 is busy - skipping
mdadm: /dev/sdb2 has wrong uuid.
mdadm: /dev/sdb1 has wrong uuid.
mdadm: Cannot assemble mbr metadata on /dev/sdb
.
Das Programm findet gar keine Devices unter md2 ???. Da müssten doch sda3 und sdb3 eingebunden bzw. enthalten sein.
.

Ein "detail scan" gibt Aufschluss:

mdadm --detail --scan

root@grml / # mdadm --detail --scan
ARRAY /dev/md/2 metadata=0.90 UUID=da722777:916406dc:d8b78f65:99226e41
ARRAY /dev/md/0 metadata=1.0 name=any:0 UUID=0ab0005c:f4e003a1:4c63d6ca:0162ef6c
ARRAY /dev/md/1 metadata=1.0 name=any:1 UUID=cc32f60d:da3320f2:16990c05:0b6fa77d

Das war also mein Fehler, metadata muß 1.0 sein und nicht 0.9 und nicht 1.2 .

root@grml / # ls -la /dev/disk/by-uuid/
lrwxrwxrwx 1 root root   9 Jan 14 21:46 652a2a86-65cb-425c-9760-bba641245f0d -> ../../md2
lrwxrwxrwx 1 root root   9 Jan 14 21:46 77506b7e-c0d2-4712-8461-e94f0ffe1c78 -> ../../md1
lrwxrwxrwx 1 root root   9 Jan 14 21:46 f735ff65-bc3c-4685-b987-204b3a5a97aa -> ../../md0
root@grml / #

Die RAID1 Partition "md2" löschen (und nochmal anlegen)

root@grml / # mdadm --stop /dev/md2 
mdadm: stopped /dev/md2

root@grml / # mdadm -v --zero-superblock /dev/sda3 /dev/sdb3
root@grml / #

Und sicherheitshalber die beiden Partitionen sda3 und sdb3 überprüfen :

root@grml / # e2fsck -f /dev/sda3
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: 73287/1921360 files (0.0% non-contiguous), 664563/7679984 blocks
root@grml / # e2fsck -f /dev/sdb3
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb3: 73287/1921360 files (0.0% non-contiguous), 664563/7679984 blocks
root@grml / #

Das bedeutet, sda3 und sdb3 sind in Ordnung.
.

md2 erzeugen :

Wir müssen also beim Anlegen unsere neuen (geklonten) RAID1 Partition "md2" auf
.

  1. die UUID und
  2. den Namen (Label) der beiden physikalischen Partitionenund
  3. die metadata Version 1.0 schauen.

.
Beide Partitionen formatieren mit :



und tunen :
tune2fs -L any:2 -U 73805d88-8640-0902-0651-2b82829bff5a /dev/sda3


root@grml / # tune2fs -L any:2 -U 73805d88-8640-0902-0651-2b82829bff5a /dev/sda3
tune2fs 1.42.12 (29-Aug-2014)
root@grml / # tune2fs -L any:2 -U 73805d88-8640-0902-0651-2b82829bff5a /dev/sdb3
tune2fs 1.42.12 (29-Aug-2014)


Das RAID1 erstellen mit Namen !!! und Level und meta-Version 1.0:

mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 --metadata=1.0 -N any:2

dann die Formatierung mit Label/Name und der alten UUID

mkfs.ext4 -v /dev/md2 -U 652a2a86-65cb-425c-9760-bba641245f0d

blkid -o list

mdadm --detail --scan

.

Und endlich können wir die gesicherten Files zurückschreiben

Ganz am Anfang der Aktion hatten wir die (funktionierende) root Partition in ein tar.gz Archiv gepackt und gesichert. Das packen wir jetzt wieder aus.

Zuvor müssen die beiden Raid1 Partitionen wieder gemounetet werden, denn auf md1 haten wir das Archiv geparkt.

root@grml / # mkdir mnt1
root@grml / # mkdir mnt2
root@grml / # mount /dev/md1 mnt1
root@grml / # mount /dev/md2 mnt2

Auspacken geht mit dem midnight commander mit einem Klick.

root@grml / # mc -a

root@grml /mnt2 # dir
total 1,9M
drwxr-xr-x  37 root root  360 Jan 14 00:58 ..
drwxr-xr-x  13 root root 4,0K Dez 13  2018 var
drwxr-xr-x  13 root root 4,0K Dez 13  2018 usr
drwxrwxrwt   9 root root 4,0K Jan 11 00:20 tmp
drwxr-xr-x   2 root root 4,0K Dez 13  2018 sys
drwxr-xr-x   4 root root 4,0K Dez 13  2018 srv
drwxr-xr-x   2 root root 4,0K Sep 25  2014 selinux
drwxr-xr-x   2 root root 4,0K Dez 13  2018 run
drwx------  10 root root 4,0K Jan 11 00:20 root
drwxr-xr-x   2 root root 4,0K Dez 13  2018 proc
drwxr-xr-x   2 root root 4,0K Jan  9 21:00 opt
drwxr-xr-x   2 root root 4,0K Sep 25  2014 mnt
drwx------   2 root root 4,0K Dez 13  2018 lost+found
drwxr-xr-x   8 root root 4,0K Jan  9 21:19 lib64
drwxr-xr-x  12 root root 4,0K Jan  9 23:23 lib
drwxr-xr-x   3 root root 4,0K Jan  9 16:04 home
drwxr-xr-x   2 root root 4,0K Dez 13  2018 dev
drwxr-xr-x   2 root root 4,0K Dez 13  2018 boot
drwxr-xr-x   2 root root 4,0K Jan  9 21:19 bin
drwxr-xr-x  22 root root 4,0K Jan 14 00:59 .
drwxr-xr-x   2 root root  12K Jan  9 23:23 sbin
drwxr-xr-x 106 root root  12K Jan 11 00:20 etc
-rw-r--r--   1 root root  29K Jan 10 23:57 .readahead
-rw-------   1 root root 1,8M Dez 13  2018 core
root@grml /mnt2 #
.

Der Test, ob es geklappt hatte

Das debian 9.0 Rescue-System, das ja nur im RAM "wohnte", hat hoffentlich ausgedient.

Im Rescue-System reicht ein Software-"reboot" (doch nicht) aus, obwohl vorher im ZKM das Rescue abgeschaltet worden war. Denn es kommt das Rescue wieder hoch.

Also "reboot" reicht nicht, es muß doch ein harter Reset her.

 

 

 

 


Und es ist nicht wieder da.


Zurück zur Startseite ----- © 2009 / 2018 - Copyright by Dipl. Ing. Gert Redlich - Zum Telefon - - - - NEU : Zum Flohmarkt