glaskugel
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
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
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
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.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
~# 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
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 11172
|
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
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
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.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
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".
- Bilder
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 11172
|
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
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
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.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5142
|
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
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
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.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
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.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5142
|
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
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5142
|
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
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
+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.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3472
|
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
|