Re: raid5, eine Platte mit excessive reads
Am 28.09.2012 10:24, schrieb Andre Tann:
> Pierre Bernhardt, Freitag, 28. September 2012:
>
>> Soweit die 1. Platte komplett raus ist sollte das Booten auch von der
>> 2. Platte funktionieren.
>
> Das habe ich im vorgenannten Thread ausgiebig getestet, und es kein
> einziges Mal zum Laufen gebracht. Welchen Bootloader verwendest Du?
grub 2:
ii grub-common 1.98+20100804-14+squeeze1 GRand Unified Bootloader, version 2 (common files)
ii grub-pc 1.98+20100804-14+squeeze1 GRand Unified Bootloader, version 2 (PC/BIOS version)
> Das hört sich an, wie wenn Du grub und nicht grub-legacy verwendest,
Ja, siehe oben.
> richtig? Mit grub habe ich es wie gesagt nie zum Booten gekriegt, auch
> nicht, wenn ich vorher dpkg-reconfigure grub-pc gemacht habe.
Bei mir habe ich alle vier Platten gewählt + das md-Device für boot.
> Kannst Du bitte ggf. nochmal die Schritte umreißen, die notwendig sind,
> damit das klappt? Ich gehe von einer Neuinstallation mit sda und sdb
> aus. Wie richtest Du die Platten, LVM usw. während des
> Installationsprozesses ein, und was machst Du ggf. danach noch?
Zur Einrichtung habe ich eigentlich ganz einfach die Manuelle Auswahl
während des Installationsprozesses verwendet.
Dazu habe ich allerdings manuell erst mal mit fdisk -u -c die Platten
einzeln Partitioniert:
root@newxen:~# fdisk -l -c -u /dev/sd?
Disk /dev/sdb: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf5af3120
Device Boot Start End Blocks Id System
/dev/sdb1 2048 206847 102400 fd Linux raid autodetect
/dev/sdb2 206848 42149887 20971520 fd Linux raid autodetect
/dev/sdb3 88271528 625142447 268435460 fd Linux raid autodetect
Disk /dev/sdc: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xbadd4095
Device Boot Start End Blocks Id System
/dev/sdc1 * 2048 206847 102400 fd Linux raid autodetect
/dev/sdc2 206848 42149887 20971520 fd Linux raid autodetect
/dev/sdc3 88271528 625142447 268435460 fd Linux raid autodetect
Disk /dev/sdd: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x24dd5756
Device Boot Start End Blocks Id System
/dev/sdd1 * 2048 206847 102400 fd Linux raid autodetect
/dev/sdd2 206848 42149887 20971520 fd Linux raid autodetect
/dev/sdd3 88271528 625142447 268435460 fd Linux raid autodetect
Disk /dev/sde: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d0d535a
Device Boot Start End Blocks Id System
/dev/sde1 * 2048 206847 102400 fd Linux raid autodetect
/dev/sde2 206848 42149887 20971520 fd Linux raid autodetect
/dev/sde3 88271528 625142447 268435460 fd Linux raid autodetect
Nicht wundern wegen dem fehlenden sda. Das ist derzeit eine an einem
Usb Controller in eine DomU durgereichte USB-Platte. Die war nach dem
booten noch aktiv und habe ich manuell dann in die DomU "verschoben".
Also nach dem partitionieren (geht auch bei der Installation vor dem Dateisystem-
setup) habe ich erst die Raids alle eingerichtet (teilweise wegen einiger
Besonderheiten per mdadm), dann habe ich das Raid für die /dev/sd?1 mit ext3
formatiert und /boot zugewiesen.
/dev/sd?2 und /dev/sd?3 wurden als zukünftiges lvm erst mal mit dm-crypt
verschlüsselt angelegt (per Menüsetup) und dann jeweils für /dev/sd?2 die rootdg
und für /dev/sd?3 die datadg angelegt.
Auf der rootdg habe ich dann /, swap, /var angelegt. Auf datadg /home.
Alle Dateisysteme sind ext3 formatiert. Nach dem Anlegen habe ich dann die
Installation weiter durchgeführt.
Ich weiss jetzt nicht warum es funktionieren könnte, aber ich vermute fast,
das wenn grub den bootloader nicht in den Platten korrekt findet, könnte es
sein das es dann nur deswegen funktioniert, weil der grub das /dev/md127
verwendet?:
md127 : active raid1 sdb1[5] sdc1[4] sdd1[7] sde1[8]
101376 blocks super 1.2 [4/4] [UUUU]
bitmap: 0/1 pages [0KB], 65536KB chunk
Auch hier nicht wundern, es sind tatsächlich 4 Platten für /boot alle gespiegelt.
Noch ein weiterer Punkt:
Ich entsinne mich, das ich halt ab und an besonders nach Updates (Kernel,
grub, initramfs usw.) mal das eine oder andere Boot-Problem hatte, was ich
aber immer mit dem Rescue-Mode der Installationsdvd beheben konnte. Zugegebener
Maßen ist das Menü von ar*** und funktioniert nicht richtig, weil es die
Raids/LVM/dmcrypt nicht richtig abfragt/erkennt. Daher ist immer ein wenig
Handarbeit notwenidig.
1. ggf. mds starten
2. immer crypsetup luksOpen auf die mds
3. ggf. LVMs starten (lvchange -a y auf alle volumes?)
Nach dem mounten des nun gefundenen / auf rootdg/root kann ich die chroot-Shell
bekommen und mit mount /boot und mount /var und ggf. /home usw. den Rest mounten.
Dann häufig einfach ein update-initramfs -k all -u und ein update-grub sowie ein
evtl. erneutes schreiben mittels dpkg-reconfigure grub-pc und schon konnte ich
nach einem reboot immer das System wieder normal booten.
Das war aber eigentlich nicht gefragt.
Reply to: