Mailinglist Archive: opensuse-de (842 mails)

< Previous Next >
Re: Multiboot-Vorgang beeinträchtigt durch eSATA-Platte
Hallo,

Ich fasse die Mails mal wieder zusammen ...

Am Sat, 19 Feb 2011, Thomas Michalka schrieb:
David Haller schrieb:
Am Fri, 18 Feb 2011, Thomas Michalka schrieb:
[..]
Wenn beim Booten schon die eSATA-Platte im Rechner steckt, dann kann ich
durch Auswahl das erste eingetragene System (hd0,2) von der SSD booten,
nicht aber die Systeme von der HDD (hd1,X). Ohne die eSATA-Platte geht
das aber! Die GRUB-Fehlermeldung lautet ungefähr so:

"(hd1,8) Error 22: Partition not found"

Noch eine kleine Ergänzung: Diese Meldung kommt nur, wenn man ein System
auf einer Partition wählt, die es auf der dazwischen gemogelten
eSATA-Platte nicht gibt. Im Falle von (hd1,2) habe ich folgende Meldung:

"(hd1,2) Error 13: Invalid or unsupported executable format"

Einfache Erklärung: Auf dieser _existierenden_ dritten Partition der
eSATA-Platte gibt es keinen GRUB im Boot-Sektor, weshalb der ladende
GRUB kein ausführbares Format erkennt. Im Grunde die gleiche Ursache.

Korrekt erkannt :)

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

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}.

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.

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.

[..]
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.

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

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.

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!

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' ;)

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?

Nein:
http://www.gnu.org/software/grub/manual/grub.html#Device-map

Leider heißt es:
"Unfortunately, even OS device names are not always stable. Modern
versions of the Linux kernel may probe drives in a different order from
boot to boot, [...]. As a result, the device map file required frequent
editing on some systems."

Letzteres wohl nur, wenn man einen GRUB installieren will.

Eben.

Aber immerhin:
"GRUB avoids this problem nowadays by using UUIDs or file system labels
when generating grub.cfg, and we advise that you do the same for any
custom menu entries you write."

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.

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.

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 :)

-dnh

--
BE MAD! IT HELPS!
--
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

< Previous Next >
Follow Ups