Mailinglist Archive: opensuse-de (842 mails)

[David Haller <dnh@xxxxxxxxxxxx>]

Hallo,

Am Mon, 21 Feb 2011, Thomas Michalka schrieb:
> David Haller schrieb:
[..]
> > 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.

Genau ;) Ob das klappt kann ich nicht vorhersagen. Es erstmal zu
probieren braucht ja nur einen Reboot ;)

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

Achso, by-path hab ich noch vergessen, das ist evtl. grad für die
Systemplatte interessant, ich hab hier z.B. alles _außer_ der
Systemplatte "by-label", die Systemplatte als /dev/sda (menu.lst,
root= Kernel-Parameter, fstab). Grund (hat sich schon bewährt): Ich
kann die Installation(en) einfach auf ne neue Festplatte umziehen, und
muß nur dafür sorgen, das die Systemplatte eben am SATA0 des ersten
Controllers hängt, mit SATA ist umkabeln ja kein Problem mehr.

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

Jep :) Z.Z. hier halt in der Variante daß MBR-Grub == SUSE-Grub, wobei
letzterer aber zusätzlich auch in der SUSE-/-Partition installiert ist
(und im Gentoo-Grub hab ich da wiederum einen chainloader):

==== /boot/grub/menu.lst für SUSE/MBR-Grub ===
default 0
timeout 8

title openSUSE 11.2 - 2.6.31.14-0.6
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.31.14-0.6-default root=/dev/sda6 noresume 
splash=native showopts edd=off pcsp=enable=1 elevator=anticipatory vga=normal
    initrd /boot/initrd-2.6.31.14-0.6-default

title=Gentoo Linux (2.6.31-gentoo-r10) [own initrd]
  root (hd0,2)
  kernel /boot/kernel root=/dev/ram0 real_root=/dev/sda3 splash=native vga=791 
init=/linuxrc ramdisk=8192
  initrd /boot/initrd-2.6.31-dnh2.cpio.gz

title Gentoo GRUB
  chainloader (hd0,2)+1

[.. diverse failsafe / backup Einträge ..]
==== /Gentoo/boot/grub/menu.lst (Gentoo-GRUB in /dev/sda3 ====
default 0
timeout 8

title openSUSE
  root (hd0,5)
  kernel /boot/vmlinuz root=/dev/disk/by-label/SUSE_ROOT noresume splash=native 
showopts edd=off vga=795
  initrd /boot/initrd

title=Gentoo Linux (2.6.31-gentoo-r10) [own initrd]
  root (hd0,2)
  kernel /boot/kernel root=/dev/ram0 real_root=/dev/sda3 splash=native vga=791 
init=/linuxrc ramdisk=8192
  initrd /boot/initrd-2.6.31-dnh2.cpio.gz

title openSUSE GRUB
  chainloader (hd0,5)+1

[.. diverse failsafe / backup Einträge ..]
====

Ich denke, so wird die Idee noch klarer ;)

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

*hihi*

Achso, ich hab da keinerlei Grafikgedöns (wozu??), nur Schwarz auf
Weiß (s.o.), da passen locker 8 Einträge hin.

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

Seltsam (daß es da kein [AHCI] oder [RAID] gibt).

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

s.u.

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

Das "Spread Spectrum" bezieht sich AFAIK auf die Art, wie die
SATA-Übertragung auf die Frequenzen verteilt wird um Störungen zu
vermindern. Siehe http://en.wikipedia.org/wiki/Spread_Spectrum.

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

Ok.

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

Teste das mal wenn du mit eSATA dran bootest und ins BIOS gehst. Ah,
könnte evtl. auch als "Removable Device" o.ä. in ner anderen Rubrik
(also nicht unter "Hard Disk Drives") auftauchen. Jedenfalls müßte daß
die Stelle sein, an der du drehen kannst.

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

Genau.

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

Naja, nicht elendslahm. Und ja, ...

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

AFAIR war da mal was in nem Plattenkarusell ;)

> 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

Hast du hier mit eSATA dran gebootet oder erst anschließen angestöpselt?

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

Das sieht hingegen wiederum so aus, als würde es nicht am BIOS liegen,
denn dann müßte die eSATA /dev/sda bekommen. Zeig mal (per PM /
paste.opensuse.org), ein 'lsmod' mit eSATA, im Idealfall auch mal wenn
du die eSATA erst nach dem booten anschließt.

> 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?

Ich glaube eher leider nicht. Probier's aber (bzw. vergleiche lsscsi
wenn du mit eSATA bootest mit nachträglich angesteckt).

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

Liegt vermutlich an der device.map, mit der dein Grub installiert
wurde. Und daran, daß du von SSD bootest (-> BIOS Bootreihenfolge!)
und üblicherweise macht das BIOS das Boot-Device zum BIOS-INT13 Gerät
0x80 was eben genau '(hd0)' beim Grub entspricht. Hab ich zuletzt
gemerkt, als ich mal von ner USB-Platte gebootet habe (da war die dann
auf einmal /dev/sda). Wie das BIOS dann die restlichen Sachen
durcheinanderwürfelt mußt du schauen ...

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

lsmod ;) Wenn da nix auftaucht ist's ahci (der ist fest im Kernel,
sata_nv aber nicht).

> > > 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 !!!)
[..]
> > 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)?

Nein. Grub liest bei der Installation die device.map und nimmt so ein
Mapping von /dev/sd* auf BIOS-Devices (hdX) vor. AFAIK wird nur dieses
Mapping (BIOS- zu Grub-Device) und auf welcher Platte+Partition die
menu.lst liegt mit "installiert", d.h. in den (M)BR bzw. den
darauffolgenden Teil von Grub (stage1.5 mit den Dateisystemtreibern)
geschrieben. Den ganzen Rest (kernel, Parameter, initrd usw.) liest
Grub dann schon aus der menu.lst, deswegen muß man Grub ja auch nicht
installieren, wenn man die menu.lst ändert. Aber wenn sich der Ort der
menu.lst ändert (z.B. weil man /boot auf ne eigene Partition auslagern
will oder von so einer auf die /-Partition holt).

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

s.o. AFAIK verwendet Grub im Stage 1 und 1.5 den BIOS INT13(e) Befehl,
d.h. die Platten werden über feste Nummern (Diskette: 0x00 und 0x01,
Festplatten 0x80 ..) angesprochen. In Assembler sieht das in DOS
debug.com so aus:

C:> debug
-a100                       ## DEBUG: assemble ab Adr. 0x0100
[SEG]:0100 mov ax,0201      ## 0x02 = read, 0x01 = Anz. Sektoren
[SEG]:0103 mov bx,1000      ## Zieladresse im Speicher für Sektor
[SEG]:0106 mov cx,0001      ## CS der CHS Adresse (10+6 bit!)
[SEG]:0109 mov dx,0080      ## 0x00 = Head (CHS), 0x80 = erste Festplatte!
[SEG]:010C int 13           ## INT13 BIOS-Funktion aufrufen
[SEG]:010E                  ## 
-g100,10e                   ## DEBUG: :0100 bis :010e ausführen
[..]
-d11be l42                  ## DEBUG: display 0x42 Bytes ab Adr. 0x11be

Das würde z.B. den MBR lesen und die Partitionstabelle (DOS-Schema,
nicht GPT) anzeigen. Quelle: c't 5/97, Seite 188.

Hm. Muß ich mal in ner VM wieder ausprobieren ;)

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

Es ist auch nicht einfach, und je nach BIOS ...

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

Nein. --recheck erzeugt nur erst die device.map neu. Kannst du machen,
wenn du grub-install.unsupported --recheck /dev/sda verwendest. Und
dann die device.map angucken / korrigieren und dann nochmal
grub-install ohne --recheck aufrufen.

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

Ist sie immer :)

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

Eher damit, wie grub die Devices vom BIOS serviert bekommt und ob das
dann zur device.map _bei der Installation von Grub_ in den BR noch
zusammenpasst. Eigentlich sollte sich die eSATA nicht zwischen SSD und
HDD drängeln, wenn du immer von SSD bootest. Kannst du nochmal die
Boot-Reihenfolge im BIOS angucken?

-dnh

-- 
Math problems?  Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
--
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