Habe folgende Vermutung: Grub orientiert sich an der Boot-Sequenz im Bios.
hd0 = 1.Boot-Platte, hd1= 2.Boot-Platte.

Partition     Linux-Device-Bezeichnung	    GRUB-Bezeichnung
Platte 1      /dev/sda	                    hd0              
Platte 2      /dev/sdb	                    hd1               

Die Tabelle im Wiki ist richtig für ein Standard-Bios. Allgemeingültig wäre:

Boot-Sequenz     GRUB-Bezeichnung
1.Boot-Platte    hd0
2.Boot-Platte    hd1

Hallo,

weißt du es oder ist es geraten?

Es erscheint mir unlogisch, aber wissen tue ich es auch nicht.

Unlogisch weil: ältere BIOS kenne nur teilweise nur C: (also die 1. HD) als HD, neben CDROM etc. natürlich. Trotzdem gibt es auch dort später sdb, sdc etc, wenn du die Platten drin hast. Daher vermute ich, dass es eher mit der Zahl der belegten Kanäle am HD-Controller zusammenhängt.

Vielleicht kommt ja noch ein Wissender hier vorbei.

Gruß, noisefloor

Wer kennt schon die Wahrheit?

Ich bin der Meinung, dass beide Varianten nicht wirklich immer richtig sind. Ein Dateil, dass ich immer wieder beobachte:

Je nachdem, ob Grub aus einer laufenden Linuxsitzung oder beim Booten direkt vom BIOS gestartet wird, erhält es die Informationen über die Plattensituation von verschiedenen "Lieferanten". Beim Start unter Linux - also z.b. auch bei der Grub-Installation - erhält Grub & Co die Information vom Kernel. Wenn Grub aber beim Booten startet, dann erhält es die Info direkt vom BIOS. Da kann es durchaus zu Differenzen kommen.

Ich habe hier z.B. ein System (2 Platten: IDE + SATA), dass abhängig von der Bootmethode die Platten anders anordnet. Folgendes passiert (wobei natürlich über den ganzen Vorgang im BIOS nichts verändert wird):

• Ich installiere per LiveCD ein Ubuntusystem. Installation läuft perfekt durch. Neustart

• Kein Grub startet. Mist, Grub kann also nur auf der falschen Platte sein.

• also flugs per LiveCD Grub auf die andere Platte (hd1!) installiert. Neustart

• Grub startet, jetzt stimmt allerdings die menu.lst noch nicht ganz. Ok, noch etwas Handarbeit.

Wie man sieht, ist die im BIOS eingestellte erste Bootplatte nicht hd0, sondern hd1. Jedenfalls dann, wenn von CD gestartet wird.

Ich kann hier nicht wirklich abschätzen, ob das BIOS oder der Kernel der "Schuldige" ist, habe aber eine Theorie: Wenn ich von einer LiveCD starte, dann schert sich mein BIOS einen Dreck um die eingestellte Plattenreihenfolge => Die Platten erscheinen bei der Installation von Grub in einer anderen Reihenfolge, als dann später beim "normalen" Systemstart.

Desweiteren habe ich nach "tausenden" von Grub-Problem-Beiträgen den Eindruck, dass die Regel "Xte Platte in der Bootreihenfolge => hd(X-1) oft bei IDE-SATA-Hybriden sowieso verkehrt ist. Sprich: Im BIOS sind die Platten beispielsweise in dieser Reihenfolge eingestellt:

1. Platte B, 2. Platte A.

Das System startet auch brav von Platte B, Grub bekommt vom BIOS aber folgende Information:

Platte B => (hd1) Platte A => (hd0)

Es kann auch sein, dass ich hier zwei Probleme sehe, wo vielleicht eigentich nur eines existiert. Fakt ist aber wohl: alles nicht so einfach...

hallo!,

ich weiß überhaupt gerade nicht, ob ich hier richtig bin, also falls nicht bitte ich um wegweisung! danke. in dem artikel steht unter 2.5.3 "linux" folgender eintrag:

title Zweitsystem - Kubuntu/OpenSuse/Fedora usw. root (hdX,Y) kernel /vmlinuz # plus optional Bootparameter initrd /initrd.img # plus optional Bootparameter boot

ich habe aber die erfahrung gemacht, dass mein zweitsystem nur dann von grub erkannt wird, wenn der eintrag folgendermaßen lautet:

title Zweitsystem - Kubuntu/OpenSuse/Fedora usw. root (hdX,Y) kernel /boot/vmlinuz # plus optional Bootparameter initrd /boot/initrd.img # plus optional Bootparameter boot

ist das nur ein schreibfehler?

danke, mathis

mathis schrieb:

in dem artikel steht unter 2.5.3 "linux" folgender eintrag:

title           Zweitsystem - Kubuntu/OpenSuse/Fedora usw.
root            (hdX,Y)
kernel          /vmlinuz              # plus optional Bootparameter
initrd          /initrd.img           # plus optional Bootparameter
boot

Und so ist es auch richtig. /vmlinuz und /initrd.img sind symbolische Links, die im Root der Rootpartition liegen, und immer auf den aktuellsten Treiber zeigen. In einem laufenden Linuxsystem funktioniert der Link immer. Bei der Verwendung in der menu.lst kommt es eigentlich nur dann zu Problemen, wenn eine separate Bootpartition verwendet wird. Dann liegen diese Links zum einen auf einer ganz anderen Partition, zum anderen zeigen sie noch ins Leere, da die boot-Partition zu diesem Zeitpunkt noch gar nicht in /boot eingehängt ist.

ich habe aber die erfahrung gemacht, dass mein zweitsystem nur dann von grub erkannt wird, wenn der eintrag folgendermaßen lautet:

title           Zweitsystem - Kubuntu/OpenSuse/Fedora usw.
root            (hdX,Y)
kernel          /boot/vmlinuz              # plus optional Bootparameter
initrd          /boot/initrd.img           # plus optional Bootparameter
boot

Wie diese Lösung funktionieren soll kann ich mir nicht erklären: Unter /boot/ liegen nämlich weder Links noch Kernel mit dem Namen 'vmlinuz'. Deine Lösung kann nur funktionieren, wenn man den konkreten Namen eines existierenden Kernels hernimmt, z.B. /boot/vmlinuz-2.6.24-16-generic
Dies jedoch entspricht der dann den Einträgen einer gewöhnlichen menu.lst, und hat denn Nachteil, dass diese Zeile dann eben nach jedem Kernelupdate des Zweitsystems händisch nachgebessert werden müßte.

Sollte man in der Einleitung dieses Artikels vielleicht den Satz update-grub liest auch manche Zeilen ein, die mit einer Raute beginnen. ein wenig präzisieren( sprich genau schreiben, dass bei allem, was in dem AUTOMAGIC-Block steht, ein ## als Kommentar gilt und dort die einfachen # quasi ignoriert werden)?

Hallo,

ja, mach mal.

Gruß, noisefloor

Doc_Symbiosis schrieb:

Sollte man in der Einleitung dieses Artikels vielleicht den Satz update-grub liest auch manche Zeilen ein, die mit einer Raute beginnen. ein wenig präzisieren( sprich genau schreiben, dass bei allem, was in dem AUTOMAGIC-Block steht, ein ## als Kommentar gilt und dort die einfachen # quasi ignoriert werden)?

Hmm, etwas weiter steht doch folgendes im Artikel:

Desweiteren muss die besondere Rolle des Kommentarzeichens # beachtet werden. Bei der menu.lst handelt es sich um eine Steuerdatei, die eigentlich nur von Grub gelesen wird. Grub ignoriert dabei Zeilen, die mit mindestens einem Kommentarzeichen beginnen. Im gerade beschriebenen inneren Bereich werden nun aber zusätzliche Parameter für das Hilfsprogramm update-grub gespeichert. Für Grub sind diese Parameter aber unverständlich. Damit nun keine Syntaxfehler auftreten wurde vereinbart, dass Parameter für update-grub im gekennzeichneten Bereich stehen müssen und jeweils mit einem einzelnen Kommentarzeichen beginnen. Tatsächliche Kommentare in diesem Bereich sollten dementsprechend mit mindestens zwei Kommentarzeichen beginnen.

Zusammenfassend gilt:

• Zeilen mit doppelten oder mehr Rauten ## sind immer Kommentare.

• Zeilen mit einer einfachen Raute # innerhalb des inneren Blocks sind Anweisungen für update-grub, wenn der Raute eines der Schlüsselworte alternative, altoptions, defoptions, groot, howmany, kopt, lockalternative, lockold, memtest86, nonaltoptions, recovery, savedefault, updatedefaultentry, xenhopt, xenkopt folgt.

• Sonstige Zeilen, die mit einer einfachen Raute # beginnen, sind Kommentare.

• Zeilen ohne Raute sind Optionen für GRUB selber.

Fehlt da was?

gabi schrieb:

Habe folgende Vermutung: Grub orientiert sich an der Boot-Sequenz im Bios.

Ja, das ist richtig so. Das liegt daran, dass GRUB im BIOS-Kontext läuft. D.h. GRUB muss mit allen Angaben des BIOS und auch mit dessen Limitierungen leben. Eine BIOS Limitierung, die man heute zuweilen noch antrifft, ist z.B. die, dass ein System nicht startet, wenn die Boot-Partition hinter der 136 GB-Grenze liegt. (Gilt nicht für ganz moderen BIOSs, aber bei 4-5 Jahre alten Rechnern kann man noch auf diese Grenze stoßen).

Erst wenn die Betriebssystem-Kernel geladen werden - also nach GRUB - wird eine vom OS eigene Treiberbasis zu Verfügung gestellt, die diese Limitierungen, dann überwinden kann.

hd0 = 1.Boot-Platte, hd1= 2.Boot-Platte.

Partition     Linux-Device-Bezeichnung	    GRUB-Bezeichnung
Platte 1      /dev/sda	                    hd0              
Platte 2      /dev/sdb	                    hd1               

Die Tabelle im Wiki ist richtig für ein Standard-Bios. Allgemeingültig wäre:

Boot-Sequenz     GRUB-Bezeichnung
1.Boot-Platte    hd0
2.Boot-Platte    hd1

Das ganze liegt am BIOS-Geräte-Mapping, was nur während des Startprozesses ersichtlich wird. Es geht so:

• Während des POST werden die Festplatten gemäß ihrer Anschlussreihenfolge am Host-Bus-Adapter mit einer BIOS-Device-ID nummeriert. Für Festplatten beginnt diese Nummerierung mit 80. Also die Platte an Anschluss 1 ist die 80, die an Anschluss 2 die 81 usw.

• Erst nach dem POST werden BIOS-Einstellungen im BIOS-Setup berücksichtigt, d.h. stellt man die Platte an Anschluss 2, als Startplatte ein, dann wird auf diese Platte nun die 80 gemappt.

Dieses Mapping findet also nur für die Startphase statt. Startet man die GRUB-Konsole, dann kann man die BIOS-Device-ID mittels "geometry" auslesen. Die 80 als Startplatte ist BIOS-historisch bedingt. Frührer konnte man nur von der ersten Festplatte booten - also der 80 - und gar keine andere Startplatte wählen. Als man das BIOS für das Booten von anderen Festplatten erweitert hat, hat man die 80 als Startkennung beibehalten und sich eben für das Mapping der ID entschieden.

In einem laufenden System - egal ob Festplatte oder Live-CD - ist das Mapping sozusagen nicht mehr aktiv. Die Festplatten tauchen nun wieder gemäß ihrer Reihenfolge am Host-Bus-Adapter auf. Ob das nun daran liegt, dass das System mit eigenen Treibern auf den Adapter zugreift, oder ob das BIOS die Platten tatsächlich nun wieder in dieser Reihenfolge an das System durchreicht, weiß ich auch nicht zu 100%.

Auf alle Fälle ist es so, dass eine im System gestartet GRUB-Shell nicht erkennt, welche Platte im BIOS als Startplatte eingestellt ist.

Da die GRUB-Installation während des Ubuntu-Setups in einem Live-System stattfindet, kommt es bei mehreren Festplatten so zu einer nicht richtigen Generierung der device.map. Diese - wird BTW nur für das GRUB-Setup verwendet - führt dann aber eben auch zu "falschen" Nummerierungen in der menu.lst.

Deshalb kann man bei manueller GRUB-Installation auch auf eine eigene, der Situation angepasste device.map zurückgreifen. Dann würde man eine richtige Nummerierung in der menu.lst erreichen.

Gruß, Martin

Newubunti schrieb:

Das ganze liegt am BIOS-Geräte-Mapping, was nur während des Startprozesses ersichtlich wird.

Das betrifft auch die Partitionen. Beispiel:

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System

/dev/sda2               1       17304   138994348+  83  Linux
/dev/sda3           17305       19216    15358140   82  Linux Swap / Solaris

Grub unter Ubuntu findet die Grub-Dateien auf (hd0,1).

grub> find /boot/grub/stage1
 (hd0,1)

Die Installation von (hd0,1) in (hd0) ist erfolgreich.
Grub startet aber nicht mit "root (hd0,1)" in der menu.lst durch, weil Grub beim Booten unter (hd0,1) die 2.Partition versteht (hier=swap). Mit "root (hd0,0)" startet Grub durch.

gabi schrieb:

Das betrifft auch die Partitionen. Beispiel:

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System

/dev/sda2               1       17304   138994348+  83  Linux
/dev/sda3           17305       19216    15358140   82  Linux Swap / Solaris

Das sieht für mich aber nach einer "verbogenen" Partitionierung aus. Also der "Standardfall" ist das bei einem Ein-Platten-System nicht. Denn wo ist da sda1? Wäre also die Frage, wie es hier zu dieser Partitionsliste kommt.

Vom Grundprinzip hast Du aber Recht. Die GRUB-Shell sieht immer nur das, was Ihr das laufende System bietet - und das kann von der aktuellen Realität abweichen.

Bei dem von Dir aufgezeigten Beispiel wird der Fehler aber schätzungsweise durch eine falsche bzw. nicht aktualisierte /etc/fstab ausgelöst.

Beim BIOS-Geräte-Mapping stellt das System nicht wirklich etwas falsch dar, sondern es kann es wohl einfach nicht erkennen. D.h. hier ist es eher die Regel, dass etwas durcheinander gerät.

Bei einem Ein-Platten-System ist es dagegen eher die Ausnahme.

Gruß, Martin

Newubunti schrieb:

Denn wo ist da sda1? Wäre also die Frage, wie es hier zu dieser Partitionsliste kommt.

Das ensteht, wenn man sda1 nachträglich löscht. Solche eine "verbogene" Partitionierung ist gar nicht so selten. Eine "ordentliche" Partitionierung hat man nur anfänglich, wenn man "ordentlich" ertstellt hat. Auch wenn man zb sda5 löscht und an derselben Stelle neu anlegt, bekommt die neue Partition (alt:sda5) eine neue Nummer (die nächste verfügbare) und heißt dann zb sda8, obwohl sich physikalisch nix geändert hat.

Gerät  boot.     Anfang        Ende     Blöcke   Id  System
...
/dev/sda5             1        100   
/dev/sda6           101        200   
/dev/sda7           201        300   

sda5 gelöscht und neu angelegt:

Gerät  boot.     Anfang        Ende     Blöcke   Id  System
...
/dev/sda8             1        100   
/dev/sda6           101        200   
/dev/sda7           201        300  

Naja, wie häufig das jetzt real vorkommt ist letztlich auch egal. Ich wollte auch keineswegs sagen, dass das unmöglich wäre. Nur ist der Fehler etwas transparenter, als das BIOS-Geräte-Mapping.

Du hast auf jeden Fall Recht, dass man bei den Bezeichnungen noch ergänzen muss, dass die sich aus einem laufenden System ergebenden "Nummerierungen" nicht der "GRUB-Realität" während des Bootvorgangs entsprechen müssen.

Woran das dann letztendlich liegt - also Geräte-Mapping oder etwas durcheinander geratene Partitionsnummerierung - ist ja letztlich egal.

Die "Boot-Realität" sieht man also immer in der GRUB-Konsole aber nicht unbedingt in der GRUB-Shell.

Das ist übrigens auch ein Umstand, der bei GRUB und den verschiedenen Installations-Methoden große Bedeutung hat und dort zu ergänzen wäre. Auch die Erklärung der Bedeutung der device.map würde in diesem Zusammenhang Sinn ergeben.

Da ich Deine Beiträge häufig verfolge, weiß ich aber auch, dass Du ohnehin ein Anhänger der "Methode 6" und damit der Konsole bist - aus guten Gründen wie man (auch) an diesem Beispiel sieht.

Gruß, Martin

@gabi: Ich könnte schwören, dass in dem von Dir geschilderten Fall Grub das System immer unter hd(X,1) finden müßte. Damit will ich jetzt nicht deine Beobachtungsgabe in Frage stellen, sondern nur betonen, dass das ganze vielleicht am verwendeten BIOS liegt? Ich werde mal einen Test in einer virtuellen Maschine machen und berichten...

EDIT:
Es ist wie ich erwartet habe: Nach dem Löschen der ersten Partition bootet das System nachwievor problemlos (was ja auch daran liegt, dass in der menu.lst bereits die UUID verwendet wird und nicht mehr der frühere "root ..."-Eintrag. Ein

find /boot/grub/stage1

auf der Grubkonsole direkt nach Systemstart liefert aber eben auch "hd(0,1)". Getestet habe ich mit Intrepid in einer Virtualbox.

Ich könnte mir in gabis Fall also eine Besonderheit im BIOS vorstellen. Vielleicht ist das aber auch das Standardverhalten, wenn es sich um ein USB-Gerät handelt?

DrScott schrieb:

EDIT:
Es ist wie ich erwartet habe: Nach dem Löschen der ersten Partition bootet das System nachwievor problemlos (was ja auch daran liegt, dass in der menu.lst bereits die UUID verwendet wird und nicht mehr der frühere "root ..."-Eintrag. Ein

find /boot/grub/stage1

auf der Grubkonsole direkt nach Systemstart liefert aber eben auch "hd(0,1)". Getestet habe ich mit Intrepid in einer Virtualbox.

Also wenn ich gabi richtig verstanden habe, dann hast Du nicht das richtige getestet. Ein bereits installierter GRUB lässt sich durch die gelöschte erste Partition nicht aus der Ruhe bringen. Das ist nicht das Problem.

Es geht wohl darum, dass man in einer Live-Session die erste Partition löscht und dann in der gleichen Session z.B. Ubuntu samt GRUB installiert.

Hier würde dann GRUB unter Umständen, wenn man ihn über die Shell installiert, zu einer anderen Partitionsreihenfolge kommen, als er es dann während des nächsten Systemstarts aus der Konsole käme. Ich habe das aber jetzt praktisch so noch nicht nachvollzogen.

Vorstellen könnte ich es mir grundsätzlich, wobei ich sagen muss, dass ich bei einem Ein-Platten-System noch keine Probleme mit einem unter "falschen Voraussetzungen" installierten GRUB hatte.

Ich werde das auch mal virtuell testen.

Gruß, Martin