# ESP Verwaltung auf ASUS UEFI firmware

## EasterParade

Hallo Leute,

mein Optimismus, auf irgendeinem Gentoo Forum eine brauchbare Hilfe zu bekommen, hält sich in Grenzen,

insbesondere bei diesem Thema.

Obwohl ich vor 1 Jahr Gentoo auf meinem Z97 basierten Asus board im UEFI Modus zum Laufen gebracht habe,

fühle ich mich immer noch als kompletter Anfänger was efi betrifft.

Da ich seither bereits einige kernel ausprobiert habe, wollte ich mal Aufräumen auf meiner esp und habe

alte kernel gelöscht und zwar deren System.map, config und vmlinuz Dateien, die da lagen, zumal meine esp

nicht groß ist. Anschliessend habe ich mit grub-mkconfig die grub.cfg neu geschrieben ( /dev/sda2, auf der 

die EP00 liegt, war gemountet ).

Seither kriege ich einen langen Beep Gruß von der firmware meines Sabertooth, wenn ich hochfahre und zwar nach dem Beep Post für "alles ok".

Hört sich an wie Signal Code für Festplatte nicht vorhanden/OS nicht vorhanden.

Dennoch lädt grub sofort danach; ich kann ohne Probleme Gentoo booten und auch Windows 10 ( liegt auf

einer SSD = kein Dualboot von einer hdd ).

```
efibootmgr -v

BootCurrent: 0001

Timeout: 1 seconds

BootOrder: 0001,0000,0006,0008,0009

Boot0000* Windows Boot Manager  HD(2,GPT,83636705-9af4-4ae0-9dc3-c97ac4f7ec95,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...5................

Boot0001* grub2 HD(2,GPT,7359ea3f-0917-4e42-aac4-045713be41eb,0x1800,0x3d000)/File(\EFI\GRUB2\GRUBX64.EFI)

Boot0006* UEFI OS       PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(2,GPT,7359ea3f-0917-4e42-aac4-045713be41eb,0x1800,0x3d000)..BO

Boot0008* UEFI OS       PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(2,GPT,7359ea3f-0917-4e42-aac4-045713be41eb,0x1800,0x3d000)..BO

Boot0009* UEFI OS       HD(2,GPT,7359ea3f-0917-4e42-aac4-045713be41eb,0x1800,0x3d000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

```

Das Zeug einfach löschen war ein Fehler. Aber eigentlich ist alles ok, was auch efibootmgr mir sagt. 

Also entweder, die firmware lernt und der lange Beep verschwindet wieder, weil die "Erinnerung" der firmware für die gelöschten kernel verschwindet,

oder aber ich muss da was selber machen.

Aber was und ob ich da was flicken kann, weiss ich nicht.

Vielleicht jemand von euch?

----------

## schmidicom

Ein UEFI interessiert sich normalerweise nur für "\EFI\BOOT\BOOTX64.EFI" und die Quellen welche in seinem eigenen Bootloader (dass ist das was du mit efibootmgr angezeigt bekommst) registriert sind. Wenn das UEFI plötzlich anfängt zu piepsen ist deine Aufräumaktion in der ESP wohl eher nicht der Grund und vom löschen irgendwelcher Einträge mittels efibootmgr würde ich dir dringend abraten [1].

Aber du könntest mal einen CMOS-Reset durchführen, vielleicht verschwindet das Piepsen dann wieder.

[1] Das kann dazu führen das der Computer gar nicht mehr startet.

----------

## EasterParade

Dann sitzt nun Information im NVRAM über Sachen, die nicht mehr da sind.

CMOS löschen würde aber auch meine nach wie vor tadellose Bootreihenfolge umschmeissen.

ARGGG

Ich habe damals ohnehin grosse Fehler gemacht. Ich habe mich total durchgewurschtelt, bis Gentoo

endlich booten wollte.

Beispiesweise habe ich einen Mix aus grub und stub kernel. Dabei bin ich mir nicht mal sicher, ob

grub sich überhaupt interessiert für bootx64.efi in /boot/efi/EFI/boot/ ... mittlerweile glaube ich auch,

dass ich die kleine unformatierte /dev/sda1 gar nicht gebraucht hätte, von Anfang an nicht. Jedenfalls

nicht für efi mit grub

 *Quote:*   

> Wenn das UEFI plötzlich anfängt zu piepsen ist deine Aufräumaktion in der ESP wohl eher nicht der Grund und vom löschen irgendwelcher Einträge mittels efibootmgr würde ich dir dringend abraten

 

Hatte ich auch nicht vor. Eigentlich ist nichts passiert, noch nicht. Der Beep ist nur störend.

Dennoch könnte ich irgendwann doch mal Probleme kriegen bis hin zu einem unbootbaren Gentoo ( Windows bootet immer, da es seine eigene efi boot Partition hat   :Confused:   )

----------

## schmidicom

 *transsib wrote:*   

> Ich habe damals ohnehin grosse Fehler gemacht. Ich habe mich total durchgewurschtelt, bis Gentoo 
> 
> endlich booten wollte.

 

Du hättest mal mein gebastel sehen sollen als ich die ersten Schritte mit UEFI machte, das war auch nicht gerade der Inbegriff der Perfektion.  :Wink: 

Dazu kommt das damals alles noch irgendwie experimentell und teilweise auch nicht sonderlich gut dokumentiert war.

 *transsib wrote:*   

> Beispiesweise habe ich einen Mix aus grub und stub kernel. Dabei bin ich mir nicht mal sicher, ob 
> 
> grub sich überhaupt interessiert für bootx64.efi in /boot/efi/EFI/boot/ ... mittlerweile glaube ich auch, 
> 
> dass ich die kleine unformatierte /dev/sda1 gar nicht gebraucht hätte, von Anfang an nicht. Jedenfalls 
> ...

 

Da ich schon länger keinen GRUB mehr benutze (ist mir persönlich schlicht zu kompliziert und für einen Bootloader auch in seiner gösse völlig übertrieben) kann ich dir nicht genau sagen was er braucht und was nicht. Aber ich weiß das die "\EFI\BOOT\BOOTX64.EFI" eigentlich nur eine Art "failsave" ist falls die Boot-Einträge im UEFI, aus welchen Gründen auch immer, nicht funktionieren oder aber von einem dem UEFI unbekannten Datenträger (CD, DVD, USB, etc.) gestartet werden soll.

Was das Partitionslayout angeht kann ich nur folgendes sagen: Es gibt Anleitungen wo empfohlen wird sowohl eine ESP- als auch eine klassische boot-Partition anzulegen doch das ist völlig unnötig, eine GPT-Partition kann problemlos beides sein.

Am besten siehst du dir mal folgende Webseiten an:

https://help.ubuntu.com/community/UEFIBooting

http://www.rodsbooks.com/refind/

http://www.syslinux.org/wiki/index.php?title=Install#UEFI

https://wiki.archlinux.org/index.php/syslinuxLast edited by schmidicom on Thu Sep 01, 2016 1:23 pm; edited 1 time in total

----------

## Josef.95

 *schmidicom wrote:*   

> Es gibt Anleitungen wo empfohlen wird sowohl eine ESP- als auch eine klassische boot-Partition anzulegen doch das ist völlig unnötig, eine GPT-Partition kann problemlos beides sein.

  Ja, schon richtig, aber wenn man zb einen Botloader wie grub nutzen möchte ist es idR keine gute Idee grub mit auf eine FAT-32 formatierte ESP zu installieren.

----------

## schmidicom

@Josef.95

Bitte nicht falsch verstehen aber wenn der GRUB inzwischen so überfett ist das er nicht einmal mehr aus einer einfachen ESP heraus sauber/zuverlässig starten kann wird es so langsam aber sicher erst recht Zeit sich von dem Ding zu verabschieden und wieder zu den Wurzeln (zum Beispiel syslinux, der kann seit einiger Zeit nämlich auch EFI) zurückzukehren. Mal ehrlich was kann der GRUB eigentlich so tolles was sich nicht auch mit syslinux oder refind umsetzen lassen würde?

----------

## Josef.95

@schmidicom

Es ging mir in erster Linie ums FAT32 Filesystem auf der ESP

Es sollte doch mit Linux  nicht wirklich notwendig sein sich Software auf ein FAT-Dateisystem zu installieren, wenn es auch besser geht :)

----------

## schmidicom

@Josef.95

Leider wurde in den offiziellen Spezifikationen von www.uefi.org nur FAT16/FAT32 (also nicht einmal exFAT geschweige denn ext2/3/4 oder irgendetwas anderem wie btrfs was vor allem für SSD's gesünder gewesen wäre) als mögliches Dateisystem für die ESP definiert, also sollten alle Bootloader welche bei UEFI mitmachen wollen besser lernen damit umzugehen.

PS: Ich bin auch nicht begeistert davon und würde bei der ESP ebenfalls viel lieber ein modernes Dateisystem im Einsatz sehen, F2FS wäre dafür vielleicht ganz gut geeignet, aber solange hauptsächlich M$ bei www.uefi.org das Sagen hat wird sich daran so schnell wohl nichts ändern.

----------

## Josef.95

@schmidicom

Ja, grub kann recht gut mit UEFI umgehen, aber das ist doch kein Grund sich nun /boot auf eine FAT formatierte ESP zu legen bzw sich einen Bootloader auf ein FAT-Dateisystem installieren zu lassen.

Man kann /boot doch auch wie bisher mit einem UNIX-Artigen Dateisystem nutzen, und zusätzlich eine ESP anlegen.

Sprich, davon die ESP auch als /boot zu mißbrauchen halte ich nicht viel.

Lass /boot doch besser auf ext2 (oder was auch immer der Bootloader unterstützt).

----------

## EasterParade

Wieder hochgekommen ist der ganze Schlamassel mit einer neuen Box, die ich gebaut habe; mit nem i7 auf x99

und ASUS firmware.

Dieser da hat nun keine Bios boot Partition mehr, nur die ESP = Efi System Partition, formatiert vfat, gemountet auf /boot

Grub ist hier bootloader und es geht. (Habe nun andere Probleme mit dem board, namentlich Zeitgeber und Netzwerkadapter; mit Ubuntu geht alles btw ).

Was mich vor einem Jahr mit meinem Sabertooth Z97 so gestört hat ist die Tatsache, dass das handbook nicht ganz

vollständig ist, wenn es um efi geht. So habe ich mir aus anderen Anleitungen Informationen geholt, die eigentlich im

handbook stehen sollten. Wie zum Beispiel das Herübernehmen der efivars durch das chroot ins neue System.

Oder die Tatsache, dass eine Bios boot Partition nicht wirklich nötig ist: Ubuntu hat die nicht.

Gut wäre es, wenn Gentoo das Kapitel efi Installation extra und verlinkt oder in einem roten Kasten bringen würde.

Und wenn mehr Leute über ihre Erfahrungen bei der Installation berichten würden, auch die Fallen, über die sie stolpern.

Allerdings sieht die Installation eines OS im UEFI Modus bisweilen sehr unterschiedlich aus, je nach dem, welche UEFI firmware man vor sich hat.

So habe ich viele Vorarbeiten, die man im UEFI selbst vornehmen muss für meine ASUS boards aus dem ASUS ROG Forum, wie zum Beispiel

das Abschalten des CSM, wie man SecureBoot deaktiviert und dass man ein UEFI bootbares Installationsmedium braucht. Das alles kann das 

Gentoo handbook auch nicht erfassen.

 *Quote:*   

> Du hättest mal mein gebastel sehen sollen als ich die ersten Schritte mit UEFI machte, das war auch nicht gerade der Inbegriff der Perfektion. 

 

Danke, ich dachte schon, ich wär allein   :Embarassed: 

Man sollte doch meinen, dass der Umgang mit UEFI für Linux mittlerweile genauso in Fleisch & Blut übergegegangen sein sollte, wie die alte Methode 

mit mbr, denn UEFI gibt es schon sehr lange.  Aber da steht sich mein Kopf selbst im Weg.

Und was die ESP angeht ... die muss tatsächlich vfat fat16/fat32 sein laut Spezifikation des UEFI Konsortiums. Ich habe aber auch schon gehört, dass manche

Leute sie ext2 formatiert haben; nur ein Gerücht?

Jedenfalls könnte mein  "OS not installed Beep" auch damit zusammenhängen. Den habe ich erst seit vorgestern, als ich Putzfrau gespielt habe. 

Da fällt mir ein, dass das handbook ruhig sagen kann, dass man die ESP größer machen soll, 500M zum Beispiel.

Ausserdem muss ich mich mit NVRAM aus UEFI motherboards beschäftigen, bevor ich das CMOS lösche, damit ich mir

damit nicht noch eine Mine hinlege.

Aber wie schon gesagt: alles läuft nett: Grub lädt und läßt mich sowohl Gentoo, als auch Windows booten, wie immer. 

Und zwischen dem langen Beep und dem Laden von grub vergeht nur geschätzt eine Sekunde.

Danke schmidicom für die links; die habe ich alle schon. Wie gesagt: bei mir blockiert sich der Kopf selbst   :Laughing: 

----------

## schmidicom

Wegen dem einen langen Beep wäre der folgende Wiki-Artikel vielleicht noch interessant:

https://de.wikipedia.org/wiki/Liste_der_BIOS-Signalt%C3%B6ne

Demzufolge könnte ein Problem mit den RAM vorliegen.

----------

## EasterParade

Stimmt: 1x Lang = RAM

Aber das RAM ist ok. Hardwarefehler ist das keiner.

Meine Theorie ist, die firmware warnt mich auf diese Weise, dass 

in der efi Partition Informationen sind, die es in der bootx64.efi nicht mehr findet.

Auf jeden Fall muss ich baldigst /dev/sda1 + /dev/sda2 platt machen, neu formatieren

als vfat und alles so machen, wie auf der neuen Kiste.

Und vorher /boot/efi aus der fstab rausmachen, so dass nur nur /boot da drin steht.

Danke für die Diskussion.

----------

## EasterParade

Habe nun /dev/sda1 + /dev/sda2 zusammengelegt, /boot frisch formatiert und

als esp neu angelegt.

grub Installation auf esp hat gut funktioniert und bootet mir beide Betriebssysteme.

Gestartet mit SysrescueCD, alle mount Befehle, dann modprobe efivars, dann

mount --rbind /sys/firmware/efi/efivars /mnt/gentoo/sys/firmware/efi/efivars

Danach chroot und grub neu installieren mit

grub-install --target=x86_64-efi --efi-directory=/boot --boot-directory=/boot

Den langen beep nach dem kurzen POST beep habe ich immer noch, aber nur wenn diese hdd dran hängt.

Ein kosmetisches Problem habe ich nun noch: unvorsichtigerweise liegt jetzt esp auf /dev/sda2

und rootfs auf /dev/sda1

Die Partitionsnummerierung entspricht nicht der Reihenfolge auf der hdd.

Ich weiss, dass fdisk dies korrigieren kann mit der Expertenoption "x"

Kann das auch für eine gpt gelabelte hdd gehen?

----------

## schmidicom

 *transsib wrote:*   

> Ein kosmetisches Problem habe ich nun noch: unvorsichtigerweise liegt jetzt esp auf /dev/sda2
> 
> und rootfs auf /dev/sda1
> 
> Die Partitionsnummerierung entspricht nicht der Reihenfolge auf der hdd.
> ...

 

Mit gdisk lässt sich das beheben, erst mit "x" ins Expertenmenu dann "s":

Aber danach müssen meist auch die Einträge im UEFI-Bootloader neu erstellt und die Konfiguration von GRUB, fstab kontrolliert werden.

EDIT:

Hab grad selber nachgesehen, die Option scheint vom Expertenmenü ins Hauptmenü gewandert zu sein also gleich ein "s" ohne "x".

----------

## EasterParade

Option "s" scheint mir nicht das zu tun, was ich mir vorstelle.

Da könnte ich falsch liegen.

Übrigens kann ich dem langen beep die Luft abschneiden.

Wenn er startet, nach dem normalen POST beep, dann kann ich den

abkürzen mit ENTER oder Pfeil ab. 

Alles schein ganz normal zu sein. 

Sehr merkwürdig. Ich mach da jetzt nix mehr dran.

Nur die Partitionsnummerierung stört mich etwas. Aber wie gesagt, 

mit "s" könnte einiges kaputt gehen.

KORREKTUR: oh warte, stimmt, mit "s" im Hauptmenü geht es. 

Dann werde ich das mal machen. Danke   :Smile: 

----------

