Diskussion:NonRaid zu (software)Raid1 SuSE 10 1

Wie wollen wir mit diesem Thema in Zukunft umgehen

Dieses Howto wurde ursprünglich mal fürs Forum geschrieben. Die damals verwendetet Methode mit den Konsolausgaben zu arbeiten ist allerings hier im Wiki nicht sonderlich gut geeignet. Ursprünglich war es für 10.1 geschrieben (steht auch so noch im Namen), mittlerweile sind einige Befehlsoptionen enthalten, die es damals noch gar nicht gab. Auf 10.3 sind schon jetzt einige Dinge ganz anders, was sich in kommenden Versionen noch alles ändert ???? Wenn wir also hier weiterhin Änderungen vornehmen, dann kann es ganz schnell mal passieren, dass es unter irgend einer Version bei irgend jemanden mal schief geht. Wir laufen also Gefahr, das mit diesem Howto genau das passiert, was mit den meisten Howtos in diesem doch recht sensiblen und nicht einfachen Themenumfeld schon passiert ist, und eigentlich der Grund war, um es überhaupt nieder zu schreiben, " Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 ... funktionieren "

Wie machen wir also weiter?

Möglichkeiten:

Permanentlinks auf getestete Versionen 

im Kopf werden PermanentLinks auf getestete spezielle Versionen in der Historie gesetzt. Damit können Änderungen problemlos gemacht werden und immer auf der neuesten Version aktualisiert werden. Allerdings sind dann die "alten Versionen" nicht mehr korrigierbar und wir leben von der Zuverlässigkeit und Lebensdauer (500 glaube ich) der Historie

alle Versionsunterschiede einarbeiten 

dann wird das hier schnell sehr unübersichtlich und uU überhaupt nicht mehr brauchbar

für jede Version speziell überarbeitet selbstständige Beiträge 

hier müssten dann eventuell Änderungen doppelt und dreifach gemacht werden.

komplett überarbeiten und ganz neu aufbauen 

hier stellt sich die Frage wer hat so viel Zeit und entsprechen die Möglichkeiten das alles an die verschiedenen Versionen zu testen.

Robi 19:26, 1. Feb. 2008 (CET)

Eure Meinung ist gefragt

leider gibt's hier bis jetzt noch keine Rückmeldungen, aber mittlerweile schreiben wir 12.2 und default ist auf Grub2 und systemd gesetzt.

Eine 12.2 kann man zwar noch bequem mit Grub betreiben aber 12.2 und einem Betrieb zB. unter sysVinit kann ich aus eigenen Erfahrungen nur wärmstens abraten.

Das Howto braucht also dringend ein Update/Upgrade.

Was machen wir nun, dieses Alte ändern und über Permanetlinks in die alten Vorgängerversion verweisen, oder ein 2. für die aktuellen Versionen erstellen, oder wird ein solches Howto in Zukunft überhaupt noch gebraucht?

Hat schon mal jemand auf einer 12.? das Howto ausprobiert und erste Erfahrungen gesammelt wo sich die Unterschiede gravierend vom Howto unterscheiden?

Was ist denn draußen bei euch im Feld zur Zeit für Mirror-Methoden angesagt? (komplette Platte gespiegelt eventuell sogar noch mit LVM drauf oder noch die klassischen gespiegelten Partitionen, oder spielt ihr alle schon mit btrfs ? )

Bitte mal ein paar Rückmeldungen? Im Moment habe ich zwar keine passende HW dazu frei, aber schätze Ende Februar hätte ich Zeit das mal zu überarbeiten, wenn denn notwendig

Robi (Diskussion) 11:57, 30. Dez. 2012 (CET)

---

Beispiel einer menu.lst bei openSUSE 10.3

Als Hilfestellung hier noch einmal meine orginale und die entgültige menu.lst auf einem openSUSE 10.3. Die Suspend to Disk Funktion wurde komplett abgeschalten, da sie zu Wechselwirkungen und Problemen mit dem gespiegeltem Swap führte. Wer diese Funktion dennoch braucht, oder sonstige Hilfe oder spezielle Einstellungen für die einzelnen Kerneloptionen benötigt, sollte sich einmal im Verzeichnis /usr/src/linux/Dokumentation umsehen. Dort sind einige Dateien wie zB. kernel-parameters.txt md.txt power/swsusp-and-swap-files.txt die hier sehr hilfreich sind.

Die Konfiguration wurde ausgetestet mit SCSI-Platten in Wechselrahmen (ohne irgend ein weiteres zusätzliches scsi-binding). Unter anderem hat folgendes problemlos funktioniert

• Entfernen eine Platte im laufendem Betrieb
• Zerstörung des MBR auf Platte /dev/sda und anschließendem reboot
• Entfernen der ersten Platte (also die Platte die normaler weise sda wird) und starten des Rechners
• hinzufügen und syncronisieren einer vorher entfernten Platte im laufenden Betrieb

Achtung: die beiden Ausdrucke der menu.lst enthalten Zeilenumbrüche die beim kopieren entstanden sind, sie wurden jedoch absichtlich nicht entfernt um hier im Wiki keine überlangen Zeilen zu produzieren.

Orginale menu.lst erstellt bei der Installation und/oder YaST

# Modified by YaST2. Last modification on Wed Feb 20 03:26:32 CET 2008
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 acpi=force resume=/dev/sda1 sp
lash=silent showopts
    initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=normal showopts ide=nodma apm=off ac
pi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd /boot/initrd-2.6.22.17-0.1-default

die für die Rootspiegelung geänderte menu.lst

# Modified by ROBI. Last modification on Wed Feb 29 03:26:32 CET 2008
default 0
fallback 1
timeout 8
gfxmenu (hd0,1)/boot/message

#---------- RAID - A----------------#
title openSUSE 10.3 - sda
    root (hd0,1)
    kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
    initrd (hd0,1)/boot/initrd

#---------- RAID - B----------------#
title openSUSE 10.3 - sdb
    root (hd1,1)
    kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
    initrd (hd1,1)/boot/initrd

#-------- failsafe--- A -----------#
title Failsafe - sda
    root (hd0,1)
    kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd (hd0,1)/boot/initrd

#-------- failsafe--- B -----------#
title Failsafe - sdb
    root (hd1,1)
    kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd (hd1,1)/boot/initrd

Verhalten dieser Konfiguration bei Kernelupdate

Jetzt gab es doch noch den lange ersehnten Kernelupdate, um diese obrige Konfiguration einmal bei einem Kernelupdate genau zu verfolgen.
Der Update wurde mit Yast durchgeführt.

• Es gab während dieses Kernelupdates sowie vieler anderer Updates keinerlei Probleme
• erwartungsgemäß wurde eine für Raid sauber funktionierende initrd erstellt
• ein Grub-Update war nicht dabei, den hätte die Konfiguration wohl auch nicht schadlos überstanden. (Vielleicht, ehr jedoch unwahrscheinlich, kommt ja mal irgendwann ein solcher, dann werde ich das auch mal testen.)
• in der /boot/grub/menu.lst gab es von Yast folgende Änderungen.

LINUX:/boot/grub # diff menu.lst.raid menu.lst
0a1
> # Modified by YaST2. Last modification on Mon Jun 23 20:48:29 CEST 2008
6a8,19
> ###Don't change this comment - YaST2 identifier: Original name: linux###
> title openSUSE 10.3 - 2.6.22.18-0.2
>     root (hd0,1)
>     kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=0x317 acpi=force noresume splash=silent showopts
>     initrd /boot/initrd-2.6.22.18-0.2-default
> 
> ###Don't change this comment - YaST2 identifier: Original name: failsafe###
> title Failsafe -- openSUSE 10.3 - 2.6.22.18-0.2
>     root (hd0,1)
>     kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
>     initrd /boot/initrd-2.6.22.18-0.2-default
> 
29a43,47
> 
> ###Don't change this comment - YaST2 identifier: Original name: floppy###
> title Diskette
>     rootnoverify (hd0,1)
>     chainloader (fd0)+1

• Yast hat also an den von mir gemachten Einträgen nichts geändert, sondern nur 3 Menü-Einträge neu dazu gesetzt. Die ersten beiden an den Anfang der Datei und die floppy ans Ende.
• mit Ausnahme des Kernel- und Initrd-Namens hat Yast dabei die Bootparameter aus der manuelle gemachten Konfiguration komplett übernommen.
• Alle so in der Datei menu.lst stehenden Einträge waren nach dem Update problemlos bootbar.
• Negativ ist aufgefallen, dass die menu.lst die vor dem Update aktiv war, hinterher komplett verschwunden war, und die menu.lst.old schon 2 der 3 von Yast getätigten Einträge beinhaltete. Es wurde also die menu.lst während des Updates 2 Mal verändert.

Hinweis:

Um also wieder in den Genuss der vollen urspünglichen Raidabsicherung des Bootprozesses zu gelangen, müssen die ersten beiden von Yast gemachten Einträge wieder entfernt werden, oder die default und fallback Optionen entsprechend geändert werden.

Robi 22:00, 23. Jun. 2008 (CEST)

---

Erfahrung mit openSUSE 11.0

Herzlichen Dank für dieses wunderbare "HOWTO".

Falls es von Interesse ist: Unter openSUSE 11.0 funktioniert es wie beschrieben. Den Abschnitt "Anlegen einer identischen Partitionstabelle" habe ich nicht vollzogen, doch glaube ich nicht, daß unter 11.0 etwas anders wäre. "boot.md" habe ich wie beschrieben aktiviert. Irgendwelche aufgehenden KDE-Fenster gab es nicht. ".../disc/by-id/..." hat den Vorteil, eine Platte oder Partition zweifelsfrei zu identifizieren, aber "dev/sdb1" usw. funktioniert genauso. An eine Warnung von "mkinitrd" am Schluß des ersten Teils kann ich mich nicht erinnern. Zu den erwähnten Problemen hinsichtlich der Konbination von "gespiegeltem Swap" und "Suspend to disk" kann ich nichts sagen, da meine SWAP-Partition nicht gespiegelt wird. Zum Beenden der "grub-shell" habe ich auf Verdacht "quit" probiert, und das hat funktioniert. Zum Aktivieren der Systemmail reicht die im "HOWTO" beschriebene Vorgangsweise (beim normalen Benutzer muß im YaST natürlich "Systemmail empfangen" angekreuzt sein), die in einem anderen Artikel "Grub, Raid1 Ausfallsicherheit" angeführten zusätzlichen Postfix-Aktivitäten sind nicht erforderlich. Nachdem "/dev/md0" eine eindeutige Identifikation ist (im Gegensatz zu "/dev/sda1"), sehe ich hier keine Notwendigkeit zu einer ".../disc/by-id/..."-Angabe.

Ein Flüchtigkeitsfehler: Unter "Herstellung der Spiegelung" steht "cat mdstat" statt richtig "cat /proc/mdstat".

Ein Nachtrag: Sofern "powersave" installiert ist, kann alternativ oder zusätzlich zum e-mail auch eine POPUP-Nachricht erfolgen. In der Datei "mdadm.conf" ist eine Zeile

  PROGRAM /Pfad/zum/Programm

einzutragen, das Programm ist ein "shell script" mit dem Inhalt:

  #! /bin/sh

  /usr/lib/powersave/powersave-notify "<b>Your RAID1 drive is failing!</b><br>

  mdadm message: $1 $2 $3"

Zwischen den Anführungszeichen kann beliebiger Text stehen, wichtig sind hier die Platzhalter $1, $2 und $3.

M.f.G. Josef