Mailinglist Archive: opensuse-de (842 mails)

[Thomas Michalka <Thomas.Michalka@xxxxxx>]

David Haller schrieb:
> Hallo,
>
> Ich fasse die Mails mal wieder zusammen ...
>
> > > > Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen
> > > > ausblenden kann, so dass GRUB es seiner Geräteliste übergeht?
> > > > GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben.
> > > Nein. Du könntest aber '(hd2,N)' Einträge ergänzen.
> > Habe ich auch schon daran gedacht, und für den Falle der eingesteckten
> > eSATA-Platte funktioniert das als Workaround auch, aber es kommt eben
> > auch vor, dass die eSATA-Platte beim Booten nicht eingesteckt ist. In
> > dem Fall findet GRUB keine Partitionen (hd2,N), weil dann (hd1) die
> > höchste Gerätenummer ist.
>
> Ich meinte folgendes, wenn du z.B. meist ohne eSATA bootest:
>
> SSD-Eintrag
> hd1,6 Eintrag
> hd1,7 Eintrag
> hd2,6 Eintrag
> hd2,7 Eintrag

Klick! Zusätzliche Einträge, die man ja auch entsprechend markieren
("plus eSATA" o.ä.) kann.

> D.h. im selteneren Fall mußt du halt weiter nach unten, aber es
> sollten sich alle booten lassen. Siehe dazu auch unten
> bzgl. device.map. Für die 'root=' Kernel-Parameter solltest du von
> sdXY unabhängige Varianten wählen, also /dev/disk/by-{label,id,uuid}.

Das war mir schon bei der Installation sympathischer, was dann auch für
die /etc/fstab gilt, die somit ebenfalls 'transportabler' ist.

> > > Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die
> > > Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst
> > > kopiert) und danach noch die Chainloader Einträge um ggfs. den
> > > Distri-Grub zu starten.
> > Damit du hin- und wieder doch noch einen anderen Distri-Kernel auswählen
> > kannst.
>
> Nein, vielmehr, damit ich dann z.B. von DVD booten kann, und "per
> Hand" und chainloader den Grub in der root-Partition einer Distri
> starten kann, falls der im MBR mal nicht will. Und den Distri-Grub hab
> ich z.B. von Yast erstellen lassen, der im MBR wird (nach Vorlage im
> Distri-Grub) manuell gepflegt. Äh, so die Grundidee. Praktisch ist im
> Grub jetzt der SUSE-Grub, mit Eintrag für Gentoo, der Gentoo-Grub ist
> in dessen /-Partition und diente als Vorlage für den Grub im MBR.

Eine nette Idee.

> > Wenn ich also einen bestimmten Kernel einer Distri sowieso bevorzugt
> > starte, könnte ich den also auch in die menu.lst des MBR-GRUB schreiben
> > und somit in der Regel einen Auswahlvorgang sparen.
>
> Genau. Und den "chainloader" Eintrag eben unten noch drinlassen, falls
> du mal was verbastelst und nicht direkt in der am grub-prompt
> reparieren kannst.
>
> > Hmmm, wenn nur alle Distris auf der SSD Platz hätten (wollte ihr
> > deswegen nur die zwei wichtigsten aufladen), dann hätte ich dieses
> > Problem nicht (aber auch nix Neues gelernt). Ein Workaround dafür
> > wäre natürlich auch, nach der GRUB-Fehlermeldung den Affengriff
> > machen und inzwischen die eSATA-Platte rausziehen. Könnte nur ein
> > bisschen arg verschleißend auf die Stecker wirken.
>
> s.o. Die paar Tastendrücke, um den hd2 statt hd1 Eintrag auszuwählen
> dürften da nervenschonender sein.

Wow, werde wohl im Boot-Menü das erste Mal scrollen müssen ;-)

> > > > > Guck im BIOS nach der Bootreihenfolge der SATA-Controller.
> > > > Die habe ich so eingestellt, dass der MBR der SSD geladen und gestartet
> > > > wird. Dieser GRUB startet dann je nach Auswahl einen weiteren GRUB in
> > > > einem Boot-Sektor, der wiederum dann einen Kernel startet.
> > > Und die Controller-Reihenfolge?
> > Seltsamerweise sehe ich den JMicron-Controller im BIOS-Setup selber
> > nicht, nur als Meldung beim Booten.

Sorry, da hat mir die mangelhafte Erinnerung einen Streich gespielt,
denn man kann ihn aktivieren/deaktivieren mit [DISABLED][IDE], wie mir
das Handbuch zur BIOS-Konfiguration eben sagt. Aber mehr leider nicht.

Zur Reihenfolge der Controller SATA (Anschlüsse 1 - 4) und JMicron
(eSATA) sehe ich im BIOS leider keine Möglichkeit.

Für SATA gibt es in der Chipsatz-Konfiguration noch die Option [SPREAD
SPECTRUM], was immer das ist, leider nicht erläutert im Handbuch. Hat
vielleicht was mit HyperTransport zu tun, weil es in dem Menu ansonsten
darum zu gehen scheint.

> Und sonst irgendwas mit "SATA0/SATA1" o.ä.? Wo man evtl. auch den
> SATA-Modus umstellen kann (IDE/AHCI)?

Leider nix. In der "Onboard Device Configuration" gibt es den "IDE
Function Setup", der für den PATA-Anschluss (meine beiden IDE-DVD-Lw)
zuständig ist. Dann ist da noch die "Serial ATA Configuration", wo ich
nur den Controller an- und abschalten und ansonsten nur noch RAID für
die einzelnen SATA-Anschlüsse konfigurieren kann.


> > > Welches MoBo?
> > Ein Asus M2N-TE (hat es frei zu kaufen wohl nie gegeben, da laut Targa
> > speziell angefertigt für Targa).
>
> Kannst du mal auf asus.de gucken, welches Board deinem am ehesten
> ähnelt? Das M2N-SLI Deluxe sollte zumindest mal die gleichen
> Controller haben, da guck ich mal ins (engl.) Handbuch ... Guck im
> Bios unter "Boot" -> "Hard Disk Drives". Im Idealfall kannst du da
> umsortieren.

Hier habe ich die SSD an erster und die HDD an zweiter Stelle. Falls ich
mich richtig erinnere, steht die eSATA-Platte an dritter Stelle, wenn
sie eingebaut ist. Aber vielleicht steht sie auch gar nicht drin. Das
sehe ich mir an und liefere die Info noch nach.

> > > Und an welchem Controller hängt die SSD und die externe Platte?
> > SSD: SATA-1, HDD: SATA-2, beide onboard am NVIDIA nForce 550 MCP.
> > eSATA: JMicron JMB 363 Extra-Chip, aber auch onboard.
>
> Da ahci fest im Kernel ist und du bei eSATA zwingend ahci brauchst
> könntest du nur die Platten am MCP55 im IDE-Modus mit dem sata_nv
> Treiber verwenden -- aber gerade bei SSD willst du das nicht!

Wenn ich den Wikipedia-Artikel zu AHCI richtig verstehe, ist nur mit
AHCI-Treibern NCQ möglich. Was hat das mit der SSD zu tun? Naja, würde
wohl elendslangsam werden, wie auch eine moderne SATA-HDD (erinnere mich
da an ein c't-Plattenkarussell).

NB: hat das auch irgendwas mit ATA-Trim zu tun und mit wiper.sh aus dem
hdparm-Paket? (Habe noch Kernel 2.6.25, wohl ohne TRIM Support.) Habe
allerdings noch recht viel Platz auf meiner SSD unpartitioniert.


> Also, s.o.: BIOS oder Grub.
>
> > > Aber die Reihenfolge von sda-sdk wird gemäß SCSI-ID vergeben, und die
> > > wiederum hängt von der Reihenfolge der Controller (und Module) ab.
> > >
> > > Onboard1 (SB710):
> > > [0:0:0:0]    disk    ATA        /dev/sda
> [..]
> > Wie bekomme ich dieses schöne Listing gleich wieder?
>
> Sehr überraschend mit 'lsscsi' ;)

Habe mich dunkel erinnert, aber nicht genau und weil lspci in /sbin
steht, nur mit "ls /sbin/ls* nachgesehen. Hier also meine SCSI-Geräte:

rechner:~ # lsscsi
[3:0:0:0]    disk    ATA      WDC WD5000BEVT-0 01.0  /dev/sdg  (eSATA)
[4:0:0:0]    disk    ATA      OCZ-VERTEX2 3.5  1.22  /dev/sda  (SSD)
[5:0:0:0]    disk    ATA      ST3500630AS      3.AA  /dev/sdb  (HDD)
[8:0:0:0]    cd/dvd  TOSHIBA  DVD/HD  SD-H802A TS06  -
[8:0:1:0]    cd/dvd  Optiarc  DVD RW AD-7191A  1.02  -
[10:0:0:0]   disk    Generic  STORAGE DEVICE   9602  /dev/sdc
[10:0:0:1]   disk    Generic  STORAGE DEVICE   9602  /dev/sdd
[10:0:0:2]   disk    Generic  STORAGE DEVICE   9602  /dev/sde
[10:0:0:3]   disk    Generic  STORAGE DEVICE   9602  /dev/sdf

Wenn ich die eSATA-Platte entferne fehlt kurz darauf nur der Eintrag
[3:0:0:0], um wieder da zu sein, wenn sie wieder drinsteckt. Sie wird
also nicht einfach angereiht, sonst würde ich [6:0:0:0] oder [7:0:0:0]
erwarten.
Kann hier die niedrigste SCSI-Nummer der eSATA-Platte für GRUB bedeuten,
dass der JMC 363 immer ganz vorne steht (trotz "Boot Device Priority"
für SSD und Hard Disk Drives Reihenfolge SSD, HDD, eSATA-Platte) und
daher in der menu.lst für die SSD immer (hd1), für die HDD immer (hd2)
einzutragen wäre?
Dann verstünde ich allerdings nicht, warum ich mit "chainloader
(hd0,2)+1" aus dem MBR der SSD _immer_ die Distri auf der SSD booten
kann, egal ob die eSATA-Platte drin ist oder nicht. Nur die Distris auf
der HDD kann ich ja mal booten oder nicht.

> > user@rechner:~> sudo /sbin/lspci | grep 'ATA\|IDE'
> > 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
> > 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
> > 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
>
> Äh, hast du die Onboard SATA im IDE oder AHCI Modus?

Da nichts im BIOS einzustellen ist (s.o.), tippe ich auf AHCI.

> > Das hat Boris wohl gemeint, das ich tun soll, gilt aber für GRUB 1.99.
> > Nur schade, dass /dev/disk/by-id/... nicht erwähnt werden.
>
> Bei beiden mappt Grub bei der Installation die /dev/* auf (hdX,Y).
>
> > > Auch Grub2 braucht erstmal noch das BIOS. Wie schaut deine device.map
> > > denn eigentlich aus?
> > (fd0)   /dev/fd0  (Controller gibt es wohl, aber kein Lw)
> > (hd0)   /dev/sda  (war die eSATA-Platte !!!)
> > (hd1)   /dev/sdb  (war die SDD !!!)
> > (hd2)   /dev/sdg  (war die HDD !!!)
>
> Hm. Zeig mal (lsscsi, Modellnamen kannst du kürzen/ersetzen) wie's
> aktuell mit und ohne eSATA aussieht, denn daß die HDD als /dev/sdg
> auftauchte spräche dafür, daß die an nem anderen Controller hängt.

Ausgabe von lsscsi siehe oben. Es ist aber doch anders und wird auch,
wie ich in einem früheren Posting etwas unauffällig erwähnte, durch eine
Anzeige des JMicron-Controllers beim Booten erwähnt: da steht ohne
eSATA-Platte nix drin, mit der eSATA-Platte wird der Modellname der
WDC-Platte blau angezeigt.
Warum in der device.map  die HDD (!) als /dev/sdg steht, ist mir jetzt
auch nicht klar. Vielleicht resultiert das aus einer etwas eigenwilligen
Vergabe der Gerätebezeichner unter der SysRescueCD -- muss ich beim
nächsten Booten auch noch ausprobieren.


> Und dann basteln wir dir ne device.map, mit /dev/disk/by-* statt
> /dev/sdX. Evtl. klappt es, wenn du manuell dort die eSATA als hd2
> definierst.

Das probiere ich beim nächsten Booten auch gleich aus (muss vorher aber
ein paar dringende Arbeiten erledigen).
Hmm, aber jetzt mal überlegen: das hieße doch, dass beim Schreiben des
GRUB in den MBR schon die Gerätenummern (hdX) in den MBR mit eingetragen
würden. Wozu muss er dann die menu.lst lesen? Auf dem Lesen der menu.lst
beruhte doch Dein Vorschlag der zusätzlichen Einträge (hd2,Y) für den
Fall des Bootens mit eSATA-Platte.
Liest GRUB vor dem Booten auch die device.map, so dass diese zur
Boot-Zeit auch relevant ist (dachte immer, die braucht nur grub-install,
wenn man die üblichen Gerätebezeichner /dev/sdXy verwendet)?

Noch etwas, worüber ich nichts genaues gefunden habe: wie erhält GRUB
eigentlich die Infos über die Geräte? Durch Parameterübergabe beim Start
durch das BIOS, oder liest GRUB selber ein BIOS-Register, oder kann GRUB
die Gerätereihenfolge gar selber festlegen? Ich denke, das müsste ich
mal verstehen.

> > Allerdings hat und musste sie so aussehen, als ich mittels SysRescueCD
> > den GRUB im MBR und den Boot-Sektoren installiert habe, denn SysRescueCD
> > hatte anscheinend eigene Vorstellungen von der Zuordnung der Geräte zu
> > /dev/sdX (hier besonders für die HDD als 2. SATA-Platte).
>
> Ja, das kann wüst werden, wenn man mal hier und mal dort bootet.  Hat
> mit bei der Installation von Gentoo auf ner externen USB Platte auch
> einiges an Zeit gekostet, in der SUSE war's /dev/sdk, im BIOS von
> USB-gebootet war's dann IIRC /dev/sdg, weil die Controller in anderer
> Reihenfolge auftauchten ... Und wenn man es wie ich zu dem Zeitpunkt
> im anderen Rechner mit 11 Platten an 3 Controllern (Onboard,
> Steckkarte, USB) zu tun hat kann die Suche nach dem richtigen Device
> für Grub einiges an Zeit und Nerven kosten ;) Es hilft, wenn man weiß,
> wie Grub funktioniert :)

Ja eben, das scheint mir der springende Punkt zu sein! Ich dachte, das
hätte ich schon verstanden ... Aber wohl noch nicht tief genug, siehe
dazu meine Fragen oben.
Kurz zu grub-install[.unsupported] ([] bei oS): die Option --recheck
braucht man ja, damit man als Schreibziel für GRUB den
_aktuell_richtigen_ MBR (/dev/sdX) bzw. den _aktuell_richtigen_
Boot-Sektor (/dev/sdXy) angibt. Selbst wenn man später ein System von
(hd0,2) starten will, kann beim Schreiben des MBR das Ziel (hd1 <-->
/dev/sdb) sein. Dann wäre aber die device.map später für's Booten egal.

Also, ich glaube, dass für eine Lösung das Verständnis die
'Laufwerkswahrnehmung' durch GRUB (absichtlich etwas unbestimmt)
entscheidend ist, und wie diese evtl. mit den SCSI-Gerätenummern
zusammenhängt.


Gruß, Tom
-- 
Um die Liste abzubestellen, schicken Sie eine Mail an:
    opensuse-de+unsubscribe@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx