staging.inyokaproject.org

Hallo,

bezüglich: GRUB 2/Skripte (Abschnitt „Allgemeiner-Aufbau-Menueeintrag“) habe ich eine Frage zu angeführtem Beispiel:

Starten von USB¶

Liegt das Zielsystem auf einem externen Datenträger wie z.B. einer USB-HDD, so ist zu obigen Eintrag zusätzlich direkt unter der Zeile menuentry einzutragen (siehe Zeile 3):

1 2 3 4 5 6

.... menuentry "Ubuntu, mit Linux 2.6.32-25-generic" { insmod usb insmod ext2 set root='(hd0,1)' ....

damit die folgenden Daten richtig ausgelesen werden können. Das externe Medium muss aber grundsätzlich vom BIOS erkannt und ausgelesen werden können.

Die interne Platte wird sicher (hd0,1) sein. Der angegebene Menüeintrag für ein Zielsystem auf einen externen Datenträger sollte dann doch vermutlich z.B (hd1,1) lauten. oder irre ich?

TausB

Hallo TausB, der fragliche Abschnitt bezieht sich auf die Zeile 3 !!

Denn ohne diesen Treiber (rechtzeitig) nachzuladen, wird auch dieser externe Datenträger nicht erreicht.

Der Hinweis auf den relevanten Datenträger in Form von (hd0,3) (oder je nach Ubuntu-Version auch anders lautend), ist für einen externen Datenträger nicht maßgebend - es sollte immer die UUID verwendet werden. Der Ausdruck (hd0,3) wechselt eh' nach Zustand seinen Wert:

• Beim Aufruf von USB durch GRUB 2 ist das immer hd0 (als Startdevice)

• Beim Nachprüfen im System ist das abhängig vom BIOS und der Anzahl der SATA-Platten

gruß syscon-hh

syscon-hh:

... der fragliche Abschnitt bezieht sich auf die Zeile 3 !!

Denn ohne diesen Treiber (rechtzeitig) nachzuladen, wird auch dieser externe Datenträger nicht erreicht.

... hatte ich auch so verstanden.

... - es sollte immer die UUID verwendet werden. ....

Danke für den Hinweis.

Vielleich bin ich zu kleinkariert, mir ging es hauptsächlich um die Schlüssigkeit des Beispiels.

• Beim Aufruf von USB durch GRUB 2 ist das immer hd0 (als Startdevice)

Ich steh' auf'm Schlauch:

1. Start von GRUB von der internen Standard-Festplatte

2. in der grub.cfg ist ein Menü-Eintrag zum Starten eines OS auf externer USB-Platte

3. dazu notwendig: laden insmod usb (bis hierher habe ich alles verstanden)

4. set root= definiert das neue root (auf der ext. Platte) - korrekt?!

5. –> also kann das zu diesem Zeitpunkt nicht die int. Platte sein - korrekt?!

6. das sollte man via UUID machen - o.k. verstanden

7. die externe Platte - so verstehe ich Deinen Kommentar - wird erst nach der 'set root'-Def. automatisch zu hd0 - korrekt?!

Mir geht es nicht um Spitzfindigkeiten. Schwerpunkt im Beispiel ist das Laden mit insmod USB. Das Beispiel hätte sich mir jedoch widerspruchsfrei erschlossen, wenn beim Definieren von set root= der externe Bezug erkennbar gewesen wäre. Daß danach diese Platte mit hd0 angesprochen wird, steht auf einem "anderen Blatt". Oder habe ich es immer noch nicht verstanden? 😳

TausB

7. die externe Platte - so verstehe ich Deinen Kommentar - wird erst nach der 'set root'-Def. automatisch zu hd0 - korrekt?!

Nein (oder auch Ja), das ist nun so:

Wenn Du ein System auf der externe Platte starten willst und Grub wird von einer internen Platte aufgerufen, dann ist die externe HD in der Reihenfolge vom BIOS vermutlich eine weit hinter den internen Platten. Also bei zwei internen dann

• /dev/sdc

oder noch weiter hinten. Bei gleichen Konditionen und einem Start von dem gleichen USB-Device (via BIOS Aufruf) wird diese (egal wie es intern aussieht) zur

• /dev/sda

Nachprüfen lässt sich das jeweils, indem man im Grubmenü die cmdline mit C aufruft und dort eingibt:

• grub> ls

dann sieht das Ergebnis jeweils anders aus - einfach mal ausprobieren.

syscon-hh

Danke für Deine Geduld.

... Bei gleichen Konditionen und einem Start von dem gleichen USB-Device (via BIOS Aufruf) wird diese (egal wie es intern aussieht) zur

• /dev/sda

... Das ist klar: Wenn ich direkt von USB boote, ist das die /dev/sda (=hd0?!). - Ist in diesem Fall der Eintrag insmod USB überhaupt notwendig? Zum Lesen dieses Eintrags muß GRUB bereits in der Lage gewesen sein von USB zu lesen...

• Booten direkt von USB: –> USB ist hd0 (laden von USB nicht notwendig) - oder kann etwa durch das BIOS vorgegeben trotz booten von ext. USB die int. hd0 (bleiben) und die ext. Platte hd1 sein?

• Booten von int. Platte mit Wunsch ein OS von (ext.) USB zu starten: insmod USB notwendig

• die Bootplatte wird immer hd0. –> Schlußfolgerung: Der Eintrag 'set root=' im Beispiel (Zugriff von int. auf eine ext. Platte) kann auf keinen Fall hd0 sein!

Um Deine Zeit nicht weiter zu stehlen, werde ich nicht weiter nerven, da ich selber kein konkretes Problem habe, mir ging es nur das Verständnis. Im "Ernstfall" sind die möglichen Szenarien ggf. schnell durchgetestet. 😀

TausB

Schau noch mal hier ein → GRUB 2/Konfiguration (Abschnitt „Externe-Festplatten“).

Als Linux Neuling verstehe ich von den Wiki-Artikel leider kaum etwas. Das finde ich sehr schade, da eine Individualisierung des Boot Managers eine sehr grundlegende Angelegenheit ist, die eigentlich gleich im Rahmen des Installations-Vorgangs erledigt werden sollte. Googelt man nach "grub reihenfolge" o.ä. sieht man auch, dass viele Neuling vor genau diesem Problem stehen.

Spricht etwas dagegen, eine simple Anleitung zum Ändern der Reihenfolge ins Wiki aufzunehmen? Ich bin nach längerer Suche hier fündig geworden: http://forum.ubuntuusers.de/topic/grub-2-reihenfolge-der-eintraege-aendern/#post-2437329

Hallo td22 und wo genau sollte es Deiner Meinung nach sein.

Wir haben es unter Konfiguration beschrieben, und da gehört es wohl auch hin.

Auch in dem Unterartikel GRUB 2/Skripte wird das mehrfach angesprochen. Wir verstehen ja (nicht nur) Deinen Wunsch, dass jedwede Fragestellung gleich ganz am Anfang angesiedelt sein sollte.

Ich bin gerade (mal wieder) dabei ein kleinen NetTop Rechner als headless Server einzurichten und muss dazu meine Scripte überarbeiten. Dabei ist mir aufgefallen, dass jetzt im Bootmenü auch die Zeile

insmod part_msdos

auftaucht und das auf einem reinen Linux System. Und da wo ich '(hd0,1)' erwartet hätte finde ich jetzt '(hd0,msdos1)'.

Hat jemand eine Ahnung wo da der Unterschied ist?

Hat jemand eine Ahnung wo da der Unterschied ist?

Außer dass es Dir optisch ins Auge fällt, bedeutet das eigentlich gar nichts für LINUX-Benutzer. Die interne GRUB2-Befehlssyntax wertet das richtig aus und ist auch abwärtskompatibel (falls Du widerborstigerweise noch (hd0,1) benutzen willst).

Dieses wurde für diejenigen Benutzer eingebaut, die ihr LINUX vom Windows-Bootmanager aus aufrufen wollen, damit kommt z.B. EasyBCD und ähnliche Programme besser klar. Da aber dazu keine wasserdichten Unterlagen vorliegen, habe ich bislang eine Überarbeitung in unserem WIKI ausgesetzt.

Dass da insmod part_msdos auf einem reinen Linuxsystem auftaucht, ist insofern ungewöhnlich, es sei denn, die HD hatte mal / hat (ggf. in Teilen) eine Formatierung mit NTFS.

gruß syscon-hh

Nachtrag: Ich sehe gerade, das ist unter Natty sogar noch schlimmer

• → set root='(/dev/sda,msdos1)'

... es sei denn, die HD hatte mal / hat (ggf. in Teilen) eine Formatierung mit NTFS.

Nein, die hatte ich frisch gekauf und gleich auf einem Linux PC partitioniert.

Mir ist da jetzt aber noch ein Gedanke gekommen. Wenn man mit Gparted partitioniert ist da nicht auch immer was mit "msdos" voreingestellt? Soll das vielleicht nur eine Abgrenzung der herkömmlichen Partitionstabelle zur GUID Partition Table sein oder werden?

Dakuan schrieb:

Soll das vielleicht nur eine Abgrenzung der herkömmlichen Partitionstabelle zur GUID Partition Table sein oder werden?

Ja, das steht für MS-Dos-Partitionstabelle.

Gruß, Martin

Hi,

mir wurde per PM mitgeteilt, dass des Skript bei Abschnitt Fehlerskript-LVM-RAID Fehler hervorruft (Ubuntu 12.04):

root@rescue:/etc/grub.d# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-27-generic
Found initrd image: /boot/initrd.img-3.2.0-27-generic
error: syntax error.
error: Incorrect command.
error: syntax error.
error: line no: 76
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.
done

Er hängt sich, soweit ich das verstanden habe, an den leeren Funktionsdeklarationen auf. Wenn man dort z.B. noch jeweils einen Aufruf von true einfügt, läuft update-grub wieder durch. Es müsste dort also irgend eine Leer-Operation aufgerufen werden. Habe noch nicht probiert, ob true im Kontext von Grub funktioniert.

Gruss Lasall

Ja - das muss mit einem Wert gefüllt sein.

Hab' ich bei meinen halbjährlichen Überprüfungen übersehen - ich korrigiere es gleich mal.

gruß syscon-hh

Meine aktuelle Lösung:

1
2
3
4
5
6
7
8
9

cat << EOF
function savedefault {
   set saved_entry=0;
}

function recordfail {
   set recordfail=1
}
EOF

Hi,

hat der Zusatz "quiet splash" bei Plymouth noch Effekt?

Gruss Lasall