Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
25.10.2020, 03:47:38

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
  • Mitglieder insgesamt: 24683
  • Letzte: xenior
Statistiken
  • Beiträge insgesamt: 690499
  • Themen insgesamt: 55894
  • Heute online: 507
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online
Mitglieder: 2
Gäste: 298
Gesamt: 300

Autor Thema:  UEFI-BIOS Fehlerhafter Installationablauf?  (Gelesen 1606 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #15 am: 01.09.2020, 19:38:47 »
Ob der immensen Fülle deiner Informationen glaube ich dennoch herausgelesen zu haben, das dir zumindest die Grundinstallation von Mint 20 inzwischen gelungen ist. Dann reiche doch bitte inxi -Fz nach, wie es @Bernibär bereits in Antwort #3 angeregt hat...

Alter Mann

  • Gast
Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #16 am: 02.09.2020, 11:07:14 »
Moin,

Hier die aktuelle inxi Ausgabe.

System:
  Kernel: 5.4.0-45-generic x86_64 bits: 64 Desktop: Cinnamon 4.6.7
  Distro: Linux Mint 20 Ulyana
Machine:
  Type: Desktop Mobo: ASRock model: 970 Pro3 R2.0 serial: <filter>
  UEFI: American Megatrends v: P2.80 date: 05/31/2016
CPU:
  Topology: Quad Core model: AMD Phenom II X4 840 bits: 64 type: MCP
  L2 cache: 2048 KiB
  Speed: 1900 MHz min/max: 800/3200 MHz Core speeds (MHz): 1: 1900 2: 800
  3: 800 4: 2500
Graphics:
  Device-1: NVIDIA GM107 [GeForce GTX 750] driver: nouveau v: kernel
  Display: x11 server: X.Org 1.20.8 driver: modesetting unloaded: fbdev,vesa
  resolution: 1920x1200~60Hz, 1920x1200~60Hz
  OpenGL: renderer: NV117 v: 4.3 Mesa 20.0.8
Audio:
  Device-1: AMD SBx00 Azalia driver: snd_hda_intel
  Device-2: NVIDIA GM107 High Definition Audio [GeForce 940MX]
  driver: snd_hda_intel
  Sound Server: ALSA v: k5.4.0-45-generic
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
  driver: r8169
  IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 1.13 TiB used: 25.07 GiB (2.2%)
  ID-1: /dev/sda vendor: Patriot model: Burst size: 223.57 GiB
  ID-2: /dev/sdb vendor: Samsung model: HD103SJ size: 931.51 GiB
Partition:
  ID-1: / size: 218.57 GiB used: 25.07 GiB (11.5%) fs: ext4 dev: /dev/sda2
Sensors:
  System Temperatures: cpu: 15.8 C mobo: N/A gpu: nouveau temp: 35 C
  Fan Speeds (RPM): N/A
Info:
  Processes: 206 Uptime: 3m Memory: 7.75 GiB used: 1.20 GiB (15.5%)
  Shell: bash inxi: 3.0.38

Der Ablauf für diese Installation den ich jederzeit wiederholen kann auch mit anderen laufwerken, war folgender: Nachdem ich den Rechner nur mit dem DVD Laufwerk gestartet hatte, habe ich das Bios erfolgreich "überredet" sich wie ein UEFI Bios zu verhalten. Danach habe ich ein leeres SSD Laufwerk und das Speicherlaufwerk angeschlossen, neu gestartet , das Bios überprüft und LMC 20 installiert, aus an, alles funktioniert 1A, das BIOS bliebt bei UEFI. CSM war Aktiv und die Optionen darunter auf UEFI gestellt.

Dann habe ich aktualisiert. Neustart, nix ging mehr. Monitor an aber sw,, ein/aus, Reset, keine Reaktion. Netz aus +an , dann F2. Das BIOS war völlig verstellt, eben auf Standard BIOS, das als Laufwerke  Ubuntu, AHCI1 Patriot und AHCI DVD anzeigte. F10, der Versuch EFI von Startlaufwerk(Ubuntu) zu laden schlug fehl, dann via F1+ F11 LW AHCI Partiot (das Ubuntu laufwerk) ausgewählt. Rechner startet im BIOS Mode anstandslos, die Partiot wird hochgefahren und als UEFI Platte gestartet, unter "ubuntu" die selbe Platte nicht zu starten.
 
Neustart geht nicht, ich kann nur herunter fahren und mit F1+F11 manuell starten. Lasse ich den Rechner ein paar Stunden im Standby, muss ich das Netz aus/einschalten, um ihn wieder starten zu können. Ja, die CMOS Batterie ist neu und secure Boot aus.

Gedanken dazu : Während die Erstinstallation von der DVD mit dem BIOS klar kam (die EFI wird auf der DVD mit Apple bezeichnet), wurden wohl bei der Installation Flags gesetzt, die dazu führen, das bei einer Änderung der zum Start notwendigen Dateien (jetzt mit einem auf MS Technik basierenden EFI) im BIOS falsch gespeichert werden und zwar so falsch, das das BIOS dabei auf Werkseinstellung zurückgesetzt wird. Ich vermute dieses , weil das LW nicht unter seiner Bezeichnung "ubuntu" starten kann, sondern nur als AHCI LW.

Sicher man kann es sich einfach machen und dem BIOS den Fehler zuschreiben, nur dann bleibt die Frage warum es ohne Updates und mit dem ersten Kernel funktioniert hat. Mir macht die Initramfs, die soweit ich weiß für die Installation der UEFI Einstellungen zuständig ist Sorgen. Sollte die falsch gespeichert sein, oder falsche Pfade den Zugang verhindern, was hier anscheinend der Fall ist, wäre das verhalten erklärbar.

Da beim starten als BIOS AHCI Laufwerk keine Fehlermeldung kommt wäre der Startvorgang so erklärbar: Der Rechner starte im BIOS, ruft das Laufwerk auf, dort steht der der richtige Pfad abweichend von der normalen UEFI Bootroutine und verweist auf die notwendigen Startdateien auf der Festplatte. Diese werden nun gestartet und überschreiben still und leise das geladene BIOS. das nun UEFi wird und startet. Da die Initramfs vor der Grafik geladen wird kommen so regelmäßigen Fehlermeldungen da wohl auch der falsche Grafiktreiber geladen wird. Das könnte vieles erklären, was hier im Forum von USERN nachgefragt wird.

Wenn dem so ist, gibt es erhebliche Probleme mit dem bei auf Windows Technik basierendem Startvorgang, der aber im Grunde zu umgehen ist in dem UEFI nachrangig ausschließlich vom Laufwerk gestartet wird, sowie es bei mir anscheinend der Fall ist. Bleibt die Frage der Sicherheit, die könnte sicher auch via Software gelöst werden. Fakt ist da es zu viele und unterschiedliche ältere BIOS Versionen gibt, die mit alter UEFI Technik Probleme haben, insbesondere wohl auch durch CSM. Darum bedarf es einer grundsätzlichen Lösung, mit der auch Newbies zurechtkommen, um auf 64BIT Linux Systeme umzustellen, ohne erst die möglichen Fehler nach ellenlangen Diskussionen in Foren via Terminal zu beheben oder entnervt aufzugeben. Wichtig ist das die Systeme stabil laufen. Wenn der Sicherheitsstandard von UEFI via BIOS nicht funktioniert, dann liegt es am USER zu entscheiden, ob er das will oder nicht. Da die alten BIOS angreifbar waren, ändert sich nichts, nur das eben eine neuere Technik (UEFI) verwendet wird.

Spielen kann man heute online im Browser, Filme gucken geht und wer Windows verliebt ist kann sich ja ne Xbox kaufen, Speicher, Prozessoren als das ist heute keine Leistungshürden mehr. Ein 240GB Festplatte kostet weniger als sich mit Anpassungen rum zu ärgern.   

Wer Linux betreibt will auch weg von Kostendruck durch Apple und MS.       
   

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #17 am: 02.09.2020, 12:01:43 »
Problem mit Englisch? ;) "except" heißt "ausgenommen"... Demnach sollte seine 840er passen.

Alter Mann

  • Gast
Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #18 am: 10.09.2020, 12:39:44 »
Auch wenn es so scheint das einige mit dem Thema nichts anfangen können, ich anscheinend ja kein Ahnung habe, hier die Ursache meiner Probleme. Initramfs in Verbindung mit dem Kernel.

Ich habe nun Folgende Installation:

System:
  Host: cord-desktop Kernel: 5.4.0-47-generic x86_64 bits: 64
  Desktop: Cinnamon 4.4.8 Distro: Linux Mint 19.3 Tricia
Machine:
  Type: Desktop Mobo: ASUSTeK model: M5A78L-M PLUS/USB3 v: Rev X.0x
  serial: <filter> BIOS: American Megatrends v: 0502 date: 11/18/2016
CPU:
  Topology: 8-Core model: AMD FX-8320 bits: 64 type: MCP L2 cache: 2048 KiB
  Speed: 1406 MHz min/max: 1400/3500 MHz Core speeds (MHz): 1: 1406 2: 1406
  3: 1406 4: 1405 5: 1406 6: 1470 7: 1406 8: 1394
Graphics:
  Device-1: NVIDIA GM107 [GeForce GTX 750] driver: nvidia v: 440.100
  Display: x11 server: X.Org 1.19.6 driver: nvidia
  unloaded: fbdev,modesetting,nouveau,vesa
  resolution: 1920x1200~60Hz, 1920x1200~60Hz
  OpenGL: renderer: GeForce GTX 750/PCIe/SSE2 v: 4.6.0 NVIDIA 440.100
Audio:
  Device-1: AMD SBx00 Azalia driver: snd_hda_intel
  Device-2: NVIDIA driver: snd_hda_intel
  Sound Server: ALSA v: k5.4.0-47-generic
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
  driver: r8169
  IF: enp4s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 689.33 GiB used: 83.76 GiB (12.2%)
  ID-1: /dev/sda vendor: Intenso model: SSD SATAIII size: 223.57 GiB
  ID-2: /dev/sdb vendor: Western Digital model: WDS500G1B0A-00H9H0
  size: 465.76 GiB
Partition:
  ID-1: / size: 219.06 GiB used: 83.76 GiB (38.2%) fs: ext4 dev: /dev/sda1
Sensors:
  System Temperatures: cpu: 31.0 C mobo: 30.0 C gpu: nvidia temp: 29 C
  Fan Speeds (RPM): cpu: 974 case-1: 0 gpu: nvidia fan: 33%
Info:
  Processes: 241 Uptime: 1h 35m Memory: 7.76 GiB used: 1.81 GiB (23.4%)
  Shell: bash inxi: 3.0.32

das LW ist eines das ich vor dem ganzen Theater funktionierend bei Seite gelegt habe und mit Recatux 0.73 Grub repariert habe, nachdem mein altes MB sich nicht mehr installieren ließ. Alle Versuche eine neues Linux, egal ob auf Ubuntu oder Debian Basis zu installieren schlugen fehl.

Die Fehlerursachen liegen im Kernel. Dieser enthält einen Grafiktreiber "nouveau" der dazu dient schon beim Start die best mögliche Auflösung zu bieten. Leider hat man bei der Ḱompalierung keinen Einfluss darauf was der macht. Der zu verwendende Grafiktreiber wird gespeichert in der initramfs während der Installation nachgeladen.

Nur geht das nicht zusammen. Der Nouveau Treiber im Kernel verhindert dieses. Bereits bei Start kommen teilweise Fehlermeldungen das der Novuveau Treiber nicht oder fehlerhaft geladen wurde, die initramfs nicht geladen werden kann.

Anmerkung : In älteren Installationsroutinen wurde der proprietäre Grafiktreiber und andere bereits vor der Installation geladen. Dieses "Vorladen" beschränkt sich in neueren Installationen auf Video Codex.   

Dieser Ablauf und auch die Nutzung von UEFI führen im Zusammenhang zu erheblichen Problemen, in Grafik und auch Sound. Mein altes Board hatte keinen onbord Grafikchip, so das nur die GRAKA installiert werden konnte. Mein jetziges hat einen ADM Radeon 3000chip und eine Nvidia GTX 750. Unter Debian war es echt eine Krux, dauernd hing sich die Grafik auf, egal was ich installierte. Die Ursache der nouveau hatte die GRAKA gar nicht richtig erkannt. So konnte er auch nicht die richtigen Pakete laden, weil Pfade fehlten, was unter anderem auch zu Endlosschleifen in der xsessions-error führte, die schnell anwuchs.

Eine Installation des aktuelle 458 Treibers von der Nividia Seite schlag fehl, weil diesem Abhängigkeiten fehlten, die der nouveau so nicht geladen hatte.

Auch eine Neuinstallation von LMC 19.3 schlug fehl weil auch dort mittlerweile die Installationsroutine geändert wurde und proprietäre Treiber nicht mehr von der Installation geladen werden. Auch merkwürdig ist das die HDMi Anschlüsse zu S/Pdif in den neueren Installationen interpretiert werden selbst wenn das Board über keine solchen Anschlüsse verfügt. Das Bluetooth, Smartcard und Batterieüberwachung installiert werden sollen obwohl nicht vorhanden, ist schon merkwürdig. All das kann man xsessions entnehmen, wo diese Fehler angezeigt werden, die man ja ignorieren soll. Das die  Datenübertragung extrem langsam ist bis 1 MB gegenüber 250MB/sek ist zu normal? Das sich die automatische Partitionierung bei der Installation komplett verändert hat, das offensichtlich nur noch 2 Partitionen genutzt werden (Boot und ext4) und bisherige boot/efi, swap, /Home und / mit aktuellen Gparted in der Installation nicht mehr angelegt werden können. All das passiert nur mir?

Lese ich die Hilfeersuchen anderer USER, so finde ich deutliche Parallelen. Da wohl auch in ältere Kernels diese "Neuerungen" einfließen sind davon auch ältere Versionen betroffen, die gestern noch liefen. Wobei nicht auszuschließen ist das bestehende Konfigurationen noch laufen. Neue Festplatte? Dann wars das. Neue Kernelversion kann, muss aber nicht.

Ich habe 4 Jahre alte Boards mit AM3+ Sockeln und unterschiedlichen Bios wie Award und AMi. Was aber nun wenn diese Bios nicht wie den Voraussetzungen der Installation auf neueren AM4 Boards entsprechen? Oder aber Updates des Kernels völlig andere nicht portierbare Voraussetzungen erfordern und dann nicht mehr sauber laufen? Auf "Sicherheitsupdates" verzichten?

Wer das nachvollziehen will sollte von folgenden Voraussetzungen ausgehen. Bestehendes Am3+ Board, aktuelles Bios, leere Festplatte nur Partitioniert und neue ISO frisch runtergeladen. Ich habs getestet unter mit alten ISOs von LMC 16.4+18.4 sowie aktuellem von 19.3 +20, Ubuntu 20.4 und KDE Debian 10.5 und zwar sooft, das wenn ich die ganzen Konstellationen und Fehlermeldungen aufführen sollte, ein Jahr nicht ausreichen würde. Aber Achtung, es besteht die Gefahr das Board so zu schrotten das hinterher nichts mehr geht! Schuld daran sind individuelle Epproms des Boards die man nicht gezielt wieder überschreiben kann, aber offensichtlich überschrieben wurden, so das diese selbst unter WIN7 nicht mehr erkannt werden bzw. keine Treiber laden können. Komisch nur, das mit früheren Versionen(Kernels) das alles noch lief.
 
Fazit: Linux hat ein strukturelles Kernelproblem, verursacht durch Techniken, die nicht mehr den Vorraussetzungen älterer Rechner entsprechen oder von diesen umgesetzt werden können.

Anmerkung: Das es bei dir anders ist, weiß ich und ehrlich es interessiert überhaupt nicht. Es sei denn du erklärst, wie du das auf einem AM3+ Board mit neuer Installation als reinen Linuxrechner, unter welchem Bios Einstellungen mit Hersteller und Version hinbekommen hast. Alles andere ist stochern im Nebel.

Geschrottetes Board ASRock 970 Pro3 R.2.0 mit AMD Pentium 840 und Nvidia GTX750, aktuelles siehe oben.


   
 
 
.     

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #19 am: 10.09.2020, 15:40:30 »
Hi :)
ich würde ja gern helfen.. nur deine romane tue ich mir nicht an ;)

Alter Mann

  • Gast
Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #20 am: 10.09.2020, 16:55:32 »
ich würde ja gern helfen.. nur deine romane tue ich mir nicht an

Taja, so ist das eben, wenn man versucht möglichst genau Fehler und bisheriges zu beschreiben, um zu verhindert das man hier wieder bei Null anfängt. Und wenn man dann Veränderungen feststellt, heißt es ja man hat keine Ahnung... oder hat irgendwer die Installationsroutinen mal nachvollzogen? Was wenn es nur dann auftritt? Sich dutzende Problem hier aus dieser ergeben? Was nützen dann bitte Ratschläge aus laufenden modernen Systemen mit neuer Hardware? Ist es nicht das herausstechende Merkmal von Linux auf alter Hardware zu laufen? Was zu der Frage führt warum eine alte Installation läuft, die gleiche LMC19.3 aktuell als ISO runtergeladen auf sich aber auf dem selben Rechner mit gleicher Bioseinstellung, aber nicht mehr fehlerfrei installieren lässt? 


Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #22 am: 10.09.2020, 17:45:14 »
Hi :)
ich würde ja gern helfen.. nur deine romane tue ich mir nicht an ;)
Die Länge der Posts ist nicht das eigentliche Problem.
Aus dieser sprachlichen Konfusität, dieser mäandernde Melange aus Beobachtungen, Vermutungen und Interpretationen, lässt sich nur schwer ein Erkenntnisgewinn erzielen.

Was nützen dann bitte Ratschläge aus laufenden modernen Systemen mit neuer Hardware? Ist es nicht das herausstechende Merkmal von Linux auf alter Hardware zu laufen?
Das ist zutreffend und hat sich auch nicht geändert.

Fazit: Linux hat ein strukturelles Kernelproblem, verursacht durch Techniken, die nicht mehr den Vorraussetzungen älterer Rechner entsprechen oder von diesen umgesetzt werden können.

Was jetzt die Grundsatzfrage aufwirft ist Linux im 64Bit Modus unter UEFI noch ein freies oder ein von Microsoft abhängiges Betriebssystem. Bleibt es eigenständig, wobei auch die Chance für alle Distros genutzt werden sollte aus dem Treiberdilemma herauszukommen? 

OK, du schaffst es also nicht, eine LM 19.3 ISO fehlerfrei zu installieren.
Wie kommst du dann aber von diesem mutmaßlich hausgemachten Problem auf solch abwegige „Grundsatzfragen“?  Die Existenz von „Treiberdilemma und strukturellen Kernelproblemen von Linux“ hast du ebenfalls nicht nachvollziehbar darlegen können.
Falls deine "Grundsatzfrage" auf Secure Boot abzielt, empfehle ich den Wikipedia-Artikel zu UEFI
Ein Auszug daraus:
Zitat
Notwendig wurde Shim, da viele Mainboardhersteller in ihren UEFI-Implementierungen ausschließlich Signaturen für Microsoftprodukte mitliefern und die Installation benutzereigener Signaturen auf ihrer Hardware, z. B. für die Installation eines Linux-Kernels, nicht oder zumindest nicht allein mit den UEFI-Bordmitteln möglich ist. Praktisch alle aktuellen Linux-Distributionen verwenden Shim, um auf Rechnern mit eingeschaltetem Secure Boot zu starten.
https://de.wikipedia.org/wiki/UEFI

« Letzte Änderung: 10.09.2020, 18:20:42 von Parmenides »

Alter Mann

  • Gast
Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #23 am: 10.09.2020, 18:27:24 »
Frage, warum sieht dann die Partition meines laufenden LM19.3 Systems, trotz erfolgter manueller Partitionierung nach der Installation wie im Bild Anhang aus?






Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #24 am: 10.09.2020, 19:04:07 »
hat irgendwer die Installationsroutinen mal nachvollzogen?
Sicher jeder, der sich ein LinuxMint installiert hat.
In der Regel mit Erfolg.

Alter Mann

  • Gast
Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #25 am: 10.09.2020, 20:30:12 »
Ich hab das eben nochmals mit einer anderen Platte und LMC 20 ISO getestet. Wieder das gleiche. Ist die Ursache der Rtl8111H für den ein Treiber Rtl8169 installiert wird? Die installierte Version scheint fehlerhaft, was im nachfolgendem Link genauso beschrieben wird.

https://www.linuxquestions.org/questions/linux-hardware-18/realtek-rtl8111-8168-8411-ethernet-controller-r8168-driver-install-r8169-driver-doesn%27t-work-4175641982/

Was passiert nun genau?
In der Installationsbeschreibung
https://www.linuxmintusers.de/index.php?action=wiki;page=Installationsanleitung_Linux_Mint_20
(hier unterscheidet sich diese von der LMc19.3)
werden zunächst die Video Codec geladen (Bild LM20 06). Ohne das secure boot eingeschaltet ist entfällt Bild 20 07. Dann aber erscheint Bild 20 08 nicht. Bricht nun die Lan und auch Wlan Verbindung ab oder aber ist secure boot, zwingende Voraussetzung das Bild 20 08 erscheint? Ohne das ein Laden der proprietären Treiber, wie in Bild zu sehen nicht möglich ist. 

Die für die Konfiguration von nouveau offensichlich notwendigen proprietären Treiber werden also nicht geladen. Auch die Initramfs scheint betroffen. 

Woran das nun liegt und welche Folgen daraus genau entstehen lässt hat sich nur vermuten.


   

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #26 am: 10.09.2020, 20:45:36 »
Secure Boot hat nichts mit Bild LM20 08 zu tun.

Zitat
Mit unter erscheint folgende Mitteilung auf dem Bildschirm.

Es könnte ein Betriebssystem auf der HDD/SSD sein, welches nicht im UEFI - Mode installiert ist.
Diese Meldung kommt aber auch, wenn auf der HDD/SSD keine EFI - Partition gefunden wurde,
bzw. zwar eine EFI - Partition vorhanden ist aber die Flag's boot, esp nicht gesetzt wurden.
Man kann, wenn man sich sicher ist mit "Im UEFI-Modus fortfahren" die Installation fortsetzen.
Es sollte jedoch beachtet werde, das alle System auf der HDD/SSD die nicht im UEFI - Mode
installiert sind nicht über Grub gestartet werden können.

Edit: Das Bild LM20 07 ist noch aus der Beschreibung LM 19.X
Es war mir erst heute bei einer Neuinstallation von LM 20 Cinnamon auf einer neuen 2 TB SSD
mit Secure Boot auf einem Lenovo ThinkPad T440p möglich diese Bilder zu erstellen,
da Secure Boot in einer VM nicht möglich ist

Die Bilder zu Secure Boot unter LM 20 befinden sich derzeit ganz am Ende der Beschreibung.
« Letzte Änderung: 10.09.2020, 20:54:14 von tommix »

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #27 am: 10.09.2020, 20:52:41 »
Frage, warum sieht dann die Partition meines laufenden LM19.3 Systems, trotz erfolgter manueller Partitionierung nach der Installation wie im Bild Anhang aus?
Vllt., weil du nach erfolgter Partitionierung dann den Installer im Automatikmodus hast machen lassen? ;)

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #28 am: 10.09.2020, 20:58:02 »
Schade ist, das man die Flägs in dem Bild nicht sieht.

Frage, warum sieht dann die Partition meines laufenden LM19.3 Systems, trotz erfolgter manueller Partitionierung nach der Installation wie im Bild Anhang aus?
Vllt., weil du nach erfolgter Partitionierung dann den Installer im Automatikmodus hast machen lassen? ;)

Oder bei manueller Partitionierung die gezeigten Standartwerte genutzt wurden.

Re: UEFI-BIOS Fehlerhafter Installationablauf?
« Antwort #29 am: 10.09.2020, 22:08:40 »
Die für die Konfiguration von nouveau offensichlich notwendigen proprietären Treiber werden also nicht geladen.
Beziehst du dich damit auf Abbildung 20 08?
Aber welche proprietären Treiber sollen das sein, die für den nouveau notwendig sein sollen?
Ich glaube, da unterliegst du einem Denkfehler.

Der nouveau ist ein quelloffener Treiber, der als Alternative zu den proprietären Nvidia-Treibern angeboten wird. Du als Anwender kannst entscheiden, welchen Graka-Treiber du installierst.