[solved]Installation von openSuSE 11.4 auf SW Raid unmöglich

[framp]

openSusE ist leider kein rolling release Also muss man immer mal wieder auf das neueste Release umstellen. Ich mache das immer so dass ich keinen Update mache sondern eine neue Version auf einer neuen Partition installiere. Bislange bin ich damit immer gut gefahren. Nur habe ich mittlerweile ein SW RAID. Wenn ich nun die normale openSuSE Installation von DVD boote bietet mir der Installer leider keine Möglichkeit an, das neue OS 11.4 auf md8 zu installieren sondern ich muss /dev/sda8 bzw /dev/sdb8 auswählen. Übersehe ich was oder supportet SuSE wirkliche keine Installation auf einem SW RAID?
Alternativ kann ich natürlich auf /dev/sda8 installieren und /dev/sda3 für swap benutzen und dann wieder die beiden RAIDs synchronisieren ... ist für mich aber eine Krücke. Übersehe ich da was oder ist es tatsächlich so?

 

[josef-wien]

Meine vorhandenen RAID werden von der Installationsroutine einwandfrei erkannt.

Wenn md8 noch nicht existiert, dann mußt Du im unteren Teil auf eine passende Auswahl-Fläche klicken und in der manuellen Partitionierung das RAID erstellen.

 

[framp]

... Meine vorhandenen RAID werden von der Installationsroutine einwandfrei erkannt. ...

Das Erkennen der RAID Partisions ist auch OK. Allerdings liegt die Konfiguration dre Mountpoints etwas tiefer im menu als bei den Disks. Deshalb habe ich es nicht gefunden ps: Die openSuSE 11.4 läuft nun auf md8. Allerdings musste ich nach dem Reboot erst händisch im grub den root Eintrag ändern, denn die SuSEInstallation hat mir (hd1,7) reingeschrieben obwohl es (hd0,7) sein muss. Als ich dann den desktop Kernel installiert habe wurde der auch wieder per hd1,7 in die menu.lst eingetragen :???:
Weiss jemand wo sich openSuSE merkt welches die root Partition ist ? Ist lästig die menu.lst immer händisch nach einem kernel Update ändern zu müssen.

 

[spoensche]

Sieh dir mal /etc/sysconfig/boot und /etc/sysconfig/bootloader an.

 

[framp]

Interessanter Hinweis. Die Dateien kannte ich noch nicht. Aber dort kann ich resume Dateien definieren. Mein Problem ist dass SuSe bei einem neuen Kernel das falsche drive in die menu.lst einträgt :???:

 

[josef-wien]

Schau Dir einmal /etc/grub.conf und die Festplattenreihenfolge in /boot/grub/device.map an.

Nur zur Sicherheit kommt die Frage, ob es auch mit (hd1,7) funktioniert hat.

 

[framp]

Schau Dir einmal /etc/grub.conf

setup --stage2=/boot/grub/stage2 --force-lba (hd0,0) (hd0,4)
setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,4)
quit

und die Festplattenreihenfolge in /boot/grub/device.map an.

(hd0) /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z426352
(hd1) /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z351168
(hd2) /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579[/quote]

Nur zur Sicherheit kommt die Frage, ob es auch mit (hd1,7) funktioniert hat.

Nein, deshalb musst ich ja im grub von 1 auf 0 umstellen.
Interessant finde ich dass in der map noch eine Platte auftaucht die ich schon längst entfernt habe. Es gibt nur noch 2 (RAID) Platten - alle von Samsung

 

[josef-wien]

setup --stage2=/boot/grub/stage2 --force-lba (hd0,0) (hd0,4)
setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,4)

Wie spielt die Partition (hd0,4) mit? Hast Du eine eigene Boot-Partition? Über welchen GRUB startest Du Dein auf /dev/md8 installiertes System? Von welcher Partition stammt die Datei /boot/grub/device.map?

Nein, deshalb musst ich ja im grub von 1 auf 0 umstellen.

Ist mit Deinem RAID etwas nicht in Ordnung?

mdadm --detail /dev/md8

Es gibt nur noch 2 (RAID) Platten

Da will ich mehr wissen:

hwinfo --disk | egrep "Device Files:|BIOS id:"

 

[framp]

ps: ps: ps: Deine Frage nach der separaten Bootpartition ps: ps: ps:
Die habe ich auf dem alten openSuSE 11.2 angelegt /dev/md7 ist root, /dev/md5 ist boot und /dev/md6 ist swap). Auf dem neuen openSuSE 11.4 benutze ich keine separate Bootpartition, also /dev/md8 ist root und boot und /dev/md6 ist swap. D.h. die o.g. Ausgaben sind vom falschen System. ps:

Anbei jetzt die Ausgaben vom openSuSE 11.4. Das RAID ist OK.

obelix:~ # hwinfo --disk | egrep "Device Files:|BIOS id:"
  Device Files: /dev/sda, /dev/block/8:0, /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z426352, /dev/disk/by-id/scsi-SATA_SAMSUNG_HD103SJS246J90Z426352, /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
  Device Files: /dev/sdb, /dev/block/8:16, /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z351168, /dev/disk/by-id/scsi-SATA_SAMSUNG_HD103SJS246J90Z351168, /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0, /dev/disk/by-id/edd-int13_dev80
  BIOS id: 0x80

obelix:~ # mdadm --detail /dev/md8
/dev/md8:
        Version : 0.90
  Creation Time : Tue Jun 15 21:24:34 2010
     Raid Level : raid1
     Array Size : 20972736 (20.00 GiB 21.48 GB)
  Used Dev Size : 20972736 (20.00 GiB 21.48 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 8
    Persistence : Superblock is persistent

    Update Time : Mon Jun 13 17:15:35 2011
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 781ba76b:3aaf8a4a:9547e4c9:010b9f63 (local to host obelix)
         Events : 0.1446

    Number   Major   Minor   RaidDevice State
       0       8        8        0      active sync   /dev/sda8
       1       8       24        1      active sync   /dev/sdb8

obelix:~ # cat /etc/grub.conf
setup --stage2=/boot/grub/stage2 --force-lba (hd1) (hd1,7)
setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,7)
quit

obelix:~ # cat /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z351168
(hd1)   /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z426352

 

[josef-wien]

Ich würde einmal in /etc/grub.conf die Reihenfolge der beiden Zeilen ändern. Ob es etwas nützt, wird das nächste Kernel-Update zeigen, etwas anderes fällt mir nicht ein.

/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z426352 erhält vom BIOS keine BIOS-ID, da scheint wieder ein interessantes BIOS auf die Menschheit losgelassen worden zu sein. Damit gibt es aber keine (hd1), und GRUB kann somit von (hd1,7) kernel und initrd nicht auf die Reise schicken.

Startet Dein System, wenn Du im BIOS die Boot-Reihenfolge umstellst? Wenn es startet, wäre interessant, wie das BIOS in diesem Fall bei der Vergabe der BIOS-ID vorgeht.

 

[framp]

Ich würde einmal in /etc/grub.conf die Reihenfolge der beiden Zeilen ändern. Ob es etwas nützt, wird das nächste Kernel-Update zeigen, etwas anderes fällt mir nicht ein.

Nachdem ich den Inhalt gesehen habe kam mir auch die Idee. Ich werde das ändern und mal den nächsten Kernel Update abwarten ...

/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90Z426352 erhält vom BIOS keine BIOS-ID, da scheint wieder ein interessantes BIOS auf die Menschheit losgelassen worden zu sein. Damit gibt es aber keine (hd1), und GRUB kann somit von (hd1,7) kernel und initrd nicht auf die Reise schicken.

Startet Dein System, wenn Du im BIOS die Boot-Reihenfolge umstellst? Wenn es startet, wäre interessant, wie das BIOS in diesem Fall bei der Vergabe der BIOS-ID vorgeht.

Mit dem interessanten BIOS hast Du wohl Recht. Ist eines der Ersten mit 4*OnBoard sata - parallel aber auch noch 4*IDE - das sieht im BIOS ziemlich grausig aus. Der Witz ist der, dass das BIOS mir nur eine der beiden SATA Platten anzeigt - ich kann also gar nicht die Bootplatte im BIOS wechseln :-(