debianforum.de

Verfasst: **05.03.2017 20:48:52**

Ich habe mir die Ausgabe von blkid tatsächlich nach LO Calc kopiert, um da durchzusteigen.

Ich habe habe keine Auffälligkeiten hinsichtlich der UUIDs feststellen können. Sowohl in der SysRescueCD als auch im chroot werden die RAID-Verbünde identisch aufgebaut. Weshalb es dm127_0 heißt und nicht dm127... weiß der Henker.
Dann habe ich mir deine vorherigen Postings noch mal angeschaut und da sind mir ein paar Sachen aufgefallen:

ext2 ist für /boot völlig OK. Das hat mit dem bootable-Flag der Partition nichts zu tun. Das bootable-Flag brauchst du bei GPT auch nur, um einem klassichen BIOS (nicht UEFI) anzuzeigen, dass es von der Partition booten soll. Da ich keine EFI-Partition finden konnte, nehme ich an, dass dein System klassisch bootet.
Wo kommt dieser Kernel 3.2 her, für den ein neues initramfs erzeugt werden soll? Jessie wird mit 3.16 ausgeliefert und in Squeeze und den Backports ist 4.9. Ist das am Ende der Kernel der SystemRescueCD? Hast du update-initramfs versehentlich nicht aus der chroot-Umgebung heraus ausgeführt?

Eine Idee: bau das System erst mal nur minimal auf, d.h. so weit, dass /boot und / da sind und starten kannst. Danach baust du aus dem nunmehr wieder laufenden System die RAID-Verbünde, die crypttab etc. wieder zusammen. Ggf. kommentierst du die in der mdadm.conf und crypttab erst mal aus.

Verfasst: **05.03.2017 21:05:55**

Also die rescuecdkommtmit nem 4.4.50-std493-amd64 kernel.

Der 3.2 Kernel ist der, den mir das letzte Wheezy update auf dem Server beschert haben muss.

Und zu deinem Tip: Genau das versuche ich ja gerade:
/boot -> md127 -> sdc/d1 ext2 (unverschlüsselt)
/ -> md128 -> sdc/d3 -> luks -> ext4

Alles lief ja auch prima,bis ich bei dem Versuch aus der chroot Umgebung grub auf sdc installieren wollte (eine der beiden Zukünftigen boot-Partitionen).
Da gab es dann halt:

Code: Alles auswählen

root@sysresccd:/# grub-install /dev/sdc
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/md127 failed.

Und die Frage, ob ich zunächst die grub.cfg updaten muss:

Code: Alles auswählen

grub-mkconfig -o /boot/grub/grub.cfg

und das sind die configs: (Kommentarzeilen mal weggelassen)

Code: Alles auswählen

root@sysresccd:/# cat /etc/crypttab
# <target name> <source device>         <key file>      <options>
cryptroot       UUID=e8ba3f74-ffff-45ab-8965-bbd0a254af3c       none    luks
# cryptdata     UUID=   none    luks

root@sysresccd:/# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/md128 during switch
/dev/mapper/cryptroot    /               ext4    errors=remount-ro 0       1
# /boot was on /dev/md127 during switch
UUID=a9349ca2-6a9e-4640-923c-3dbd7c028aa1        /boot           ext3    defaults        0       2

root@sysresccd:/# cat /etc/mdadm/mdadm.conf
#New after hdd switch
ARRAY /dev/md/127_0 metadata=0.90 UUID=3de7d48a:7c67c842:c44c77eb:7ee19756
ARRAY /dev/md/128 metadata=1.2 name=sysresccd:128 UUID=883b5984:310045c3:94bb2809:4d46bc9e
ARRAY /dev/md129 metadata=1.2 name=sysresccd:129 UUID=b360b8e5:b30a047e:dd887155:2a75262f

Wo ich mir gerade diese Ausgabe anschaue:

Code: Alles auswählen

root@sysresccd:/# ls -l boot/
-rw-r--r-- 1 root root   129281 Jan  4  2016 config-3.2.0-4-amd64
drwxr-xr-x 3 root root     5120 Mar  5 14:22 grub
-rw-r--r-- 1 root root 12171403 Mar  5 12:59 initrd.img-3.2.0-4-amd64
-rw-r--r-- 1 root root  2116191 Jan  4  2016 System.map-3.2.0-4-amd64
-rw-r--r-- 1 root root  2845152 Jan  4  2016 vmlinuz-3.2.0-4-amd64

Müsste ich "System.map-3.2.0-4-amd64" und "config-3.2.0-4-amd64" nicht auch irgendwie noch updaten?

Verfasst: **05.03.2017 22:02:39**

Jetzte checke ich es langsam gar nicht mehr.
In einem anderen Forumfand ich den Tip, für die boot-partitionen folgendes flag zu setzen: "bios_grub"
Also 1.Versuch:

Code: Alles auswählen

# parted /dev/sdc set 1 bios_grub on
Information: You may need to update /etc/fstab.
# partprobe
# grub-install /dev/sdc
Installation finished. No error reported.

Das ganze für sdd wiederholt:

Code: Alles auswählen

# parted /dev/sdd set 1 bios_grub on
Information: You may need to update /etc/fstab.
# partprobe
# grub-install /dev/sdd
/usr/sbin/grub-probe: error: unknown filesystem.
Auto-detection of a filesystem of /dev/md127 failed.
Try with --recheck.
If the problem persists please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>

boot von sdc bleibt bei "loding grub" hängen
boot von sdd orher beidem blinckenden cursor

Verfasst: **05.03.2017 22:20:16**

Das sieht danach aus, als sei GRUB nicht vollständig oder nicht richtig installiert. Stage 1 wird in den MBR geschrieben und lädt die folgenden Stages nach. Das scheint er nicht zu schaffen, weshalb da "Loading GRUB" stehen bleibt. grub-install empfiehlt von sich aus die Option --recheck (und https://wiki.ubuntuusers.de/GRUB_2/Repa ... AID-System auch). Hast du das bereits versucht?

Verfasst: **06.03.2017 09:45:16**

Sorry (gestern hatte ich zu dem ganzen Zeug auch noch den ganzen Tag einen Schädel).
ja die --recheck option hatte ich schon durchgeführt.

Ich vermute eher, dass ich ein Problem mit meinem partition table habe. Was mir aufgefallen ist:
Setzen kann ich flags mit parted, allerding nur eines. Was ich aber im Vergleich zu den alten Platten brauche ist die Möglichkeit, dass die 1. Partition 2 flags hat. root und boot (bios_grub).
Momentan bekomme ich das aber nicht hin, da offenbar immer nur ein flag gesetzt wird (bzw. das vorherige "überschrieben" wird).

Ausserdem gibt es in den gpt tables keine Spalte "part-type".
(alles auf dem Gedächtnis zitiert, bin momentan bei der Arbeit)

Verfasst: **06.03.2017 11:45:26**

Ich bin auch bei der Arbeit... Keine Hektik... [emoji23]

Verfasst: **06.03.2017 19:05:50**

so da haben wir also die korrekten Werte:
alte boot-Partition (erste Part) sieht so aus:

Code: Alles auswählen

Model: ATA Hitachi HTE54322 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  500MB   499MB   primary                  boot, raid
 2      500MB   57.5GB  57.0GB  primary                  raid
 3      57.5GB  60.5GB  3000MB  primary  linux-swap(v1)
 4      60.5GB  245GB   185GB   primary                  raid

neue (noch nicht) boot Partition (erste Part):

Code: Alles auswählen

Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdc: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  524MB   523MB   ext2         1     bios_grub
 2      524MB   4744MB  4219MB               2
 3      4744MB  75.2GB  70.4GB               3     raid
 4      75.2GB  3001GB  2925GB               4     raid

Die Frage ist jetzt also, wie muss die 1.Part korrekt konfiguriert werden, damit sowohl grub im MBR landet, als auch das RAID (sdc1/sdd1) erkannt wird?
EDIT:
laut diesem Beitrag: http://serverfault.com/questions/320697 ... tion-types ist bios_grubwohldie richtigeOption,wie ich es verstehe.
So bin ich vorgegangen:
cryptsetup open --type luks /dev/md128 cryptroot
/dev/mapper/cryproot als /new/ gemounted
md127 als /new/boot gemounted
mount -o bind /sys /new/sys
mount -o bind /proc /new/proc
mount -o bind /dev /new/dev
chroot /new /bin/bash #sysrescuenutzt die zsh, die auf dem Zielsystem nicht installiert ist
Danach halt grub installiert (einmal ohne Meldung,einmal mit Fehler).Bootenkonnte aber keine der Platten.

Einzige Idee die ich momentan habe: /boot hat metadata v0.9 und auf dem alten System war es v1.2. Ich könnte natürlich das RAID der boot-Partition jetzt nochmal mit v 1.2neu aufsetzen,ist ja klein und damit schnell gemacht..

EDIT2:
initramfs hat ja seine eigene Kopie von mdadm.conf. Aber: holt sich initramfs die von /etc/mdadm/mdadm.conf oder legt es die selbst an?
In ersterem Fall scheint mir die aufegelesene version immernoch strange:

Code: Alles auswählen

ARRAY /dev/md/127_0 metadata=0.90 UUID=3de7d48a:7c67c842:c44c77eb:7ee19756
ARRAY /dev/md/128 metadata=1.2 name=sysresccd:128 UUID=883b5984:310045c3:94bb2809:4d46bc9e
ARRAY /dev/md129 metadata=1.2 name=sysresccd:129 UUID=b360b8e5:b30a047e:dd887155:2a75262f

wie kommen diese Unterschiede zustande? md129 md/128 md/127_0?

In zweiterem:Sollte ich dann das System ohne die alten RAID Verbünde starten?

Verfasst: **06.03.2017 20:35:11**

Hier scheint es noch ein paar Hinweise auf zu korrigierende confs zu geben:
http://unix.stackexchange.com/questions ... otup#71209
innerhalb von chroot:
/boot/grub/devicemap
/etc/default/grub

dann nochmalinitramfs neu bauen und grub installieren/ updaten ist die kurzversion.
Mal schauen
EDIT:
Mist: das hat gestern definitiv noch funktioniert:

Code: Alles auswählen

% mount /dev/md127 /new/boot 
mount: wrong fs type, bad option, bad superblock on /dev/md127,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

und der Parttable von md127 sieht auch merkwürdig aus:

Code: Alles auswählen

Model: Linux Software RAID Array (md)
Disk /dev/md127: 523MB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags: 

Number  Start  End    Size   File system  Flags
 1      0.00B  523MB  523MB  ext2

Verfasst: **07.03.2017 02:50:01**

mclien hat geschrieben:Momentan sieht das Datenerzeichnis auf mein Server so aus:
RAID1 (sda3 und sdb3) + RAID1 (sdc1 und sdd1) -> LVM -> /daten
nun würde ich das ganze gerne Verschlüsseln ohne alles neu aufsetzten zu müssen.

Ich kann beim besten Willen nicht verstehen, wie man so etwas auch nur in Erwägung ziehen kann. In der ganzen Zeit nun seit in diesem Thread das Problem durchgekaut wird, hätte man das ganze System locker x-mal neu aufsetzen und die Daten entsprechend zurück spielen können. Eigentlich müsste doch inzwischen klar sein wie kompliziert das ist. Aber muss jeder selbst wissen.

Verfasst: **07.03.2017 17:56:53**

Und ich kann beim besten Willen nicht verstehen, wie man einen Thread nicht vollständig lesen kann, bevor man seinen Senf dazugibt.

Verfasst: **07.03.2017 19:16:24**

So habe mein Wissen zu gpt Part tables ein wenig erweitert.
So wie ich es verstehe, kennt gpt keinen MBR. Die Bedeutet, dass gpt eine ZUSÄTZLICHE Partition dafür braucht, die dann das flag bios_grub haben muss.
Also statt:

Code: Alles auswählen

number  Start   End     Size    File system  Name  Flags
 1      1049kB  524MB   523MB   ext2         1     bios_grub
 2      524MB   4744MB  4219MB               2
 3      4744MB  75.2GB  70.4GB               3     raid
 4      75.2GB  3001GB  2925GB               4     raid

muss ich den wohlso aufbauen:

Code: Alles auswählen

number  Start   End     Size    File system  Name  Flags
 0      0kB 1048kB   1MB   ext2         0     bios_grub   # neue part
 1      1049kB  524MB   523MB   ext2         1     raid  # das müsste das RAID wieder lesbar machen
 2      524MB   4744MB  4219MB               2
 3      4744MB  75.2GB  70.4GB               3     raid
 4      75.2GB  3001GB  2925GB               4     raid

Die Frage ist nun, ob ich die bios_grub partition noch or die /boot RAID Partition bauen kann. Was möglicherweis eklappt,da ich die 1.Part ja erst bei 1049KB angefangen habe.
Ansonsten muss ich wohl die 1.Part nochmal neu bauen. Ausserdme stellt sich die Frage, ob ich "0" als nummer vergeben darf, wobei das nicht weiter relevant sein dürfte solange bios_grub am Anfang der Platte steht.
EDIT:
funktioniert ungefähroder zumindest besser (die Part number "0" gibts natürlich nicht,ist dei "5" geworden).
- md127 nochmal mit neuem file system bestückt
- per chroot initramfs neu
- grub install
Zumindest läd Grub jetzt schonma,findet allerdings die /boot Platte nicht (keine disc zur UUID)
checke jetzt nochmal configs.
EDIT2:
OK, die UUID,die Grub laden will ist die alte ID der /boot RAID PArtition.
Irgendetwas in Grub muss wohlnoch korrigiert werden...

Verfasst: **10.03.2017 14:29:47**

Weitest gehend abschließende Melldungen:
/etc/fstab und
/etc/cryptab
korrekt editierenud alles läuft wieder. Diesmal auf einem verschlüsseltem RAID 1.
Momentan muss ich halt beim boot 2x eine Passphrase eingeben (cryptroot und cryptdata).Ob ich mir die Mühe mache cryptdata noch auf keyfile umzubauen, weiß ich noch nicht. Kommt drauf an wie oft ich die Kiste booten muß..

Verfasst: **11.03.2017 09:57:24**

Sehr schön.

Was war denn letztendlich falsch bzw. was hast du noch geändert, um die Sache zum Laufen zu bringen?

Noch ein Tipp: leg doch für die verschlüsselten Daten eine systemd-mount-unit an, die das während des Starts entschlüsselt und mountet. Wenn diese Unit auf verschlüsseltem / liegt, kannst du da ja das Passwort reinschreiben.

(Schmuck am Nachthemd: Debian bildet die Namen der entschlüsselten Devices aus dem Namen des verschlüsselten Device mit angehängtem _crypt. Dadurch kann man die Geräte einfach einander zuordnen. Auf dem Laptop, auf dem ich gerade tippe, gehört sda3_crypt zu sda3.)

Verfasst: **11.03.2017 21:48:47**

Der wesentlich fail, war halt die zusätzlcihe Part. die gpt braucht. Durch den missglückten Install auf die /boot Part war die jetzt geschrottet.
Also nochmal das RAID md127 für bootmit neuem Dateisystem bestückt
die daten vom alten /boot aufs neue /boot gesynct
chroot und dann
- grub-install
- update-grub

Und offenbar hatte ich in der /etc/fstab nur die überflüssigen Dinge auskommentiert, aber die UUID für boot noch nicht mit der neuen Ausgetauscht.
Danach ohne Probleme gebootet und dann noch die /daten Part eingehängt (fstab und crypttab).

Bin am überlegen, ob ein WIKI EIntrag für das ganze lohnt...

Oh und Danke für Deinen "Beistand"

debianforum.de

Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?

Re: Bestehendes RAID + LVM im Betrieb verschlüsseln?