Installation von Mint/Ubuntu auf Notebook nicht möglich

[josef-wien]

Neben den Voraussetzungen für den UEFI-Modus ist aber auch im MBR der Festplatte GRUB-2 installiert. In der Ausgabe von dmesg ist außer dem Laden des Moduls efi_pstore nichts zu "efi" enthalten (da efi_pstore bei mir im Kernel enthalten ist und dieses backend for pstore auch im BIOS-/Kompatibilitäts-/Legacy-Modus in /sys/module existiert, kann ich dazu nichts sagen). Ich bin der Ansicht, das System läuft im BIOS-/Kompatibilitäts-/Legacy-Modus.

Der einzige Weg, unseren Wissensdurst zu stillen und den verwendeten Modus herauszufinden, wäre die jeweilige Entfernung eines der beiden Boot-Loader, und diesen Weg können wir nicht gehen, da uns dieses seltsame BIOS/UEFI nicht zur Verfügung steht.

Für mojo ist nur wichtig, daß sein System läuft.

 

[Christina]

Ich bin der Ansicht, das System läuft im BIOS-/Kompatibilitäts-/Legacy-Modus.

Das sehe ich auch so.
Vermutlich handelt es sich bei dieser Fremd-Firmware um ein Minimal-EFI, mit dem sich Microsoft-Betriebssystem bereits zufriedengeben und die Verwendung eines GPT-Disklabels fürs Bootlaufwerk gestatten, damit Festplatten von ≥2 TiB eingesetzt werden können.
Siehe auch hier: Is it EFI or not? Gigabyte’s Hybrid EFI BIOS explained

Die Linux Mint Installationsroutine entlarvt diese Notebook-Firmware erst später dann aber als ein Fake-EFI und verwendet daher den MasterBootRecord (MBR) der GUID Partitionstabelle (GPT) zum Booten. – Microsoft® gestattet dies seinen Produkten nicht.

 

[susejunky]

Hallo @josef-wien ,

Neben den Voraussetzungen für den UEFI-Modus ist aber auch im MBR der Festplatte GRUB-2 installiert.
...
Ich bin der Ansicht, das System läuft im BIOS-/Kompatibilitäts-/Legacy-Modus.

ich habe mir die Ergebnisse des bootinfoscripts noch einmal genauer angesehen

Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,msdos1)/boot/grub.

...

sda2: __________________________________________________________________________

File system: vfat
Boot sector type: FAT32
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /efi/BOOT/fbx64.efi /efi/BOOT/mmx64.efi
/efi/ubuntu/grubx64.efi /efi/ubuntu/mmx64.efi
/efi/ubuntu/shimx64.efi /efi/ubuntu/grub.cfg

...

========================== sda2/efi/ubuntu/grub.cfg: ===========================

--------------------------------------------------------------------------------
search.fs_uuid 7db42c03-83ec-4ca4-8342-9ecbc589d076 root hd0,msdos1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
--------------------------------------------------------------------------------

und bin mittlerweile der Meinung, dass das System sowohl im MBR- als auch im UEFI-Modus gestartet werden kann.

Vor wenigen Jahren, als ich noch Geräte mit BIOS im Betrieb hatte, waren alle meine Rettungssysteme so konfiguriert. Allerdings habe ich für meine Rettungssysteme immer GPT-Partitionierung und BIOS-Boot-Partitionen eingesetzt. Daher war ich erst "etwas irritiert", als ich die bootinfoscript-Ergebnisse gesehen habe.

============================ Drive/Partition Info: =============================

Drive: sda _____________________________________________________________________
Festplatte /dev/sda: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: ST500LM000-1EJ16
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sda1 39,071,744 298,893,311 259,821,568 83 Linux
/dev/sda2 * 2,048 976,895 974,848 ef EFI (FAT-12/16/32)
/dev/sda3 976,896 10,741,759 9,764,864 82 Linux swap / Solaris
/dev/sda4 298,893,312 957,243,391 658,350,080 83 Linux

Das System von @mojo scheint nun aber eine MBR-Partitionierung zu verwenden und bei der kann das GRUB2 core.img direkt hinter dem MBR abgelegt werden (2000 Sektoren sollten dafür ausreichen).

Der einzige Weg, unseren Wissensdurst zu stillen und den verwendeten Modus herauszufinden, wäre die jeweilige Entfernung eines der beiden Boot-Loader, und diesen Weg können wir nicht gehen, da uns dieses seltsame BIOS/UEFI nicht zur Verfügung steht.

Das sehe ich auch so.

Viele Grüße

susejunky

 

[Christina]

(…) , dass das System sowohl im MBR- als auch im UEFI-Modus gestartet werden kann.

Ja, natürlich kann das diese Minimal-EFI-Firmware. Sonst wäre eine Installation und der Betrieb mit gpt-Disklabel unter MS-Windows gar nicht möglich.
Lies doch mal den von mir in #42 verlinkten Artikel.
Zudem schreibt @mojo :

(Anmerkung: bei der anschließenden Installation (von Linux Mint 21.3, Anm. Christina) auf dieser Partition wurde eine fehlende EFI-Partition angemeckert - ich musste also eine EFI-Partition per Hand anlegen, sonst hätte ich das Fenster nicht verlassen können).

•

Das System von @mojo scheint nun aber eine MBR-Partitionierung zu verwenden (…)

Wenn du damit ein dos- bzw. ein msdos-Disklabel meinst, das lässt sich leicht herausfinden:

@mojo zeige bitte:

/usr/sbin/fdisk -l | grep -i Disklabel

(Genau diese Angabe fehlt leider im bootinfoscript. Der Autor hielt das anscheinend für nicht notwendig.)

 

[josef-wien]

das lässt sich leicht herausfinden

Ganz oben in RESULTS.txt steht, daß core.img im Sektor 1 beginnt, daher muß es eine msdos-Partitionentabelle sein. Außerdem gibt das Skript bei einer GPT sowohl die msdos-Partitionentabelle als auch die GPT aus.

Disklabel

Das System von mojo spricht deutsch, und da heißt es Festplattenbezeichnungstyp.

 

[Christina]

Ja, und außerdem kennt eine GPT keine aktiven Partitionen. Auch daran hätte ich es sehen können. Peinlich!
Ich hatte das früher schon mal gelesen, aber inzwischen wieder ganz vergessen. Mit dem Thema muss ich mich wirklich intensiver befassen.

 

[susejunky]

Hallo @Christina ,

Ja, und außerdem kennt eine GPT keine aktiven Partitionen.

es gibt eine ganze Reihe von Anzeichen, anhand derer man vermuten kann, dass es sich um eine MBR-Partitionierung handelt:

• bootinfoscript würde eine GPT-Partitionierung explizit anzeigen
• normalerweise ist bei einer GPT-Partitionierung nicht genug Platz hinter dem MBR, um dort das core.img von GRUB2 abzulegen
• normalerweise legen die Installationsroutinen von Distributionen auf GPT-partitionierten Datenträgern eine BIOS-Boot-Partition an, um dort das core.img von GRUB2 abzulegen.
• normalerweise verwendet GRUB2 bei GPT-partitionierten Datenträgern in grub.cfg Bezeichnungen wie hd0,gpt1 und nicht hd0,msdos1

aber wenn man nicht direkt vor dem, vom Fehler betroffenen Gerät sitzt, besteht immer eine gewisse Unsicherheit. Und es besteht auch immer noch die Möglichkeit, dass man selbst etwas übersehen oder falsch eingeschätzt hat. Das versuche ich mit einer entsprechenden Ausdrucksweise in meinen Beiträgen zu vermitteln.

Ich denke es würde auch Dir gut stehen, wenn Du mit Deinen Beiträgen etwas zurückhaltender auftreten würdest.

Viele Grüße

susejunky

 

[Christina]

Da hast du recht. Ich stehe derzeit etwas unter Strom, weil ich wie letztes Jahr ein saisonales, sehr wichtiges Ehrenamt ausübe.
Linux Club - Support Forum für GNU/Linux - Ansehen, was du verpasst hast
Und wenn dadurch die Qualität der Hilfestellung darunter leidet, weil ich mir bei anspruchsvollen Themen die Infos nur noch flüchtig durchlese und dann falsche Rückschlüsse ziehe, dann ist es besser ich lege hier eine Pause ein.

Lg, Christina

 

[mojo]

@mojo zeige bitte:

/usr/sbin/fdisk -l | grep -i Disklabel

(Genau diese Angabe fehlt leider im bootinfoscript. Der Autor hielt das anscheinend für nicht notwendig.)

test@1810TZ:/usr/sbin$ sudo fdisk -l | grep -i Disklabel
test@1810TZ:/usr/sbin$