Gerry_Ghetto Die Booteinträge werden im NVRAM und nicht auf der ESP gespeichert.

In anderen Worten: Nach deiner Meinung geht der Eintrag bei UEFI bei einem BIOS Upgrade und somit die Bootfähigkeit der Installation immer verloren, was bei MBR Installationen vorher eigentlich niemals der Fall war ...

Die Frage bleibt, weshalb die anderen UEFI Einträge noch vorhanden sind (Selbst einer, der mit "ubuntu" bezeichnet ist und wahrscheinlich von Mint stammt), während ausschließlich der Arch-GRUB Eintrag verschwand.

Gerry_Ghetto In solchen Fällen reicht es normalerweise, einen fehlenden Booteintrag mit efibootmgr neu zu erstellen.

Aber auch das kann man ja nicht mit der bestehenden (nicht mehr bootbaren) Installation machen ...

    tomsam Gerry_Ghetto Die Booteinträge werden im NVRAM und nicht auf der ESP gespeichert.

    In anderen Worten: Nach deiner Meinung geht der Eintrag bei UEFI bei einem BIOS Upgrade und somit die Bootfähigkeit der Installation immer verloren, was bei MBR Installationen vorher eigentlich niemals der Fall war ...

    Nein, das ist falsch. Meine Worte sagen, dass der Speicherort für Booteinträge nicht auf einer Festplatte liegt. Meine Worte sagen nur indirekt etwas über die Persistenz der Daten aus. Einträge im NVRAM bleiben erhalten (NV steht für "non volatil"). Es kann aber gut sein, dass die Firmware alte/invalide Einträge aus dem NVRAM entfernt.

    Die Frage bleibt, weshalb die anderen UEFI Einträge noch vorhanden sind (Selbst einer, der mit "ubuntu" bezeichnet ist und wahrscheinlich von Mint stammt), während ausschließlich der Arch-GRUB Eintrag verschwand.

    Viele Einträge werden von der Firmware automatisch generiert. Und dann gibt es Einträge, die (automatisch) bei der Installation eines Betriebssystems hinzugefügt werden.

    Wenn jedoch noch alte Einträge wie zum Beispiel "ubuntu" (bei Linux Mint müsste der Eintrag anders lauten, da Linux Mint kein Ubuntu ist) vorhanden sind, deutet das eher darauf hin, dass dein Arch Linux speziell/anders aufgesetzt wurde.

    Gerry_Ghetto In solchen Fällen reicht es normalerweise, einen fehlenden Booteintrag mit efibootmgr neu zu erstellen.

    Aber auch das kann man ja nicht mit der bestehenden (nicht mehr bootbaren) Installation machen ...

    Wieso nicht? Du brauchst ja nur irgendein im UEFI-Modus gestartetes System (und erhöhte Rechte). Zum Beispiel ein Linux-Livesystem mit efibootmgr. Aber im Prinzip kannst du den Eintrag auch unter Windows mit bcdedit erzeugen.

    • tomsam hat auf diesen Beitrag geantwortet.

      Gerry_Ghetto Es kann aber gut sein, dass die Firmware alte/invalide Einträge aus dem NVRAM entfernt.

      So nebenbei: Als Informatiker weiss ich sehr wohl was NV bedeutet.

      Wieso sollte der vorher gültige GRUB Eintrag mit einmal durch das BIOS-flashen invalide geworden sein? Der hat ja schliesslich 6+ Monate lang gut funktioniert und das System war vor dem Flashen auch sauber heruntergefahren.

      Oder sollte es nur der primäre Eintrag sein, der dann nicht mehr funktioniert?

      Gerry_Ghetto Wenn jedoch noch alte Einträge wie zum Beispiel "ubuntu" (bei Linux Mint müsste der Eintrag anders lauten, da Linux Mint kein Ubuntu ist) vorhanden sind, deutet das eher darauf hin, dass dein Arch Linux speziell/anders aufgesetzt wurde.

      Auf dem System, welches Ende November 21 zusammengebaut wurde, war bisher ausschliesslich Mint (fuer <1 Monat) und danach Arch. Beim Aufsetzen wurde jeweils nichts besonderes gemacht, ausser der Tatsache, dass die Partionen über verschiedene Platten verteilt sind. Der "ubuntu" Eintrag muss also zwingend von der Mint Installation kommen. Und ? wieso ist Mint kein Ubuntu mehr??? Hat sich da in den letzten 6 Monaten was geändert?

      Das grub-install wurde damals und jetzt mittels

      grub-install    --target=x86_64-efi         \
                      --efi-directory=/boot/efi   \
                      --bootloader-id=GRUB        \
                      --recheck
      
      vi /etc/default/grub
      GRUB_DEFAULT=saved
      GRUB_SAVEDEFAULT=true
      GRUB_DISABLE_OS_PROBER=false
      
      grub-mkconfig -o /boot/grub/grub.cfg

      gemacht. Was wäre daran speziell oder falsch? Ich ändere das gerne, wenn man dann später weniger Probleme bekommt.

      Gerry_Ghetto Wieso nicht?

      Ne, die Frage muss lauten: Wieso muss das überhaupt gemacht werden, wenn doch andere "Betriebssysteme" inklusive Mint in der Lage waren, den Eintrag beizubehalten oder korrekt restauriert zu bekommen.

        Kleiner Nachtrag:

        Die Herren/Damen/Diverse von ASUS teilen mit, dass

        1. das Motherboard per-se kein Linux unterstützt
        2. man doch OS Type auf "Other OS" setzen solle, und
        3. CSM enablen

        Bei mir war Other OS schon aktiviert und CSM disabled, derweil ich dafuer auch bisher keine Notwendigkeit sah.

        • Dirk hat auf diesen Beitrag geantwortet.

          tomsam Wir haben 2022. Niemand braucht heutzutage noch CSM.

          Hmm, ich weiß ihr wollt mich hier nicht aber ich möchte in Punkto CSM doch etwas einwerfen:

          CSM, auch als Compatibility Support Module bekannt, ist eine Komponente der UEFI-Firmware, die Legacy-BIOS-Kompatibilität bietet, indem sie eine BIOS-Umgebung emuliert, sodass Legacy-Betriebssysteme und einige optionale ROMs, die UEFI nicht unterstützen, weiterhin verwendet werden können.
          Moderne PCs mit UEFI ohne CSM können daher Betriebssysteme und Boot-Medien, die ein BIOS erfordern, nicht mehr ausführen. (Quelle: Wikipedia)

          Darum ist vielleicht CSM doch nicht so unnütz.

            josefine Darum ist vielleicht CSM doch nicht so unnütz.

            CSM bräuchte man, wenn man ein UEFI hat, aber die Systeme im BIOS Modus installiert wurden.

            In diesem Fall sind die Systeme allerdings im UEFI Modus installiert.

            tomsam

            Gerry_Ghetto Es kann aber gut sein, dass die Firmware alte/invalide Einträge aus dem NVRAM entfernt.

            So nebenbei: Als Informatiker weiss ich sehr wohl was NV bedeutet.

            So nebenbei: Hätte ich natürlich gewusst, wenn ich Hellseher wäre. Bin ich aber nicht. Und vielleicht wird das Forum ja auch von anderen Leuten gelesen.

            Wieso sollte der vorher gültige GRUB Eintrag mit einmal durch das BIOS-flashen invalide geworden sein? Der hat ja schliesslich 6+ Monate lang gut funktioniert und das System war vor dem Flashen auch sauber heruntergefahren.

            Es gibt da verschiedene Möglichkeiten. Jeder Hersteller kann da ja seine eigene Logik einbauen, wie die "Hygiene" der Einträge funktionieren soll. Möglicherweise hast du mehr als eine ESP?

            Oder sollte es nur der primäre Eintrag sein, der dann nicht mehr funktioniert?

            Es gibt meines Wissens keine Klassifizierung der Einträge.

            Gerry_Ghetto Wenn jedoch noch alte Einträge wie zum Beispiel "ubuntu" (bei Linux Mint müsste der Eintrag anders lauten, da Linux Mint kein Ubuntu ist) vorhanden sind, deutet das eher darauf hin, dass dein Arch Linux speziell/anders aufgesetzt wurde.

            Auf dem System, welches Ende November 21 zusammengebaut wurde, war bisher ausschliesslich Mint (fuer <1 Monat) und danach Arch.

            Und das Windows, das gebootet wird, lebt in der Cloud?

            Der "ubuntu" Eintrag muss also zwingend von der Mint Installation kommen. Und ? wieso ist Mint kein Ubuntu mehr??? Hat sich da in den letzten 6 Monaten was geändert?

            Nein, Linux Mint war noch nie ein Ubuntu. Genau so wenig, wie Ubuntu ein Debian ist. Ubuntu basiert auf Debian und Linux Mint basiert auf Ubuntu. Aber es sind verschiedene Distributionen, die eigene Bootloadernamen verwenden sollten.

            Meines Wissens hat Linux Mint nicht die Rechte an der Nutzung des Namens "ubuntu".

            Das grub-install wurde damals und jetzt mittels

            grub-install --target=x86_64-efi \
            --efi-directory=/boot/efi \
            --bootloader-id=GRUB \
            --recheck

            vi /etc/default/grub
            GRUB_DEFAULT=saved
            GRUB_SAVEDEFAULT=true
            GRUB_DISABLE_OS_PROBER=false

            grub-mkconfig -o /boot/grub/grub.cfg

            gemacht. Was wäre daran speziell oder falsch? Ich ändere das gerne, wenn man dann später weniger Probleme bekommt.

            Soweit ist nichts falsch. Allerdings weiss ich nicht, welche Partition nach /boot/efi eingehängt wurde. Es kann ja sein, dass du mehr als 1 ESP hast.

            Gerry_Ghetto Wieso nicht?

            Ne, die Frage muss lauten: Wieso muss das überhaupt gemacht werden, wenn doch andere "Betriebssysteme" inklusive Mint in der Lage waren, den Eintrag beizubehalten oder korrekt restauriert zu bekommen.

            In den Anfangstagen von UEFI kam es vor, dass der Platz im NVRAM komplett gefüllt war, weil sich da dutzende unnützer/falscher Booteinträge angesammelt hatten. Mittlerweile ist das kein grosses Problem mehr, weil die Firmware auch mal invalide Einträge löscht (oder die Hersteller bauen übergrosse NVRAM Speicher ein, aber das glaube ich nicht).

            Viele der Theorien hier kannst du ja einfach mal mit der Ausgabe von efibootmgr -v entkräften oder bestärken.

            • tomsam hat auf diesen Beitrag geantwortet.

              Gerry_Ghetto Möglicherweise hast du mehr als eine ESP?

              Ja

              Gerry_Ghetto Auf dem System, welches Ende November 21 zusammengebaut wurde, war bisher ausschliesslich Mint (fuer <1 Monat) und danach Arch.

              Und das Windows, das gebootet wird, lebt in der Cloud?

              Nein, das Windows war hierbei aussen vor.

              Gerry_Ghetto welche Partition nach /boot/efi eingehängt wurde

              diejenige, die sich auf der Boot SSD befindet.

              /dev/nvme0n1p5 ist /boot
              /dev/nvme0n1p1 ist /boot/efi

              Gerry_Ghetto Ausgabe von efibootmgr -v

              Ich habe das mal etwas eingekürzt und die UUIDs ersetzt.

              BootCurrent: 0001
              Timeout: 1 seconds
              BootOrder: 0001,0004,0007,0003,0005,0006,0002,0000,0008,0009,000A
              Boot0000* Windows Boot Manager	HD(1,GPT,UUID-1,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS
              Boot0001* GRUB	HD(1,GPT,UUID-1,0x800,0x32000)/File(\EFI\GRUB\GRUBX64.EFI)
              Boot0002* ubuntu	HD(1,GPT,UUID-1,0x800,0x32000)/File(\EFI\UBUNTU\SHIMX64.EFI)..BO
              Boot0003* UEFI OS	HD(2,GPT,UUID-2,0x8000,0x400000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
              Boot0004* UEFI: SanDisk, Partition 1	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/USB(13,0)/HD(1,MBR,0x0,0x20,0x394dfe0)..BO
              Boot0005* Hard Drive	BBS(HD,,0x0)..GO..NO........q.S.a.m.s.u.n.g. .S.S.D. .9.8.0. .1.T.B
              Boot0006* CD/DVD Drive	BBS(CDROM,,0x0)..GO..NO........u.D.R.W.-.2.4.D.5.M.T............
              Boot0007* USB	BBS(HD,,0x0)..GO..NO........q.S.a.n.D.i.s.k............
              Boot0008* UEFI:CD/DVD Drive	BBS(129,,0x0)
              Boot0009* UEFI:Removable Device	BBS(130,,0x0)
              Boot000A* UEFI:Network Device	BBS(131,,0x0)

              Nur der GRUB Eintrag musste von mir händisch neu angelegt werden.

              6 Tage später

              Gerry_Ghetto Viele der Theorien hier kannst du ja einfach mal mit der Ausgabe von efibootmgr -v entkräften oder bestärken.

              Hab ich ja nun getan. Hat es was bestätigt oder widerlegt?


              Zweite Antwort von dem sich wohl in einem geistig fragwürdigen Zustand befindlichen ASUS Support Mitarbeiter: Man möge doch zunächst mal Windows 11 installieren ...


              PS Ich kann ja aber nicht der Einzige sein, der mit einer Dual-Boot Konfiguration ein BIOS Upgrade macht. Ist das bei all Euch anderen ohne Probleme durchgelaufen? oder wurde da der (primäre) GRUB-Eintrag auch schon mal überschrieben? Ich gehe ja fast davon aus, dass das BIOS der Meinung ist, es müsse nach dem BIOS Upgrade unbedingt den Eintrag mit dem Namen "Windows Boot Manager" starten und dass dann Windows die "Booteinträge fixed", sich also selbst nach ganz oben setzt und den komischen Störenfried "GRUB" ersatzlos streicht. Das müsste aber ja bei anderen auch schon mal passiert sein.

                tomsam Hab ich ja nun getan. Hat es was bestätigt oder widerlegt?

                Das System erkennt tatsächlich zwei ESP, allerdings wird auf den ersten Blick nur eine richtig benutzt (Booteinträge 0, 1, 2). Die zweite ESP enthält scheinbar auch etwas UEFI startbares (Eintrag 3). Es ist allerdings schwer zu sagen, was da genau installiert ist.

                Falls du nichts an der fstab angepasst hast, würde ich sagen, dass auch der spurlos verschwundene Booteintrag von deinem Arch Linux auf der ersten ESP installiert war und das verschwinden mysteriös bleibt.

                tomsam Ist das bei all Euch anderen ohne Probleme durchgelaufen? oder wurde da der (primäre) GRUB-Eintrag auch schon mal überschrieben?

                Nicht überschrieben, aber weggeworfen. Finde ich jetzt weder misteriös noch hat es mich sonderlich genervt. Neu setzen und gut.
                Klar wäre es schöner wenn das einfach so funktionieren würde aber hei, was soll's 😂

                10 Tage später

                Kleiner Nachtrag: Nachdem das 2803 BIOS nun vom Status BETA auf aktuell gesetzt wurde, habe ich das Ganze noch einmal durchgeführt, diesmal mit dem Primären Eintrag auf "Windows Boot Manager" gesetzt und GRUB war Eintrag #6 ...

                Und auch bei dieser Kombination wurde beim BIOS Upgrade ausschliesslich der GRUB Eintrag entfernt ...