Linux Installationsfehler bitte Hilfe?

3 Antworten

Vom Fragesteller als hilfreich ausgezeichnet

Scheint ein bekanntes Problem zu sein, passiert aber offenbar nur beim Booten von DVD oder USB-Stick. Versuch mal das Paket mit dem Paket Manager zu installieren.

Karamellpopcorn 
Fragesteller
 17.04.2021, 02:23

Ok! Du meinst das gibt sich mit der Installation dann? Da wäre toll. Beim Abschalten kommt nämlich auch failed to unmount /cdrom - könnte sein dass alles mit dem stick zu tun hat

also der fehler ist komplett unbedenklich? ich habe dann wichtige dateien drauf, will sicher sein.

0
Karamellpopcorn 
Fragesteller
 18.04.2021, 01:05
@HarryXXX

Könnte es was damit zu tun haben, dass mein Computer für Windows ausgelegt ist und für Linux nicht ganz so geeignet?

0
ewigsuzu  18.04.2021, 03:13
@Karamellpopcorn

Nein. Da Linux überall funktioniert. Kein PC ist für Win explizit geschaffen, zum min keiner für Endbenutzer.

0
HarryXXX  18.04.2021, 03:15
@Karamellpopcorn

Das denke ich nicht. Soweit ich das nachlesen konnte tritt es nur bei Mint auf und da nur bei bestimmten Versionen.

1
ewigsuzu  18.04.2021, 03:15
@Karamellpopcorn

Weil Linux eben kein geschlossenes System ist, das sind ums einfach zu sagen bugs.

0

setz den LogLevel auf 2, dann hast du deine ruhe
- in der grub Kernelzeile als systemd.log_level, oder auch in /etc/sysctl.conf (kernel.printk) 

Karamellpopcorn 
Fragesteller
 17.04.2021, 02:24

Was genau bewirkt das mit dem LogLevel? Verdeckt es die Message nur oder löst es das Problem?

Wo finde ich die grub Kernelzeile? muss ich dafür zurück zu windows und mir den stick anschauen?

0
xxfistexx  17.04.2021, 02:37
@Karamellpopcorn

das bewirkt das du die Fehlermeldung nicht mehr bekommst.

Das Überprüfen der auf dem System verwendeten Standardprotokollierungsebene ist sehr einfach. Dazu muss lediglich der Inhalt der Datei /proc/sys/kernel/printk überprüft werden.

/proc ist ein virtuelles Dateisystem: Die darin enthaltenen Dateien befinden sich nicht tatsächlich auf der Festplatte, sondern sind visuelle Repräsentationen des Systemzustands, die vom Kernel erstellt und im Speicher gehalten werden. 

$ cat /proc/sys/kernel/printk

Dies ist die typische Ausgabe des Befehls:

4 4 1 7

Der erste Wert in der Ausgabe ist der aktuelle console_loglevel. Der Wert, in diesem Fall 4, repräsentiert den aktuell verwendeten Loglevel. Wie bereits erwähnt, bedeutet dies, dass nur Meldungen, die einen höheren Schweregrad als diesen annehmen, auf der Konsole angezeigt werden.

Der zweite Wert in der Ausgabe stellt den default_message_loglevel dar. Dieser Wert wird automatisch für Nachrichten ohne einen bestimmten Loglevel verwendet: Wenn eine Nachricht keinem Loglevel zugeordnet ist, wird dieser für sie verwendet.

Der dritte Wert in der Ausgabe gibt den Status minimum_console_loglevel an. Er gibt den minimalen Loglevel an, der für console_loglevel verwendet werden kann. Der hier verwendete Level ist 1, der höchste.

Der letzte Wert schließlich stellt das default_console_loglevel dar, welches das Standard-Loglevel ist, das für console_loglevel zur Boot-Zeit verwendet wird.

Der Vollständigkeit halber muss gesagt werden, dass die gleichen Informationen auch mit dem Befehl sysctl abgerufen werden können, indem man ihn ausführt:

$ sysctl kernel.printk

Die einfachste Methode, die man verwenden kann, ist, den neuen Wert in die Datei /proc/sys/kernel/printk zu schreiben. Dies ist jedoch eine temporäre Lösung, und die neue Einstellung bleibt bei einem Neustart des Rechners nicht erhalten. Angenommen, man möchte temporär den Standard-Loglevel der Konsole auf 3 ändern, dann würde man folgendes ausführen:

$ echo "3" | sudo tee /proc/sys/kernel/printk

Um den Standard-Loglevel dauerhaft zu ändern, muss die Datei /etc/default/grub geändert werden, indem der Parameter loglevel beim Booten an die Kernel-Befehlszeile übergeben wird:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="Konsole"
GRUB_CMDLINE_LINUX="loglevel=3 resume=UUID=df5a0685-43f8-433a-8611-57335a10ca8d"
GRUB_DISABLE_RECOVERY="true"
1
Karamellpopcorn 
Fragesteller
 17.04.2021, 03:04
@xxfistexx

Danke wow für diese ausführliche Antwort!!! Das ist sehr nett von dir!

1.) Habe ich die Grundidee richtig verstanden? Die Änderungen der Loglevel sind eine rein kosmetische Angelegenheit und zeigen eben nur noch Fehlermeldungen an, die schwerer Natur sind? Sonst gar nichts? Wenn es nur kosmetisch ist, wäre mir das denn Aufwand nicht wert.

2.) Lassen sich diese Änderungen nach der Installation nachträglich vornehmen? Oder nur vor Installation? Also das was du da alles vorschlägst.

3.) Im Internet habe ich mittlerweile diese Anleitung gefunden, was hältst du von der? Post 2, also die erste Antwort:

https://forums.linuxmint.com/viewtopic.php?p=1836169#p1836169

LG und danke nochmal für die große Mühe!

0
xxfistexx  17.04.2021, 03:30
@Karamellpopcorn
  • 1) ja, es bezieht sich in erster Linie auf kosmetische Effekte, die den Bootvorgang durch Syslevel-Timeouts zum "humanen" Debuggen von schnell laufenden Systemen beschleunigen können. (z. B. wird mein System in 0,00375 ns gebootet und hat keinen Platz für verbose.messages)
  • 2) ja klar, im zweiten Teil wird beschrieben, wie man das "temporäre" Abbild des Kernels an anderer Stelle dauerhaft darin implementieren kann, man muss das System nur einmal mit diesem logLevel booten.
  • die im Link vorgeschlagene "Kosmetik" bezieht sich auf die Modifikation des Kernels. Eine empfehlenswertere und effektivere Methode ist jedoch ein Update des Bios, wenn das Problem dauerhaft besteht.
  • 3) die verlinkte Antwort bezieht sich darauf, dass der Kernel nachträglich modifiziert und für den nächsten Neustart angepasst wurde. Eine Anpassung, erfolgt entweder während des Bootvorgangs durch entsprechende Parameter, die an den Bootloader übergeben werden, oder durch eine Modifikation des Bootmanagers im laufenden System > für den nächsten Neustart.
1
Karamellpopcorn 
Fragesteller
 17.04.2021, 04:28
@xxfistexx

Vielen Dank! Die Option während des laufenden System gefällt mir besser! Bootloader modifizieren macht mir angst xD

0
xxfistexx  17.04.2021, 04:30
@Karamellpopcorn

das kombiniert sich aber beides ineinander.

aus meiner sicht ist es manchmal sehr viel effektiver, ein linux/unix system fehlerfrei neu auf zu ziehen, als es nach einer laufzeit zu reparieren.

ich empfehle dir weiterhin, ein bios update zu machen in diesem zusammenhang

1
Karamellpopcorn 
Fragesteller
 17.04.2021, 04:34
@xxfistexx

Ok ich werde das sowieso erst ab morgen machen und bis dahin etwas darüber nachdenken

0

acpi=off

Woher ich das weiß:Hobby
Karamellpopcorn 
Fragesteller
 18.04.2021, 03:28

Toll und dann geht dafür wieder was anderes nicht

0
Ploppy8888  18.04.2021, 04:07
@Karamellpopcorn

Toll, Grub bezieht sich nur auf den Bootvorgang, was das Betriebssystem hinterher macht ist eine ganz andere Geschichte.

0