staging.inyokaproject.org

Hier auch nochmal die angeforderte fstab von kulumbu, fast identisch und schön automatisch auskommentiert.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda5 during installation
UUID=ee375e09-6484-4d90-b089-414db3d116a4 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=78C1-82FE  /boot/efi       vfat    defaults        0       1
# swap was on /dev/sda6 during installation
UUID=92a50d83-0276-4509-95ee-952083033640 none            swap    sw              0       0

Erst einmal Danke - das ist was ich suchte!!

Bleibt die Frage, ob es sinnvoll ist, die Festplattenprüfung auf 1 zu belassen??

syscon-hh schrieb:

Bleibt die Frage, ob es sinnvoll ist, die Festplattenprüfung auf 1 zu belassen??

IMO nein, weil man im Zweifel nur eine Verschlimmbesserung herbeiführt. Wenn man wirklich ein Problem mit der ESP hat, dann kann man das immer noch manuell prüfen. Normalerweise wird ja von der Partition überwiegend gelesen und das ja auch nur in der Systemstartphase. Geschrieben wird da doch nur, wenn man die Loader installiert. Bei Windows weiß ich jetzt nicht, ob da irgend etwas bezüglich Energiesparmodi schreibend geschieht, aber ich denke mal dafür haben sie wohl die MS-System-Reserved-Partition vorgesehen.

Windows hängt die Partition AFAIK auch nicht ein, sofern sie mal eingehängt wird, wird empfohlen Ihr den Laufwerksbuchstaben zu entziehen, um zu verhindern, dass Windows-Updates etwaige Fehler auf der Partition verursachen.

Ich bin wie gesagt der Meinung, dass sie auch unter Linux nicht ständig eingehängt sein sollte. Am saubersten wäre es, wenn grub-install die Partition automatisch mounten würde. Das tut es derzeit nicht, wie ich gestern Abend noch mal geprüft habe.

Am besten dürfte es ohnehin sein, wenn man von der Partition ein dd-Backup-Image anlegt. Das kann man dann im Problemfall leicht zurück spielen. Die UUIDs hat man dann gleich mit gesichert, was dann auch die Funktionalität der Boot-NVRAM-Einträge aufrecht erhält.

Gruß, Martin

Hallo - ich bin jetzt hier auf ein weiteres Phänomen gestoßen:

Bislang waren alle EFI-Partitionen als VFAT angelegt - nun habe ich hier einen Rechner

• FUJITSU ESPRIMO 710, Windows 7 Pro 64Bit

bei dem ist diese Partition als NTFS angelegt - ansonsten ist der (Windows-) Inhalt vergleichbar mit anderen Rechnern. Außerdem ist die Partitionstabelle als MPT angelegt.

Nur lässt sich zur Zeit das/die Ubuntu EFI-Paket(e) nicht freiwillig auf diese Partition ablegen. Wiederum als normale MBR Installation mit dem angepassten Skript kann dann auch das Windows gestartet werden.

Es gibt da erhebliche Arbeit, alle Aspekte in eine noch lesbare Beschreibung einzubinden. Ob es hilfreich ist, so wie schon in der Baustelle auf die einzelnen, von den diversen Firmen beschrittenen Wege du dokumentieren, scheint mir aussichtslos.

Begründung: Ich habe hier zwei EFI-BIOS von AMI, gleiche Core-Version, die von zwei Herstellern unterschiedlich abgeändert wurden (Funktionen unterdrückt) und führen somit zu verschiedenem Handling.

Mal sehen, welche Überraschungen da noch so warten.

Hallo syscon-hh,

kannst Du von dem System bitte mal die Ausgaben von

sudo fdisk -l

und von

sudo file -s /dev/sdX

(/dev/sdX anpassen) posten. Was mich an dem Fall wundert ist, dass ich bisher immer gelesen habe, Windows könnte EFI nur mit GPT. Möglicherweise wurde aber beim Ausetzen es Systems auch ein Hybrid-MBR erzeugt - beabsichtigt oder unbeabsichtigt.

Daher bitte auch mal noch die Ausgabe von

sudo hexdump -s0 -n512 -C /dev/sdX 

Es gibt da erhebliche Arbeit, alle Aspekte in eine noch lesbare Beschreibung einzubinden. Ob es hilfreich ist, so wie schon in der Baustelle auf die einzelnen, von den diversen Firmen beschrittenen Wege du dokumentieren, scheint mir aussichtslos.

Deswegen wollte ich auch immer erst mal einen Sammelthread, ähnlich wie bei Ubuntu-Entwicklung, um erst mal zu sehen, was so in der Praxis vorkommt, um dann beurteilen zu können, was im Wiki sinnvoll ist und was nicht.

Grundsätzlich wollte ich soweit eigentlich mit dem Artikel nur Aufzeigen, dass es eben nicht einheitlich ist und wo diese Unterschiede liegen (können), wie es aber grundsätzlich funktioniert. Und mir geht es vor allem darum, dass man bei der Installation um die verschiedenen Modi weiß, damit man wenigstens Nachvollziehen kann, was man eigentlich gemacht hat.

Gruß, Martin

EDIT:
Wie sieht beim ESPRIMO das Boot-Menü aus. Eher so wie beim LENOVO oder so wie beim ASROCK. Der ESPRIMO hat auch Intel-Management-Funktion für das BIOS/EFI über Netzwerk, oder?

Step 1:

Wie sieht beim ESPRIMO das Boot-Menü aus. Eher so wie beim LENOVO oder so wie beim ASROCK. Der ESPRIMO hat auch Intel-Management-Funktion für das BIOS/EFI über Netzwerk, oder?

Sieht noch nach klassischen Stil aus (grauer Hintergrund, dunkle bzw. helle Schrift)

• Oben Menüleitse mit den Optionen

  • Darunter die ausgewählten Optionen bzw. Anzeigen

  • Rechts davon mögliche Einstellungen

Das Ganze ggf. mit Unterpunkten - eben AMI typisch und keine Mausbedienung.

Step 2:

Zur Zeit setzte ich das Windows auf eine separate (Test-)Festplatte auf, die ich vorab mit GPT als Tabelle gesetzt habe - ich werde berichten. Dann lässt sich auch klären, ob das FUJITSU-typisch ist oder generell vom BIOS her geblockt wird. Das Ergebnis habe ich als Anlage (efi-daten.txt) beigefügt! Das zweite Laufwerk ist der USB-Stick mit Ubuntu.

Step 3:

Danach kann ich die Original-Festplatte wieder rein hängen und die gewünschten Daten liefern.

Der ESPRIMO hat auch Intel-Management-Funktion für das BIOS/EFI über Netzwerk, oder?

Ja - volle Kanne, sogar wählbar wie PXE-Boot ablaufen soll und welche Prioritäten hinsichtlich EFI. Nur testen kann ich das nicht.

Nachtrag: Die Original-Festplatte ist wieder eingebaut und ein Ubuntu (daily 24.08) wurde installiert. Erwartungsgemäß wurde Windows von GRUB 2 nicht erkannt. Mit einem Live-System die Werte der Festplatte - es ist nicht Fisch noch Fleisch!! Aber Experten können es sicherlich deuten → siehe Anlage (efi-kombi.txt)

gruß syscon-hh

Hallo syscon-hh,

da habe ich mich nicht deutlich genug ausgedrückt. Ich wollte

sudo file -s /dev/sda

und

sudo hexdump -s0 -n512 -C /dev/sdX 

sehen.

Aber auch so sieht das für mich schon einfach danach aus, dass Windows nicht im EFI-Mouds vorinstalliert ist. Das läuft also alles über den BIOS-Kompatibilitäts-Modus. Ich sehe da auf sda1 einfach eine Windows-Bootsektor.

Nur lässt sich zur Zeit das/die Ubuntu EFI-Paket(e) nicht freiwillig auf diese Partition ablegen. Wiederum als normale MBR Installation mit dem angepassten Skript kann dann auch das Windows gestartet werden.

Ja, das ist normal so. Wenn Du die Ubuntu-Installation auf diesem System im EFI-Modus startest, dann wird es zwar installiert, aber anschließend kannst Du es nicht starten, weil keine Boot-Loader-Installation stattgefunden hat. Das liegt daran, dass im EFI-Modus nur GRUB-EFI mit an Board ist, es müsste in dem Fall aber grub-pc installiert werden. GRUB-EFI installiert nur auf eine EFI-System-Partition - zumindest innerhalb des Ubuntu-Setups.

Die ESP gibt es aber auf dem ESPRIMO nicht. Das ist eine stinknormale Windows-Bootpartition, wie sie Windows 7 immer anlegt - auch auf einem BIOS-System. Du hättest bei der Installation in dem Fall die ESP selbst anlegen müssen. Das macht das Ubuntu-Setup in dem Fall nicht automatisch - was sicher auch eine gute Entscheidung ist, da je nach Vorpartitionierung zu risikoreich. Allerdings macht eine ESP auf einem MBR-Datenträger in meinen Augen wenig Sinn.

Bei dem Lenovo-PC den ich hatte - der übrigens auch eine Office-PC mit Windows-7-Pro war - ist das ganz genauso gewesen. Die Vorinstallation war auf einem Datenträger der nach MBR-Schema partitioniert ist.

So lange die System ein CSM haben, ist ja die EFI-Installation keine Pflicht. Ich denke mal, dass die Hersteller bei den Office-Computern für den professionellen Einsatz lieber auf Nummer sicher gehen und noch einen Bogen um eine EFI-Installation machen. Bringt ja keine nennenswerten Vorteile für die Zielgruppe.

Hat sich bei Dir ein Eintrag mittels efibootmgr setzen lassen? Das ging nämlich bei dem Lenovo-System nicht, so dass ich Ubuntu neben eine Windows-EFI-Installation - die ich zuvor selbst eingerichtet hatte - letztlich nur im BIOS-Modus mittels BIOS-Boot-Partition auf dem GPT-Datenträger installieren konnte. GPT-Datenträger habe ich selbst angelegt, da wie gesagt die Vorinstallation auf MBR-Basis war.

Gruß, Martin

Hier die korrigierte Ausgabe als Anlage efi-nachtrag.txt

Zu Deinen Anmerkungen:

Die Installation auf meiner Test-Festplatte funktioniert einwandfrei (Anlage = efi-daten.txt) und auch das Ubuntu lässt sich über den EFI-Modus auswählen (Anzeigen u.a.):

• > P2: ST3500413AS: Windows Boot Manager <

Wobei

• P2: ist der Platz in der intern eingestellten Bootreihenfolge

• ST3500413AS: die Festplattenbezeichnug

Es bleibt die getroffene Auswahl auch als Option für den nächsten Start erhalten (entspricht der Grubfunktion saved. Auswahl erfolgt hier über die F12 .

Das entspricht also, was wir hier kürzlich im Forum beschrieben hatten. Und auch das Problem mit dem Timeout (siehe kulumbu 4717672) ist kein Problem von (U)EFI, sondern es ist/war die Zeit nach dem Einschalten des Rechner und dem Zeitpunkt, wo man diese Taste drücken muss.

Ansonsten kann ich diese Maschine nur empfehlen - unter Ubuntu läuft alles ohne Nachjustieren, incl. Speedstepping.

Sorry, aber ich blicke gerade noch nicht durch:

syscon-hh schrieb:

Hier die korrigierte Ausgabe als Anlage efi-nachtrag.txt

Zu Deinen Anmerkungen:

Die Installation auf meiner Test-Festplatte funktioniert einwandfrei (Anlage = efi-daten.txt)

Meine Anmerkung war auf die interne Platte bezogen, also die, auf der die Windows-Vorinstallation liegt. Da hatte ich Dich so verstanden:

Nur lässt sich zur Zeit das/die Ubuntu EFI-Paket(e) nicht freiwillig auf diese Partition ablegen. Wiederum als normale MBR Installation mit dem angepassten Skript kann dann auch das Windows gestartet werden.

Auf einer MBR-Platte ist bei mir bis jetzt automatisch durch das Ubuntu-Setup - wohlgemerkt im EFI-Modus, also GRUB-Startbildschirm beim Start des Mediums - noch nie GRUB-EFI installiert worden. Getestet übrigens immer mit 12.04. Es wurde immer nur Ubuntu ohne Bootloader installiert.

Nur im BIOS-Modus klappt die Installation dann vollständig, dann aber eben mit GRUB-PC - also Installation ganz normal in MBR + verborgenen Bereich.

Auf eine neue leere Platte oder eine mit bereits bestehender GPT, funktioniert die Installation aus dem EFI-Modus heraus dagegen ohne Probleme.

Ist das bei Dir nun genauso oder anders? Ich hatte Dich erst so verstanden, dass es genauso ist - was mir auch logisch erscheint - bin aber durch Deinen letzten Beitrag gerade etwas verwirrt.

und auch das Ubuntu lässt sich über den EFI-Modus auswählen (Anzeigen u.a.):Formatierter Text

• > P2: ST3500413AS: Windows Boot Manager <

Das ist Dein Eintrag für Ubuntu oder existierte dieser Eintrag von Anfang an so für Windows?

Zeige doch mal bitte noch die Ausgabe von

sudo efibootmgr --verbose

Danke!

Gruß, Martin

EDIT:
Das Timeout lässt sich nun durch efibootmgr beeinflussen oder hast Du das im EFI-Setup eingestellt? Ich kenne es so, dass meist im EFI-Setup ein Delay für die Funktionstasten eingestellt werden kann. Konnte aber noch nicht ausprobieren, ob das das gleiche Timeout ist, wie bei efibootmgr. Laut manpage von efibootmgr klingt es für mich nach zwei unterschiedlichen Dingen.

Zu den Thema oben melde ich mich noch einmal - ich setzte jetzt die Test-Festplatte noch mal völlig neu auf - incl. Windows 7, Ubuntu 12.04.1 und poste dann die entsprechenden Ausgaben.

Nebenbei bemerkt:

Habe ich das bisher überlesen oder fehlt der Hinweis, das auch die

• Windows-DVD im UEFI-Modus

gestartet werden muss???

syscon-hh schrieb:

Nebenbei bemerkt:

Habe ich das bisher überlesen oder fehlt der Hinweis, das auch die

• Windows-DVD im UEFI-Modus

gestartet werden muss???

Das hast Du nicht überlesen, dass fehlt noch - wie der Artikel insgesamt noch nicht fertig ist. Da fehlt z.B. auch noch, dass sich Ubuntu auf dem Lenovo im EFI-Modus nicht hat starten lassen und ich das über eine BIOS-Installation mit BIOS-Boot-Partition gelöst habe.

Wie gesagt ich habe im Moment wenig Zeit und die Systeme auch nicht mehr verfügbar, so dass ich das aus den damaligen Aufzeichnungen - die nicht in allen Belangen optimal sind - machen muss. Dazu kommen halt auch immer noch mal Tests in Virtual-Box - soweit möglich - um mich noch mal zu vergewissern, wenn eine Aufzeichnung lückenhaft ist.

Dann habe ich den Text schon mehrfach umgebaut, mit dem Versuch mich auf das wesentliche zu konzentrieren. Da ist im Moment eventuell auch noch Spielraum.

Ist es bei Dir auch so, dass der Unterschied zwischen Windows im EFI-Modus und im BIOS-Modus darin besteht, dass im EFI-Modus die Aufforderung zum Drücken einer Taste um von CD zu starten in hellem Weiß erscheint, während es im BIOS-Modus ein mehr grau-weiß ist?

Gruß, Martin

EDIT:
Damit ich nicht noch zig mal nachfrage, wenn Du gerade wieder eine Testreihe abgeschlossen hast. IMO sind folgende Tests sinnvoll und für EFI-Artikel interessant - musst Du natürlich nicht alles testen, wenn Du die Zeit nicht hast:

Das richtet sich jetzt übrigens nicht nur an syscon-hh, sondern alle, die Zeit und Lust und Spaß am Testen haben.

Für die Test-Installationen von Ubuntu empfehle ich übrigens, den Netzwerkadapter im EFI-Setup zu deaktivieren, weil das die Installationszeit stark verkürzt.

sudo fdisk -l

sudo parted -l

sudo sgdisk -p /dev/sda # Bei nur einer Platte im System, sonst gegebenfalls anpassen

file -s /dev/sda # Bei nur einer Platte im System, sonst gegebenfalls anpassen

sudo hexdump -s0 -n512 -C /dev/sda

sudo efibootmgr --verbose

Nun geht gar nichts mehr - auch mit den obigen Befehlen. Es ergibt

root@quantal:/home/laura# hexdump -s 0 -n 1024 -C /dev/sdf

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  01 00 ee fe ff ff 01 00  00 00 af 9e a1 12 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  1e 74 77 4a 00 00 00 00  01 00 00 00 00 00 00 00  |.twJ............|
00000220  af 9e a1 12 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000230  8e 9e a1 12 00 00 00 00  fa 86 da 9a ec db 21 40  |..............!@|
00000240  9e a5 77 55 bd e0 7d 83  02 00 00 00 00 00 00 00  |..wU..}.........|
00000250  80 00 00 00 80 00 00 00  fd 21 2d 59 00 00 00 00  |.........!-Y....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

Und was ist das jetzt - um überhaupt etwas zu sehen, hab ich die Menge auf 1024 gesetzt. Es scheint so, als wenn der Bootsektor um einen nach hinten gerutscht ist. Einbinden und lesen kann ich die Partitionen. Es ergibt

root@quantal:/home/laura# sudo sgdisk -p /dev/sdf

Logical sector size: 512 bytes
Disk identifier (GUID): 9ADA86FA-DBEC-4021-9EA5-7755BDE07D83
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          194559   94.0 MiB    EF00  
   2          194560       304490495   145.1 GiB   0700  
   3       304490496       312580095   3.9 GiB     8200 

• 1 = EFI-Partition

• 2 = System-Partition

• 3 = SWAP

Nur es erfolgt keine UEFI-Anzeige mehr in der F12 -Auswahl und die Auswahl der Festplatte mündet in der Auswahl eines anderen Menüpunktes. Siehe auch die Anzeigen des CD-Laufwerkes mit 12.04.1-DVD für beide Startvarianten, das hatte ich vorher mal für die erste Solo-Installation.

Hola syscon-hh

syscon-hh schrieb:

Und was ist das jetzt - um überhaupt etwas zu sehen, hab ich die Menge auf 1024 gesetzt. Es scheint so, als wenn der Bootsektor um einen nach hinten gerutscht ist. Einbinden und lesen kann ich die Partitionen. Es ergibt

Wenn es weiter hilft, ich hatte die LBA 0 - LBA 2 (Partitionstabellen) mal aufgebröselt (sicher nicht perfekt) auf meiner Benutzer/RapaNui (Abschnitt „MBR“)

Hallo RapaNui - gute Informationen!!!

Nur liegt das Problem leider woanders → Die Bezeichnungen / Verzeichnisse, die Ubuntu auf die EFI-Partition schreibt, stimmen mit der EFI-Spezifikation nicht überein:

• Soll der Verzeichnisse:

  • EFI → boot → grubx64.efi

• Ist bei Ubuntu

  • EFI → ubuntu → grubx64.efi

Wobei die Schreibweise (groß / klein) des Leadvolume sowie die Bezeichnung der Datei egal ist, solange die Endung efi lautet.

Nachdem ich das händisch umgestellt habe, wird das auch korrekt angezeigt und ist auswählbar.

Kann jemand mal diesen Sachverhalt überprüfen.

Dazu gibt es wohl erweiterte Spezifikationen. Newubunti hat den Link dazu auch mit in efibootmgr integriert.

EFI System Partition Subdirectory Registry

Originally implemented by the DIG64 Consortium, this is an industry registry of vendor-specific subdirectory 
names in the EFI system partition described in the UEFI Specification.  

EDIT: syscon-hh schrieb:

Hallo RapaNui - gute Informationen!!!

Ein Auslesen/Anzeigen dieser Informationen macht u.a. mein Skipt lsdisk