staging.inyokaproject.org

Ist es empfehenswert den PC neu zu installieren, wenn man im Bios von CSM auf UEFI ohne Secure Boot umstellt und nur Ubuntu installiert ist?

Ich habe extrem merkwürdiges Verhalten schon gleich nach dem Einschalten, bevor Ubuntu überhaupt startet und kann mir gut eine Bios-Einstellung als Problem vorstellen.

Wenn der Rechner bootet, dann funktioniert alles. Betonung auf "Wenn", vgl. https://forum.ubuntuusers.de/topic/zusammenhang-zwischen-uefi-und-monitorerkennun/

Es ist gerade neu mit CSM installiert, aber auch aufwendig konfiguriert, sonst würde ich es einfach probieren und mit UEFI installieren.

Wenn ich mich entschliesse neu zu installieren, macht es dann Sinn im Bios auf Secure Boot zu stellen? IMHO ist das ja eine reine Windows-Sache, oder?

Jedenfalls finde ich efi-Dateien nach der CSM-Installation:

~# find / -iname "*.efi"
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/shimx64.efi
/boot/efi/EFI/ubuntu/mmx64.efi
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/BOOT/mmx64.efi
/boot/grub/x86_64-efi/core.efi
/boot/grub/x86_64-efi/grub.efi
find: ‘/run/user/1000/gvfs’: Keine Berechtigung
find: ‘/run/user/115/gvfs’: Keine Berechtigung
/snap/core20/1852/usr/lib/systemd/boot/efi/systemd-bootx64.efi
/snap/core20/1879/usr/lib/systemd/boot/efi/systemd-bootx64.efi
/snap/core18/2721/usr/lib/systemd/boot/efi/systemd-bootx64.efi
/snap/core18/2745/usr/lib/systemd/boot/efi/systemd-bootx64.efi
/usr/lib/grub/x86_64-efi/monolithic/gcdx64.efi
/usr/lib/grub/x86_64-efi/monolithic/grubnetx64.efi
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
/usr/lib/shim/fbx64.efi
/usr/lib/shim/mmx64.efi
/usr/lib/shim/shimx64.efi
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

Hallo!

Eine Neuinstallation ist nicht unbedingt nötig, je nachdem wie du vorher installiert hast. Bei einem echten BIOS wäre das MBR auf ms-dos-Partition → Dann Neuinstallation mit EFI/gpt. Wenn du bereits gpt verwendest, kannst du einfach die grub-„Schummelpartition“ (k.a. wie sie heisst 😉 ) als EFI verwenden und entsprechend umformatieren. Diese wird ja nur bei CSM gebraucht, um gpt für den klassischen Ansatz lesbar zu machen.

Der langen Rede kurzer Sinn: sudo parted --list würde helfen.

btw: SecureBoot kannst du verwenden, musst du aber nicht. Ist eh Schlangenöl, da der neue Angriffsvektor für Hinterlistigkeiten das UEFI selbst ist. Damit kannst du dann auch SecureBoot aushebeln.

~# parted --list
Modell: ATA WDC WD20EARS-00S (scsi)
Festplatte  /dev/sda:  2000GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name  Flags
 1      1049kB  2000GB  2000GB  xfs


Modell: ATA ST12000NM0007-2A (scsi)
Festplatte  /dev/sdb:  12,0TB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name  Flags
 1      1049kB  12,0TB  12,0TB  xfs


Modell: ATA XA960ME10063 (scsi)
Festplatte  /dev/sdc:  960GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem     Name                  Flags
 1      1049kB  2097kB  1049kB                                        bios_grub
 2      2097kB  540MB   538MB   fat32           EFI System Partition  boot, esp
 3      540MB   101GB   100GB   xfs
 4      101GB   251GB   150GB   xfs
 5      251GB   356GB   105GB   xfs
 6      356GB   511GB   155GB   xfs
 7      511GB   921GB   410GB   xfs
 8      921GB   960GB   39,7GB  linux-swap(v1)                        swap


Modell: ATA ST6000VN0021-1ZA (scsi)
Festplatte  /dev/sdd:  6001GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem     Name  Flags
 1      1049kB  150GB   150GB   xfs
 2      150GB   250GB   100GB   xfs
 3      250GB   1150GB  900GB   xfs
 4      1150GB  5600GB  4450GB  xfs
 5      5600GB  5750GB  150GB   xfs
 6      5750GB  5995GB  245GB   xfs
 7      5995GB  6001GB  6175MB  linux-swap(v1)        swap


Modell: ATA ST6000VN0021-1ZA (scsi)
Festplatte  /dev/sde:  6001GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name  Flags
 1      1049kB  2400GB  2400GB  xfs
 2      2400GB  5760GB  3360GB  xfs
 3      5760GB  6001GB  241GB   xfs


Modell: SanDisk Ultra Luxe (scsi)
Festplatte  /dev/sdf:  30,8GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 1      1049kB  30,8GB  30,8GB  primary  fat32

Das System ist also auf sdc.

# df -HT | sort | grep sdc
/dev/sdc2      vfat   537M    6,4M  531M    2% /boot/efi
/dev/sdc3      xfs    100G     27G   74G   27% /
/dev/sdc4      xfs    150G    2,2G  148G    2% /home
/dev/sdc5      xfs    105G    766M  105G    1% /distri2
/dev/sdc6      xfs    155G    1,2G  154G    1% /distri2_home
/dev/sdc7      xfs    410G    2,9G  407G    1% /render

Hej glaskugel,

glaskugel schrieb:

... Es ist gerade neu mit CSM installiert, aber auch aufwendig konfiguriert, sonst würde ich es einfach probieren und mit UEFI installieren.

stell' einfach mal den Bootmodus im UEFI um auf EFI (only), ich möchte wetten, da startet das Ubuntu (im EFI Modus).

ubiquity installiert nämlich ungefragt beide Modi, wenn man keine Eingriffe macht, sprich, "Platte löschen und Ubuntu installieren" oder so ähnlich.

Gruß black tencate

black_tencate schrieb:

stell' einfach mal den Bootmodus im UEFI um auf EFI (only), ich möchte wetten, da startet das Ubuntu (im EFI Modus).

Da geh ich mit… EFI ist installiert, nix mit BIOS MBR/ms-dos.

stell' einfach mal den Bootmodus im UEFI um auf EFI (only)

Das Mobo ist von der Bezeichnung etwas eigenartig. Da gibt es nur was für Windows.

Ich weiß nicht was ich da einstellen soll, siehe die 3 Screenshots.

ich möchte wetten, da startet das Ubuntu (im EFI Modus).

Ubuntu startet ja (meistens). Kann man irgendwie erkennen, ob im UEFI-Modus gestartet wurde?

$ sudo dmidecode -t0 |grep -Ei "(BIOS boot|EFI)" 
		BIOS boot specification is supported
		UEFI is supported

Es geht also nicht darum, ob es nach einer Umstellung im Bios / CSM starten kann, sondern ob die CSM-Installation Problem für die Monitorerkennung sein kann und eine Neuinstallation was bringen könnte.

Ich verzweifle, in der Regel sehe ich nach 24h kein Login mehr mit der Auffälligkeit, dass schon kein Mobo-Splashscreen kommt. Und mir kommt wieder der Verdacht auf, dass irgendwas bei der Mobo Konfiguration nicht stimmt. Manches ist sehr versteckt. Vielleicht liegt es daran, dass der Monitor mit dem Legacy-Mode des Bios nicht klar kommt und deswegen habe ich auf UEFI umgestellt. früher gab es ja mal "fastboot".

Hej glaskugel,

glaskugel schrieb:

stell' einfach mal den Bootmodus im UEFI um auf EFI (only)

Das Mobo ist von der Bezeichnung etwas eigenartig. Da gibt es nur was für Windows.

Dein snapshot_06 bietet doch eine Auswahl? UEFI (in gelber Schrift) CSM (in weißer), das sollte man umschalten können.

...Kann man irgendwie erkennen, ob im UEFI-Modus gestartet wurde?

ja, mit

 [ -d /sys/firmware/efi ] && echo UEFI || echo "CSM/legacy" 

im Terminal

...ob die CSM-Installation Problem für die Monitorerkennung sein kann und eine Neuinstallation was bringen könnte.

k. A., aber eher unwahrscheinlich!

Gruß black tencate

Dein snapshot_06 bietet doch eine Auswahl?

Ja schon, aber oben stand

stell' einfach mal den Bootmodus im UEFI um auf EFI (only)

Das habe ich nicht als Auswahl.

Ich habe mit CSM installiert und nach der Installation auf UEFI umgestellt. Viel mehr kann ich im Bios nicht mahcen, außer bei Secure Boot gibt es da noch was oder sonst irgendwo versteckt.

~#  [ -d /sys/firmware/efi ] && echo UEFI || echo "CSM/legacy" 
UEFI

k. A., aber eher unwahrscheinlich!

Da der Splash-Screen vom Mobo immer wieder fehlt, früher ab und zu, nun alle 24h und es damit dann auch kein Login gibt, habe ich echt ein Problem. Ich habe schon einen teuren Asus Pro Art 32" durch einen neueren Pro Art getauscht, jedes Mal über 1k. Wäre einfach blöd, wenn es "nur" an einer Bios-Einstellung liegt.

Wenn ich den Thread also richtig verstehe, dann bringt eine Neuinstallation mit Secure Boot eher nichts. Keine Ahnung wie kaputt mein Bios ist. Am Anfang war die Linux-Installation abenteuerlich beim Erkennen der Geräte (HDD / SSD / Brenner). Dieser Bug ist lt. History behoben.

Hallo,

wie alt ist denn das Board? Bzw. zeig mal die Ausgabe von

journalctl -b -k --grep="EFI v" 

Damit kann man die EFI-Version - nicht zu verwechseln mit der Firmware-Version) Deines Boards anzeigen lassen.

Wenn das ein UEFI < = 2.3.1 (eventuell auch als 2.31 angezeigt ist), dann ist das ein Board aus der "UEFI-Anfangsphase", da gibt es dann häufig noch Ungereimtheiten. Bei einem UEFI dieser Generation würde ich bei reiner Ubuntu-Ntuzung CSM bevorzugen.

Die ganze Ausgabe von

sudo dmidecode -t0 -t1 -t2 

würde in dem Fall nicht schaden. Dann weiß man auch, um was für ein System das ist. Falls da irgendwelche Seriennummern in der Ausgabe sein sollten, kannst Du diese ja unkenntlich machen.

LG, Newubunti

wie alt ist denn das Board?

https://geizhals.de/msi-mpg-x570-gaming-pro-carbon-wifi-7b93-001r-a2078277.html#data Gelistet seit 17.06.2019

Das älteste Bios zum Download: https://de.msi.com/Motherboard/MPG-X570-GAMING-PRO-CARBON-WIFI/support AMI BIOS 7B93v10 2019-06-20

$ journalctl -b -k --grep="EFI v" 
Mai 20 02:25:54 sv kernel: efi: EFI v2.70 by American Megatrends

nicht zu verwechseln mit der Firmware-Version)

Dazu siehe auch angehängte Screenshots und Text davor. FW ist aktuell.

würde ich bei reiner Ubuntu-Ntuzung CSM bevorzugen.

Das hatte ich ja schon und damit die Probleme. Ich bin jetzt von CSM auf UEFI umgestiegen und auch von DP auf HDMI. Kabel sind hochwertig. Eben gab es nach dem Einschalten 3 blaue Screens mit HDMI 1 nicht gefunden. Der Monitor war im Standbye, hat sich irgendwann ausgeschaltet und irgendwann wieder eingeschaltet und der Login war da. Wenn ich jetzt beim Monitor schaue, dann sehe ich das via HDMI 1 verbunden sein soll. Kann ich das unter Linux verifizieren, ob ich wirklich an HDMI 1 hänge?

https://dlcdnets.asus.com/pub/ASUS/LCD%20Monitors/PA329C/PA329C_German.pdf?model=PA329C Das HDMI-Kabel ist direkt neben dem Netzwerkkabel eingesteckt, sollte also HDMI-1 sein, aber es dauert eben bis die blauen Screens verschwinden, entweder da wird neu gestartet oder gesucht. Ich sehe in der Anleitung nichts, dass die Quelle automatisch gesucht wird, wo was angesteckt ist.

Womit ich wieder bei den Bios-Einstellungen bin. Vielleicht passen die "optimized defaults" nicht bzw. die A-XMP Einstellung nicht. A-XMP soll nur das RAM-Timing beeinflussen. Handbuch https://download.msi.com/archive/mnu_exe/mb/E7B93v1.4.pdf

Ich kann gerne auch wieder mit DP-Port testen. Vermutlich dauert es 1 Tag bis der Monitor nicht mehr erkannt wird. Hat es gerade funktioniert, dann ist ein Umstecken von HDMI auf DP bzw. umgehert problemlos. Ähnlich ist es, wenn ich einen anderen (kleineren) Monitor anstecke

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
	Vendor: American Megatrends International, LLC.
	Version: 1.J0
	Release Date: 05/10/2023
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 32 MB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
		Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
		5.25"/360 kB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 5.17

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Micro-Star International Co., Ltd.
	Product Name: MS-7B93
	Version: 1.0
	Serial Number: To be filled by O.E.M.
	UUID: c8b...
	Wake-up Type: Power Switch
	SKU Number: To be filled by O.E.M.
	Family: To be filled by O.E.M.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Micro-Star International Co., Ltd.
	Product Name: MPG X570 GAMING PRO CARBON WIFI (MS-7B93)
	Version: 1.0
	Serial Number: J816xxxxxxx
	Asset Tag: To be filled by O.E.M.
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: To be filled by O.E.M.
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Grafikkarte: MSI GeForce GTX 1660 ARMOR 6G OC Aktiv PCIe 3.0 x16 1xHDMI / 3xDisplayPort (Retail) https://de.msi.com/Graphics-Card/GeForce-GTX-1660-ARMOR-6G-OC

Kann man vielleicht die Grafikkarte flashen? https://de.msi.com/Graphics-Card/GeForce-GTX-1660-ARMOR-6G-OC/support

Angeblich muss für ältere Nvidia-Grafikkarten die Graka geflasht werden, damit DP funktioniert. Vgl. https://www.nvidia.com/en-us/drivers/nv-uefi-update-x64/ Meine Karte ist aber neuer als Maxwell und Pascal. Das ist eine Turing glaube ich.

Newubunti schrieb:

journalctl -b -k --grep="EFI v" 

+1 für die Verwendung der dafür vorgesehenen Bordmittel 😉

me@desktop[~]› journalctl -b -k --grep="EFI v"
May 19 15:18:36 desktop kernel: efi: EFI v2.31 by American Megatrends
me@desktop[~]› 

Ich kann bestätigen, das diese Version sehr „eigen“ ist. USB3 ist zu der Zeit auch noch wackelig gewesen. Bei meinem verhält es sich aber andersrum, bei Legacy funktioniert nichts richtig, bei EFI klappts. (Letztes UEFI-Update gab es 2012, da kommt also auch nix mehr).

Was die Monitorgeschichte angeht, mal ganz blöd gefragt: Liefert das Stromnetz denn genug Leistung? Der PC und aktuelle, fette Grafikkarten brauchen beim Start zunächst mal so viel Strom wie ein Raketenstart — deine Graka geht bis Spitze 450W. Da das Problem sporadisch auftritt, könnten andere Geräte zu der Zeit aktiv sein? Das ist ja immer nur kurz bei der Initialisierung so mit dem Energievampirismus. Wasserkocher sollten also nicht am selben Sicherungskreis laufen, während du den PC anwirfst 😉

Ansonsten würde ich versuchen auf DaisyChain umzustellen, also DisplayPort Monitor 1 in 2, 2 dann in die Grafikkarte (DP1.2 darf nur an einem Bildschirm aktiv sein). Das hat bei meiner AMD-Karte Wunder gewirkt. DP ist aber auch kein Allheilmittel.

Nachtrag: Dein PC-Netzteil muss natürlich auch entsprechend dimensioniert sein und eine maximale Leistungsaufnahme aller Komponenten gewährleisten.

glaskugel schrieb:

wie alt ist denn das Board?

https://geizhals.de/msi-mpg-x570-gaming-pro-carbon-wifi-7b93-001r-a2078277.html#data Gelistet seit 17.06.2019

Das älteste Bios zum Download: https://de.msi.com/Motherboard/MPG-X570-GAMING-PRO-CARBON-WIFI/support AMI BIOS 7B93v10 2019-06-20

$ journalctl -b -k --grep="EFI v" 
Mai 20 02:25:54 sv kernel: efi: EFI v2.70 by American Megatrends

Ok, das ist ja dann ein relativ neues Board. Da fallen UEFI-Kinderkrankheiten als Ursache aus.

Das Board ist halt eins der Sorte "Featuritis". Ich muss aber auch dazu sagen, dass meine praktische Erfahrung mit solchen Boards unter Linux nicht groß ist. Auch bei dezidierten Grafikkarten bin ich Erfahrungs-technisch raus.

Bei so fetten Boards hast Du halt in der Regel einen Haufen Einstellmöglichkeiten. Dementsprechend gibt es ein größeres Potential für werksseitige Fehlfunktionen und man kann sich da halt leicht verkonfigurieren.

Grundsätzlich würde ich bei Deiner Hardware zunächst mal nach bekannten Problemen suchmaschineln.

Außerdem würde ich auch mal das GRUB-Menü sichtbar machen, um zu sehen, ob das auch schon nicht angezeigt wird oder nicht. Also:

sudoedit /etc/default/grub.d/zz_custom.cfg 

und dort die beiden Zeilen rein:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10

Eventuell noch den Splash-Screen vorläufig deaktivieren (siehe auch GRUB 2/Konfiguration). Kannst Du aber auch dann temporär aus dem GRUB-Menü machen - falls es angezeigt würde.

Dem Monitor die richtige Quelle fest zuweisen wäre auch von Vorteil - falls möglich.

Falls das alles nichts bringt, dann würde ich im Firmwaresetup mal gucken, was sich da Grafikkarten-mäßig so alles einstellen lässt und dort dann mit möglichst konservativen Einstellungen beginnen.

würde ich bei reiner Ubuntu-Ntuzung CSM bevorzugen.

Das hatte ich ja schon und damit die Probleme.

Also bei einem Board wie Du es hast, würde ich grundsätzlich auch eher UEFI bevorzugen. Das mit dem CSM betrifft in der Regel nur die 2.3.1-Generation.

Du kannst auch mal in den Kernel-Meldungen gucken, ob die Umschaltung von UEFI-Grafik auf den Nvidia-Treiber sauber stattfindet. Ich würde aber dort eher nicht das Problem vermuten.

Alle EFI-relevanten Kernelmeldungen bekommst Du mit:

journalctl -b -k --grep="efi" --no-pager 

Alle Kernelmedlungen dann einfach ohne grep also:

journalctl -b -k --no-pager 

Ansonsten zu weiteren Filtermöglichkeiten auch journalctl.

Viel mehr kann ich zu dem Thema nicht beisteuern, weil wie gesagt bei der Art der verwendeten Hardware zu wenig praktische Erfahrung.

LG, Newubunti

ChickenLipsRfun2eat schrieb:

me@desktop[~]› journalctl -b -k --grep="EFI v"
May 19 15:18:36 desktop kernel: efi: EFI v2.31 by American Megatrends
me@desktop[~]› 

Ich kann bestätigen, das diese Version sehr „eigen“ ist. USB3 ist zu der Zeit auch noch wackelig gewesen. Bei meinem verhält es sich aber andersrum, bei Legacy funktioniert nichts richtig, bei EFI klappts. (Letztes UEFI-Update gab es 2012, da kommt also auch nix mehr).

OT: Ja, diese frühe Version hält einen bunten Strauß an "Problem-Überraschungen" für den Anwender bereit. OT-ENDE

LG, Newubunti

+1 für die Verwendung der dafür vorgesehenen Bordmittel

Ich tendiere stark dazu, dass Linux nichts für die Probleme kann. Wenn es "richtig" startet, dann macht Ubuntu keine Probleme.

Bei meinem verhält es sich aber andersrum, bei Legacy funktioniert nichts richtig, bei EFI klappts.

Genau deswegen bin auch auf UEFI umgestiegen, leider ohne Erfolg. Könnte aber sein, dass es mit HDMI ein anderes Problem ist, Inwieweit da Sceure Boot damit zu tun hat, kann wohl nur MSI sagen. Logisch ist es ja nicht. Vielleicht sollte ich es doch probieren mit Secure Boot zu installieren und schauen wie es dann funktioniert. Ein paar Tage gab es ja nach der Jammy-Neuinstallation und DP-Port auch keine Probleme. Insofern alles Glückssache.

Mobo-Hanbduch: https://download.msi.com/archive/mnu_exe/mb/E7B93v1.4.pdf

Vielleicht mag ja wer ins Habdbuch schauern und findet irgendwo was, das die Monitorerkennung betrifft. Letztlich gibt es aber mehr Optionen als im Handbuch beschrieben.

Mich plagt mittlerweile ein anderer Gedanke, vielleicht ist es eine Monitoreinstellung. Handbuch: https://dlcdnets.asus.com/pub/ASUS/LCD%20Monitors/PA329C/PA329C_German.pdf?model=PA329C Der Vorgänger-Monitor verhielt sich genauso an diesem PC und auch an einem älteren PC. Allerdings ist es erst in letzter Zeit so extrem, dass ich kein Login sehe. Zumindest nach ein paar Reboots gab es irgendwann ein Login.

Ich sehe da nur die Auwahl eines bestimmten Ports, aber nirgends eine Einstellung, dass nach anderen Quellen gesucht werden soll. Diese 3 blauen Screens könnten aber bedeuten, dass die 3 HDMI-Ports durchprobiert werden. Vielleicht kann man den Scan irgendwie unterbinden und den Input fixieren.

Das Booten dauert ziemlich lang, war unter 20.04 viel schneller. Gibt es da eine einfache Methode festzustellen, was lange dauert? Ich erinnere mich, da gibt es eine grafische Darstellung des Bootverlaufs, weiß aber nicht mehr, was das war. Edit: Glaube das war bootchart.

Es sind so viele unlogische Dinge passiert, die spare ich mir mal.

Sollte eine CSM-Installation mit Umstellung im Mobo auf UEFI und Secure Boot noch starten?

Mindestens 1x konnte ich mich mit HDMI am Monitor noch mit aktiviertem Secure Boot einloggen. Umkonfiguriert habe ich gar nichts, immer nur Reboots gemacht. Irgendwann blieb es bei "HDMI1 no signal" hängen und ich kam nicht mal mehr ins Bios über Del. Erst mit einem Nec und DP-Port statt dem Asus mit HDMI war es dann vorerst problemlos.

Mit UEFI und Secure Boot Standard versuche ich nun mit NEC/DP Xubuntu installieren. Der NEC hat kein HDMI, nur DVI: Das Grub Menü des Xubuntu-USB-Sticks wurde angezeigt, aber dann blieb es lila, keine Aufforderung irgendwas einzugeben, auch nicht nach Minuten.

Also steckte ich im laufenden Betrieb auf den 32" Asus mit HDMI um und siehe da, da war die Abfrage nach dem Land oder der Sprache bin mir nicht mehr sicher, jedenfalls lief die Testinstallation nach dem Umstecken weiter. Da wurde ich nach einem noch nie angegebenen Secure Boot PW gefragt, ohne PW ging es nicht weiter. Mal schauen, ob es durchläuft. Ich habe nicht meine normale Partionierung verwendet, sondern ließ die Installation die ganze SSD automatisch partitionieren.

Ich wiederhole die für mich wesentliche Frage, darf das System mit Secure Boot im Bios hochfahren, wenn dies bei der Installation nicht verwendet wurde? Irgendwann gab es dann kein Login mehr, aber es war der XFCE-Hintergrund sichtbar. Über die Konsole ohne X konnte ich mich immer anmelden.

Ergänzung: Es geht abenteuerlich weiter, aber nun kommt wieder Ubuntu ins Spiel.

Die unbeaufsichtigte Installation dam 32" mit HDMI ging schief. Als ich zurückkam, wurde der Monitor nicht mehr gefunden und es gab nur einen blauen Screen. Keine Ahnung, ob die Installation fertig gemacht wurde oder nicht. Keine Chance mit HDMI, aber nun funktionierte es via DP sofort Während der Installation passte ich auf, dass der Bildschirm nicht ins Standbye ging und ich kam bis zum Ende.

Bei der Installation hatte ich angegeben, dass die Nvidia-Treiber installiert werden, das verlangt dann das Secure PW.

Nach dem 1. Reboot sah ich ganz kurz das Login und dann war es weg. Die Situation hatte ich ja auch schon vor der Neuinstallation. Ich habe ein Update über die Konsole gemacht, reboot und nun gibt es auch ein Login. Aber es fehlt das Standard XFCE-Desktop, es gibt nur den Standard Lila-Desktop-Hintergrund.

rm -r ~/.cache/

löst das Problem nicht.

Außerdem würde ich auch mal das GRUB-Menü sichtbar machen

Bei der Neuinstallation gemacht Zur Zeit bootet der PC aber, mal sehen was in ein paar Stunden ist.

Alle Kernelmedlungen dann einfach ohne grep also:

Sehr lang, aber in rot fällt auf:

blacklist: Problem blacklisting hash (-13)

Villeicht sieht hier jemand was:

$ sudo journalctl -b -k --grep="efi" --no-pager 
Mai 21 04:01:54 sv kernel: efi: EFI v2.70 by American Megatrends
Mai 21 04:01:54 sv kernel: efi: ACPI=0xccbe2000 ACPI 2.0=0xccbe2014 TPMFinalLog=0xccbac000 SMBIOS=0xcd9fd000 MEMATTR=0xc86a7018 MOKvar=0xcda29000 RNG=0xcb0d4018 TPMEventLog=0xc7846018 
Mai 21 04:01:54 sv kernel: efi: seeding entropy pool
Mai 21 04:01:54 sv kernel: Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
Mai 21 04:01:54 sv kernel: clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
Mai 21 04:01:54 sv kernel: pci 0000:2f:00.0: BAR 1: assigned to efifb
Mai 21 04:01:54 sv kernel: Registered efivars operations
Mai 21 04:01:54 sv kernel: efifb: probing for efifb
Mai 21 04:01:54 sv kernel: efifb: showing boot graphics
Mai 21 04:01:54 sv kernel: efifb: framebuffer at 0xd0000000, using 34560k, total 34560k
Mai 21 04:01:54 sv kernel: efifb: mode is 3840x2160x32, linelength=16384, pages=1
Mai 21 04:01:54 sv kernel: efifb: scrolling: redraw
Mai 21 04:01:54 sv kernel: efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Mai 21 04:01:54 sv kernel: fb0: EFI VGA frame buffer device
Mai 21 04:01:54 sv kernel: EFI Variables Facility v0.08 2004-May-17
Mai 21 04:01:54 sv kernel: integrity: Loading X.509 certificate: UEFI:db
Mai 21 04:01:54 sv kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
Mai 21 04:01:54 sv kernel: integrity: Loading X.509 certificate: UEFI:db
Mai 21 04:01:54 sv kernel: integrity: Revoking X.509 certificate: UEFI:dbx
Mai 21 04:01:54 sv kernel: integrity: Revoking X.509 certificate: UEFI:dbx
Mai 21 04:01:54 sv kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
Mai 21 04:01:54 sv kernel: tsc: Refined TSC clocksource calibration: 3599.999 MHz
Mai 21 04:01:54 sv systemd[1]: Starting Load Kernel Module efi_pstore...
Mai 21 04:01:54 sv kernel: pstore: Registered efi as persistent store backend
Mai 21 04:01:54 sv systemd[1]: modprobe@efi_pstore.service: Deactivated successfully.
Mai 21 04:01:54 sv systemd[1]: Finished Load Kernel Module efi_pstore.
Mai 21 04:01:55 sv kernel: fb0: switching to nouveau from EFI VGA