staging.inyokaproject.org

RapaNui schrieb:

Ja, die meine ich immer, wenn ich von Ubuntu/Bootx64 schreibe, kann man ja einfach aus der CD herauskopieren. Da aber die im Loader hinterlegen Verweise auf das /boot/grub identisch sein sollten, müsste der, rein theoretisch, auch auf einem installierten System einsetzbar sein. Darum immer meine Nachfrage: Was macht der? (Bei Win kann man übrig. den eig. Loader der CD auf einen vorbereiteten USB ziehen und der startet dann auch.)

Also ich habe jetzt mal den Loader bootx64.efi von der CD nach /EFI/boot auf der Festplatte kopiert. Dann wieder Windows-NVRAM-Eintrag raus, Ubuntu-NVRAM-Eintrag raus, die efi-Dateien in /EFI/Microsoft/boot gelöscht und dann neu gestartet.

Ergebnis: Das System startet nicht. Schwarzer Bildschirm mit blinkendem Cursor.

Es bestärkt sich der Eindruck, dass das MSI-EFI bei einer internen Platte das Verzeichnis /EFI/boot nicht auswertet.

Ich kann die bootx64.efi natürlich über die EFI-Shell starten, dann landet das System in einer GRUB-Shell. Stecke ich einen Ubuntu-Boot-Stick an, dann wird über diesen Eintrag auf der Festplatte das Live-System vom Stick gestartet. Also das Ding lässt sich nicht universell nutzen sondern ist, wie bei EFI üblich, wohl an eine UUID gekoppelt.

Dann lässt sich übrigens nicht jede EFI-Datei aus GRUB direkt heraus laden.

Aus dem Verzeichnis /EFI/Microsoft/Boot lässt sich weder die bootmgr.efi noch die memtest.efi direkt von GRUB starten. Diese beiden könnne nur über die bootmgfw.efi geladen werden.

Die bootmgr.efi braucht man übrigens bei Windows für die Anzeige des erweiterten Start-Menüs (Abgesicherte Modus, Normal starten, Reparieren etc.)

Ansonsten feire mal schön!

Gruß, Martin

Newubunti schrieb:

Also ich habe jetzt mal den Loader bootx64.efi von der CD nach /EFI/boot auf der Festplatte kopiert...

Ergebnis: Das System startet nicht. Schwarzer Bildschirm mit blinkendem Cursor.

Es bestärkt sich der Eindruck, dass das MSI-EFI bei einer internen Platte das Verzeichnis /EFI/boot nicht auswertet.

Ich kann die bootx64.efi natürlich über die EFI-Shell starten, dann landet das System in einer GRUB-Shell. Stecke ich einen Ubuntu-Boot-Stick an, dann wird über diesen Eintrag auf der Festplatte das Live-System vom Stick gestartet. Also das Ding lässt sich nicht universell nutzen sondern ist, wie bei EFI üblich, wohl an eine UUID gekoppelt.

Wir können wohl festhalten, dass die bootx64.efi auf den Installationsmedien auf diese ausgelegt sind (internes umschalten, cd fs1: ... oder so etwas). An der UUID kann es dabei wohl nicht liegen, die bezieht sich mMn auf die Einträge im NVRAM. Von einem Stick mit entsprechenden /boot/grub/ würde er diese wohl auswerten, sonst dürfte so etwas ⇒ UEFI-Windows-Setup vom USB-Stick ja auch nicht funktionieren.

Dann lässt sich übrigens nicht jede EFI-Datei aus GRUB direkt heraus laden.

Das ist wohl wieder falsch rüber gekommen. Laden läßt sich wohl jeder, er landet aber u.U. in einer Shell, bringt Fehlermeldungen (nicht so etwas wie ein Kernelpanik aus dem man nur durch reboot heraus kommt) und besitzt spezielle Funktionalitäten.

Aus dem Verzeichnis /EFI/Microsoft/Boot lässt sich weder die bootmgr.efi noch die memtest.efi direkt von GRUB starten. Diese beiden könnne nur über die bootmgfw.efi geladen werden.

Solche Abhängigkeiten können ja in Zukunft bei verschiedenen *.efi eingebaut sein, will heißen, nicht jede xyz.efi ist zum Starten eines Systems gedacht. Da bin ich dann mal gespannt, wie die GRUB-Leute diese Einschränkungen implementieren werden. syscon-hh's Informationen deuten ja darauf hin, dass die die Loader verfügbar machen wollen. Hart codierte Ausschlüsse mache da ja weniger Sinn, denn die Namensgebung der *.efi soll ja frei wählbar sein.

Saludos

RapaNui schrieb:

Wir können wohl festhalten, dass die bootx64.efi auf den Installationsmedien auf diese ausgelegt sind (internes umschalten, cd fs1: ... oder so etwas). An der UUID kann es dabei wohl nicht liegen, die bezieht sich mMn auf die Einträge im NVRAM. Von einem Stick mit entsprechenden /boot/grub/ würde er diese wohl auswerten, sonst dürfte so etwas ⇒ UEFI-Windows-Setup vom USB-Stick ja auch nicht funktionieren.

Ja, Du hast recht. Da habe ich mich falsch ausgedrückt. Mit EFI hat das ganze schon gar nichts mehr zu tun. Das ist dann insoweit eine GRUB-Geschichte. Das prefix bzw. die Art und Weise was GRUB an weiteren Bestandteilen von wo nachlädt, ist in das EFI-Image integriert. Die grubx64.efi bzw. die bootx64.efi ersetzt bzw. enthält das, was bei einem BIOS-System an GRUB-Bestandteilen zum ersten Teil im Code-Bereich des MBR und zum zweiten Teil im verborgenen Bereich abgelegt wurde.

Dann lässt sich übrigens nicht jede EFI-Datei aus GRUB direkt heraus laden.

Das ist wohl wieder falsch rüber gekommen. Laden läßt sich wohl jeder, er landet aber u.U. in einer Shell, bringt Fehlermeldungen (nicht so etwas wie ein Kernelpanik aus dem man nur durch reboot heraus kommt) und besitzt spezielle Funktionalitäten.

Naja, da man mit der EFI-Shell nicht all zu viel anstellen kann, heißt für mich erfolgreich Laden in dem Sinne, dass dann das gleiche passiert, als würde man es über "Windows" laden.

Aber im Prinzip gilt für Windows gleiches, wie für GRUB:

• Die Datei bootmgfw.efi repräsentiert das, was bei einem BIOS-System von Windows zum ersten Teil in den Code-Bereich des MBR und zum zweiten Teil in den Bootsektor (genaugenommen 16 Sektoren) der Windows-Bootpartition geschrieben wird (die Bootpartition wird von Windows als Systempartition bezeichnet)

• Die bootmgr.efi ist für mich das Pendant zur Datei bootmgr auf einem BIOS-System.

Aus dem Verzeichnis /EFI/Microsoft/Boot lässt sich weder die bootmgr.efi noch die memtest.efi direkt von GRUB starten. Diese beiden könnne nur über die bootmgfw.efi geladen werden.

Solche Abhängigkeiten können ja in Zukunft bei verschiedenen *.efi eingebaut sein, will heißen, nicht jede xyz.efi ist zum Starten eines Systems gedacht.

Ich hätte an dieser Stelle bis jetzt gedacht, dass eigentlich nur die bootmgfw.efi eine .efi-Datei seien muss und der Rest sich dann so handhaben lässt, wie auf einem BIOS-System - also mit "normalen" Dateien. Ist aber auch nicht so wichtig. Letztlich muss man aus Ubuntu-Dualboot-Sicht ja nur wissen, welche Datei man von Ubuntu (GRUB) aus anstoßen muss, um Windows zu laden und warum. Das wissen wir ja nun - zumindest im Groben.

Hätte ja auch sein können, dass man z.B. die bootmgr.efi auch direkt aus GRUB heraus hätte laden können, denn so ein Eintrag im GRUB-Menü, der die F8-Funktionalität verfügbar gemacht hätte, wäre durchaus praktisch gewesen, weil es ja im Dualboot doch auch mal vorkommt, das man ein chkdsk von der Reparatur-Konsole ausführen muss.

Letztlich ist aber EFI dann so gescheit wohl nicht umgesetzt worden, sondern man hat herkömmliches Bootverhalten 1:1 auf EFI-Gegebenheiten adaptiert.

Gruß, Martin

Noch einen Nachtrag:

syscon-hh schrieb:

syscon-hh schrieb:

Nachtrag: Mal eine ganz andere Frage (zum Thema EFI-Installation):

Starten über die UEFI-Option vom USB-Stick realisieren >

So auch das Problem scheint gelöst zu sein:

Ich habe mal beide Startmedien am Grub-Prompt mit

set 

untersucht und dann gesehen, dass die CD als root=(cd0) anzeigte und auch der Stick root=(hd0) - dass USB-System sich aber auf (hd0,msdos1) befindet.

Das ist darin begründet, dass

• der Startmedienersteller nur auf /dev/sdX1

• UNetbootin auch /dev/sdX1 erwartet

Um jetzt diese Falle zu umgehen, muss man mal tricksen oder besser gesagt, gezielt vorgehen:

• 1. Partitionstabelle neu schreiben → msdos

• 2. Im Terminal ohne Suffix-Nummer eingeben

  • sudo mkfs.vfat -I /dev/sdX

• 3: UNetbootin werkeln lassen - jetzt akzeptiert er die Partition ohne Zählnummer !!!

• 4. Rebooten und den UEFI-Eintrag im EFI-Menü auswählen 👍

Das könnte man auch noch in das WIKI einbringen - hat m.E. an anderer Stelle keine Berechtigung bzw. verwirrt dort nur.

gruß syscon-hh

Diese Verrenkungen muss ich übrigens bei dem MSI-Board nicht machen und soweit ich mich erinnere auch bei keinem von den anderen beiden Systemen davor. Das scheint also eher die Ausnahme zu sein.

Gruß, Martin

Ich stehe im Moment auf'n Schlauch - Ratlosigkeit macht sich breit!!

Mit dem USB-Stick und dem Eintrag in der dortigen grub.cfg:

menuentry "Windows von Festplatte nachladen" {
    search -n -f --set=root /EFI/Microsoft/Boot/bootmgfw.efi
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

(alternativ mit UUID) kann ich ohne Probleme über den UEFI-Menüeintrag das Windows starten - und nun kommt's - mit dem gleichen Eintrag in die seitens Ubuntu generierte grub.cfg (und auch mit dem obigen favorisierten Eintrag oder andere Kombinationen) kommt folgende Fehlermeldung:

/EndEntire
file path: /ACPI(a0341d0,0)/PCI(2,1f)/UnknownMessaging(12)/HD (1,800,3200,55129134d8cfce43,a6,0)/ File (\efi\microsoft\boot)/ File (bootmgfw.efi)
/EndEntire

und das Windows startet nicht. Mein EFI-BIOS scheint ein besonderes zu sein - oder liegt es doch am Board und dem Zusammenspiel?? Alles Andere konnte ich mir bisher plausibel zusammenreinem - nun ist Schluss!

gruß syscon-hh

syscon-hh schrieb:

(alternativ mit UUID) kann ich ohne Probleme über den UEFI-Menüeintrag das Windows starten - und nun kommt's - mit dem gleichen Eintrag in die seitens Ubuntu generierte grub.cfg (und auch mit dem obigen favorisierten Eintrag oder andere Kombinationen) kommt folgende Fehlermeldung:

/EndEntire
file path: /ACPI(a0341d0,0)/PCI(2,1f)/UnknownMessaging(12)/HD (1,800,3200,55129134d8cfce43,a6,0)/ File (\efi\microsoft\boot)/ File (bootmgfw.efi)
/EndEntire

Von welchem Ubuntu, das nicht geht, sprichst Du hier? Ist das Ubuntu und die grub.cfg die nicht funktioniert auf dem Stick oder ist das Ubuntu und die grub.cfg auf der Festplatte?

Und hat sich das auf mein vorheriges Post bezogen oder ist das eine allgemeine Frage, die gerade bei Dir aufgekommen ist?

Gruß, Martin

Von welchem Ubuntu, das nicht geht, sprichst Du hier?

Sowohl auf dem USB-Stick (Live-System, mit UNetbootin erstellt) als auch auf der Rechner Festplatte befinden sich Precise Pangolin (also LTS 12.04.1). Auf dem Rechner außerdem

• Windows 7 Prof 64bit

und letzteres läßt sich nicht aus der grub.cfg mit einem seperatem Eintrag seitens der rechnerinternen Festplatte starten - ansprechen ja, ansonsten käme ja nicht die Fehlermeldung. Diese scheint mir ja windowsbezogen.

Eine Suche mittels bless (Hexdump) ergibt keinen derartigen Eintrag in der grubx64.efi Datei.

Nachtrag: Einen Schritt weiter (oder??).

Ich habe festgestellt, dass Grub-Shell-Aufrufe aus einer UEFI-Umgebung heraus nicht funktionieren. Dazu mal bitte antesten, ob aus einer Grub-Shell ( C ) heraus, die auf einen UEFI-Eintrag (z.B. ubuntu) basiert / aufgerufen wurde, diese funktionieren - mal ein Ansatz

search -n -u --set=root <gültige UUID> 

der bei mir in ein Einfrieren mündet. Ich will jetzt erst einmal wissen, ob das lokal ist oder generell auftritt?!?

Also bei mir ist das so, dass ich $root in einer GRUB-Shell, die vom Ubuntu-Stick gestartet wurde setzen kann. Das führt nicht zum einfrieren. Wie gesagt, der Stick ist dabei ganz einfach ohne Deine Veränderungen mit dem Startmedienersteller eingerichtet wurden.

Bei mir ist es dabei auch so, dass $root von Anfang an hd0,msdos1 ist. Allerdings kann ich dann trotzdem nicht mittels chainloader Windows auf der internen Platte booten. Das erzeugt im Prinzip den gleichen Fehler, wie bei Dir mit dem /EndEntire... .

Allerdings verhält es sich gleich, wenn ich das über den intern auf der Festplatte eingerichteten GRUB versuche. root lässt sich mit set über UUID oder File setzen. Chainloader lädt aber Windows nicht.

Entweder ist das ein Bug - wobei ich da eher auf GRUB tippe, auch wenn es sich mir nicht erklärt - oder der chainloader Eintrag muss vielleicht in der Shell irgendwie anders lauten.

Das Problem liegt für mich auf alle Fälle bei dem "UnknownMessaging(12)".

Gruß, Martin

EDIT:
🙄 Also ich habe jetzt einfach mal - trotz der Entire-Meldung - boot in die Shell eingegeben. Und siehe da, Windows bootet. Also kann man die Meldung offenbar ignorieren?!

Gruß, Martin

Newubunti schrieb:

EDIT:

Also ich habe jetzt einfach mal - trotz der Entire-Meldung - boot in die Shell eingegeben. Und siehe da, Windows bootet. Also kann man die Meldung offenbar ignorieren?!

Probiere ich auch gleich noch mal aus - noch ein Ergebnis:

• Vorgaben:

  • Internes Laufwerk 1

  • Internes Laufwerk 2

  • Externes Laufwerk 1 (RAID-Verbund)

  • Externes Laufwerk 2 (RAID-Verbund)

• Verhalten Eins - Start mit internen Laufwerk (UEFI)

  • ls ergibt in der Grub-Shell

    • für die internen Laufwerke: Auslösung + Anzeige der Partitionen

    • für die externen Laufwerke: nur (hd2) bzw. (hd3)

• Verhalten Zwei - Start mit externen Laufwerken (BIOS)

  • ls ergibt in der Grub-Shell

    • für die externen Laufwerke: Auslösung + Anzeige der Partitionen

    • für die internen Laufwerke: nur (hd1) bzw. (hd2)

Wobei jetzt im zweiten Fall richtigerweise die Reihenfolge von (hd0) zur ersten externen HD wechselt, von der aus aufgerufen wurde.

Nachtrag: Ich habe jetzt mal Deinen Versuch bei mir eingearbeitet - Erfolgsmeldung !! Nachfolgend ein Skript (31_Windows), dass das sicherstellt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#!/bin/bash

EFI_MEDIUM=$( cat /etc/mtab | grep /boot/efi | cut -d ' ' -f 1 )
EFI_UUID=$( blkid -c /dev/null -o value -s UUID ${EFI_MEDIUM} | cut -d ' ' -f 2 );

echo "Menüeintrag für Windows eingefügt" >&2

cat <<EOF
menuentry "Windows 7 Professional" {
	insmod fat
	insmod part_gpt
	insmod part_msdos
	search --no-floppy --fs-uuid --set=root ${EFI_UUID}
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
	boot
}
EOF

Welcher der insmod-Module man meiden könnte, wird später optimiert - wichtig scheint mir aber das fat-Modul. Ich muss mal nachforschen, ob es bei chainloader eine Ergänzung gibt, die darauf abzielt, auftretende Fehler zu ignorieren

Nachtrag 2:

So ich habe das jetzt reduziert auf:

1
2
3
4
5
6

...
	insmod fat
	insmod chain
	search --no-floppy --fs-uuid --set=root ${EFI_UUID}
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
...

Das Modul chain bereinigt die Fehleranzeige.

syscon-hh schrieb:

Das Modul chain bereinigt die Fehleranzeige.

Das kann ich hier nicht bestätigen auch mit insmod chain - allerdings in der GRUB-Shell ausgeführt, kommt die Entire-Meldung. Die Frage ist auch, ob das in dem Sinn überhaupt eine Fehlermeldung oder eher einer Rückmeldung bzw. Status-Meldung ist.

Ist sowieso irgendwie seltsam. Für was brauche ich eigentlich das Modul "chain", wenn es an sich auch ohne geht? Ich dachte eigentlich, dass das Modul überhaupt erst die Nutzung von "chainloader" möglich macht.

Naja, solange es funktioniert, soll es mich nicht weiter stören.

Gruß, Martin

RapaNui schrieb am 15. September:

ich hab mir auch mal weitere Gedanken gemacht.

Grub kann ja mittels chainload die EFI-Programme zur Ausführung bringen. Bei den Bootloadern, z.B. von Windows, geht das über die 40_custom ja ganz einfach:

 menuentry "Windows 7 UEFI" {
    insmod fat
    search --fs-uuid --no-floppy --set=root 6050-A107
    chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi 

Ich habe dazu jetzt ausführliche Tests auf verschiedenen EFI-Boards durchgeführt. Dabei bing es um das Laden eines EFI-Eintrages aus einer EFI-Umgebung heraus und bin zu einer allgemein gültigen Form gekommen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#!/bin/bash
# EFI-Partition suchen und auswerten
[ ! -f /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi ] && exit;
EFI_MEDIUM=$( cat /etc/mtab | grep /boot/efi | cut -d ' ' -f 1 );
EFI_UUID=$( blkid -c /dev/null -o value -s UUID ${EFI_MEDIUM} | cut -d ' ' -f 2 );

echo "Menüeintrag für Windows eingefügt" >&2

cat <<EOF
menuentry "Windows 7 Professional" {
	insmod fat
	insmod chain
	search --no-floppy --fs-uuid --set=root ${EFI_UUID}
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
EOF

• Die Zeilen 3 bis 5

sind zur Auswertung und entlasten die Anwender hinsichtlich der korrekten Bestimmung der HD-Parameter.

• Die Zeile 7

dient der Anzeige, sofern das Skript umgesetzt wurde und als Hinweis, dass da noch was in der /etc/grub.d ist.

• Die Zeile 12

war nicht immer erforderlich - hat jedoch niemals gestört, deshalb zur sicheren Abwicklung einfach drin lassen.

Jetzt werden wir noch mal testen, wie es sich andere Kombinationen auf EFI-Boards verhalten bzw. gestrickt werden müssen:

• EFI (z.B. Ubuntu) soll Non-EFI aufrufen

  • Windows als BIOS-Installation

  • Ubuntu (oder anderes Linux) als BIOS-Installation

  • Loop-Devices abgelegt auf HD

• Non-EFI soll EFI aufrufen

gruß syscon-hh

syscon-hh schrieb:

Ich habe dazu jetzt ausführliche Tests auf verschiedenen EFI-Boards durchgeführt. Dabei bing es um das Laden eines EFI-Eintrages aus einer EFI-Umgebung heraus und bin zu einer allgemein gültigen Form gekommen:

Das sieht soweit gut aus. Hast Du/habt Ihr das auch schon mal für den Fall getestet, dass es mehrere Datenträger mit einer EFI-System-Partition gibt?

Ansonsten:

Braucht Ihr wirklich das insmod fat. Ich frage deswegen, weil immer wenn ich in ein EFI-GRUB-Shell gehe und lsmod eingebe ist das Modul fat bereits installiert. Nochmaliges Laden eines Moduls schadet natürlich nicht, aber irgendwie geht es ja auch um schlüssige Darstellungen.

Oder habt Ihr schon mal eine GRUB-EFI-Shell gehabt, die das fat-Modul nicht enthält?

• Die Zeilen 3 bis 5

sind zur Auswertung und entlasten die Anwender hinsichtlich der korrekten Bestimmung der HD-Parameter.

👍 Aber deswegen auch noch mal der Hinweis, auf Mehr-Platten bzw. Mehr-Datenträger-System.

• Die Zeile 12

war nicht immer erforderlich - hat jedoch niemals gestört, deshalb zur sicheren Abwicklung einfach drin lassen.

Ich habe mir da für mich mal folgende Erklärung zusammen gereimt:

Das Modul chain ist - anders als das Modul fat - ja tatsächlich nicht in der GRUB-EFI-Shell geladen. Bei mir funktioniert das aber bisher auch immer ohne den Eintrag.

Ich erkläre mir das damit, dass das ja eigentlich mehr ein Dateisystem-Aufruf ist, anstatt das Abarbeiten bzw. Einleiten einer Blocksprung-Anweisung, wie es beim Chainloading auf einem BIOS-System der Fall ist, wo man das Chainloading gerade deswegen verwendet, weil eine Dateisystem-Operation nicht möglich ist bzw. durch das BIOS nicht unterstützt wird.

Beim EFI-System wird aber die Dateisystemoperation auf der EFI-System-Partition schon vom EFI aus unterstützt. Da ist dann das chain-Modul weniger wichtig.

Gruß, Martin

Newubunti schrieb:

Hast Du/habt Ihr das auch schon mal für den Fall getestet, dass es mehrere Datenträger mit einer EFI-System-Partition gibt?

Nicht wissentlich - nehmen wir mal in unsere Agenda auf! Du meinst also, von einem GRUB-(2.0) ausgehend, nicht die eigene EFI-Partition ansprechen, sondern über eine weitere EFI-Partition zu starten?

Braucht Ihr wirklich das insmod fat. Ich frage deswegen, weil immer wenn ich in ein EFI-GRUB-Shell gehe und lsmod eingebe ist das Modul fat bereits installiert. Nochmaliges Laden eines Moduls schadet natürlich nicht, aber irgendwie geht es ja auch um schlüssige Darstellungen.

Ja - eines unserer Systeme - das ESPRIMO - startet nicht ohne diesen Eintrag, ein anderes auf einem GIGABYTE-Board hingegen schon.

syscon-hh schrieb:

Newubunti schrieb:

Hast Du/habt Ihr das auch schon mal für den Fall getestet, dass es mehrere Datenträger mit einer EFI-System-Partition gibt?

Nicht wissentlich - nehmen wir mal in unsere Agenda auf! Du meinst also, von einem GRUB-(2.0) ausgehend, nicht die eigene EFI-Partition ansprechen, sondern über eine weitere EFI-Partition zu starten?

Ja, genau. Ausgehend von der Annahme, dass jeder weitere Datenträger eine eigene EFI-System-Partiton haben könnte auf der auch wieder ein EFI-Loader liegt.

Nur interessehalber:

Ja - eines unserer Systeme - das ESPRIMO - startet nicht ohne diesen Eintrag, ein anderes auf einem GIGABYTE-Board hingegen schon.

Der Eintrag wird dort gebraucht, weil das fat-Modul - aus welchen Gründen auch immer - nicht in der GRUB-EFI-Shell geladen ist oder trotzdem es bereits eigentlich geladen ist? Kann man ja überprüfen, indem man mit "C" in die Shell wechselt und lsmod eingibt.

Gruß, Martin

Newubunti schrieb:

Kann man ja überprüfen, indem man mit "C" in die Shell wechselt und lsmod eingibt.

War klar - ist eben dort nicht vorhanden - warum auch immer. Kann jetzt aber auch an der Grub-Version liegen, dass müsste man jetzt mal durchtesten.