Ubuntu für absolute Anfänger...Fragen, Tips, Tricks, ...

Das sind schlicht patch-Versionen des 5.15er Ubuntu Kernels.
Höhere Nummer ist höherer patch-Stand
Es ist bei Ubuntu nicht wichtig den neuesten Kernel, den Linus veröffentlicht hat, zu haben, um auf den neuesten Sicherheitsstand zu sein.
(Außer man benötigt ein feature oder Devicetreiber, die der Distributionskernel nicht hat)
Sicherheitsrelevante Patches werden backportet.
Für neuere features gäbe es die HWE Kernel, die etwas neuer sind und auf zukünftige Releases ausgerichtet sind.
hi Tom,
Bitte was ist backportet?
Automatisch, muss ich da nichts machen oder wird mir das gemeldet? *noahnung*
Der Erklärung von @X_FISH aus https://forum.planet3dnow.de/index....fänger-fragen-tips-tricks.460344/post-5424423 ist nichts hinzuzufügen.
 
Dann sollte eigentlich nach dem Neustart des Rechners der folgende Befehl für eine dauerhafte Einbindung des erweiterten it87-Moduls sorgen:
Code:
sudo modprobe it87

... nach einem Kernel Upgrade müsstest Du dann nach meiner Einschätzung ggf. lediglich das Skript einmalig neu laufen lassen.
Nope, der Befehl lädt das Modul nur für den aktuellen Systemstart.
Für nachfolgende Starts ist der Befehl irrelevant. Dann werden die entweder automatisch vom Kernel geladen, oder von systemd auf Anweisung (das hatten wir ein paar Seiten vorher) oder gar nicht.

Und ja, nach einem Kernel Upgrade muss das Modul neu kompiliert werden, d.h. das Skript nochmals ausgeführt werden.
 
nach einem Kernel Upgrade muss das Modul neu kompiliert werden, d.h. das Skript nochmals ausgeführt werden.
Und das ist bei mir quasi nach jedem Neustart der Fall. Die Kiste läuft oft 24/7 , also ist in der Zwischenzeit auch oft mindestens ein neuer Kernel gekommen.
 
Nope, der Befehl lädt das Modul nur für den aktuellen Systemstart.
Ja, das hatte ich auch immer gedacht, hatte mich aber dann gewundert, dass in einem anderen Fall plötzlich ein Treibereintrag in "/etc/modules" mehrfach auftauchte nachdem derjenige zunächst mit modprobe den Treiber getestet und anschließend manuell zu "/etc/modules" hinzugefügt hatte ... ok, es könnte natürlich sein, dass der Eintrag versehentlich doppelt hinzugefügt wurde.
Wie auch immer ... das könnte man ja ausprobieren:
Code:
cat /etc/modules
sudo modprobe it87
cat /etc/modules
... wenn it87 in "/etc/modules" zunächst nicht vorhanden war, aber nach modprobe, hat modprobe den Eintrag gesetzt.
Andernfalls müsste der Eintrag manuell vorgenommen werden:
Code:
sudo xed /etc/modules
... und dann einfach Dateiende eine Zeile mit "it87" hinzufügen und speichern.

Jetzt sollte das Treibermodul auch nach einem Neustart automatisch geladen werden.

Gruß,
vnt
 
Nope, der Befehl lädt das Modul nur für den aktuellen Systemstart.
Ja, das hatte ich auch immer gedacht, hatte mich aber dann gewundert, dass in einem anderen Fall plötzlich ein Treibereintrag in "/etc/modules" mehrfach auftauchte nachdem derjenige zunächst mit modprobe den Treiber getestet und anschließend manuell zu "/etc/modules" hinzugefügt hatte ... ok, es könnte natürlich sein, dass der Eintrag versehentlich doppelt hinzugefügt wurde.
Ne, sowas macht modprobe nicht, außer du hast eine ungewöhnliche (modifizierte?) Version von modprobe. Die normale aus dem kmod Paket verhält sich jedenfalls nicht so.
Andernfalls müsste der Eintrag manuell vorgenommen werden:
Code:
sudo xed /etc/modules
... und dann einfach Dateiende eine Zeile mit "it87" hinzufügen und speichern.
Wenn es eh an das Dateiende soll, dann wäre
Code:
"echo "it87" >> /etc/modules
einfacher. ;)
(Aber vorsicht, dass es wirklich zwei > sind, sonst wird die Datei überschrieben.
 
enn es eh an das Dateiende soll, dann wäre
Code:
"echo "it87" >> /etc/modules
einfacher.
Bist Du sicher, dass "echo" zusammen mit "sudo" funktioniert? ... ich meine mich zu erinnern, dass ich diesbezüglich schon einmal Probleme hatte.

Hab's gefunden -> siehe Beitrag #241

Statt "xed" könnte man auch Folgendes machen:
Code:
echo "it87" | sudo tee -a /etc/modules
 
Zuletzt bearbeitet:
Hab ich nicht probiert, da ich eher su nutze. (Ja, die Vor- und Nachteile kenne ich zur genüge. ;))
Könnte schon sein, dass es nicht direkt damit funktioniert, weil es sich bei >> um eine Shellfunktion handelt, d.h. evtl. würde statt "it87" dann die Ausgabe von sudo echo ... in die Datei geschrieben (oder ggf. auch mit Fehler beendet).
Ich denke aber, es sollte funktionieren, wenn man eine Subshell nutzt, i.e.
Code:
sudo $(echo "it87" >> /etc/modules)

Ist aber auch wurscht, man kann ruhig auch einen Editor nutzen. Ist speziell für unerfahrene Nutzer sicher auch besser, denn man kann direkt noch kontrollieren, dass man es so drin stehen hat wie man will. Manche Editoren (i.e. kate) fragen auch automatisch nach elevated privileges, wenn notwendig.
d.h.
Code:
kate /etc/modules
sollte ebenso eine Passwortabfrage bringen wie sudo xed/vim/emacs/sonstigereditor.

Angeblich (nicht getestet) gibt es zudem auch noch
Code:
sudoedit /etc/modules
Welcher Editor dann verwendet wird weiß ich nicht, wahrscheinlich der, der in der Umgebungsvariable EDITOR gesetzt ist.
 
Zuletzt bearbeitet:
Ne, sowas macht modprobe nicht, außer du hast eine ungewöhnliche (modifizierte?) Version von modprobe.
Vermutlich hast Du recht und der Eintrag in "/etc/modules" wurde seinerzeit manuell versehentlich doppelt eingefügt ... kann ich aber nicht nachprüfen, da ich in dem besagten Fall seinerzeit auch nur Fernunterstützung geleistet hatte.

Jedenfalls freut mich unser Austausch über die verschiedenen Herangehensweisen, weil ich dadurch mein vorhandenes Wissen vertiefen und Kenntnisse erweitertern kann ... So machen Foren Sinn!

Gruß,
vnt
 
Ich mal wieder, mit einer anderen Baustelle.
In meinem Laptop ist eine 480GB SSD, die ich mal von der ursprünglichen 250GB SSD geklont und den freien Platz erweitert habe.
Nun wollte ich die Linux-Partition zurück-Clonen, damit ich für das geplante update von Ubuntu 18 auf 20 oder 22 notfalls eine bootfähige Reserve habe.
Das Clonezilla hat ohne Fehler sda5 auf sdb5 geclont. Nur konnte ich vom Ergebnis nicht booten (evtl. weil sdx4 unterschiedlich ist?). Es kam nur eine GRUB-Console mit der ich nichts anfangen konnte. Daher habe ich noch die sda1-Partition hinterhergeclont, ohne Besserung.
Also eine Live-DVD gebootet und nach dieser Anleitung einen Reparaturversuch gestartet: https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#chroot-Methode
Beim Punkt "sudo cp /proc/mounts /mnt/etc/mtab " kam die Meldung, dass beide Dateien identisch seien. Keine Ahnung, ob das was zu bedeuten hat.
Das einzige System, was danach im Grub zu sehen war, war aber Windows10. Ubuntu, Memtest etc. fehlte alles.

Jetzt habe ich wieder die zu clonende Ubuntu-Version gebootet und wollte auf Dateisystemebene mal schauen, ob und was da vielleicht beim Clonen nicht kopiert wurde. Aber es sieht identisch aus. In die Boot-Partition hab ich aber noch nicht geschaut, die lässt sich nicht mounten wegen angeblichem Windows-nicht-korrekt-heruntergefahren.
Wobei ich auch nicht weiß, ob die Boot-Partition wirklich als boot-Partition genutzt wird, weil auf der Ubuntu-Partition im Ordner /Boot/Grub jede Menge aktuelle Daten liegen, die ich mit dem Boot-Vorgang in Verbindung bringe.

So sieht es in GParted aus:
Original:
bildschirmfotovon202266fjx.png


Clone:
bildschirmfotovon2022l8d8u.png


Edit: Ich habe jetzt noch einmal grub repariert, aber ohne die boot-partition. Damit wurden nun auch die fehlenden Images eingebunden.

Bleibt für mich aber noch die Frage, warum das Clonen nicht mitsamt den Grub-Einträgen geklappt hat.
 
Zuletzt bearbeitet:
Das Clonezilla hat ohne Fehler sda5 auf sdb5 geclont. Nur konnte ich vom Ergebnis nicht booten (evtl. weil sdx4 unterschiedlich ist?). Es kam nur eine GRUB-Console mit der ich nichts anfangen konnte.
Ist denn die UUID der beiden Partitionen identisch?
Also eine Live-DVD gebootet und nach dieser Anleitung einen Reparaturversuch gestartet: https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#chroot-Methode
Beim Punkt "sudo cp /proc/mounts /mnt/etc/mtab " kam die Meldung, dass beide Dateien identisch seien. Keine Ahnung, ob das was zu bedeuten hat.
Das einzige System, was danach im Grub zu sehen war, war aber Windows10. Ubuntu, Memtest etc. fehlte alles.
Die Zeile mit dem cp /proc/mount… kannst du einfach weglassen. /etc/mtab ist heutzutage normalerweise ein symbolischer Link auf besagte Datei, entsprechend macht das einfach keinen Sinn.
Da ist Ubuntuusers etwas veraltet, leider heutzutage keine Seltenheit. :(

Ansonsten kann es schon sein, dass das clonen mit GRUB nicht so einfach funktioniert, weil EFI vermutlich keine UUIDs versteht.
d.h. ggf. musst du die GRUB Stage 1 und/oder Stage 1.5 anpassen, damit es auf die richtige Platte/Partition verweist.
Wenn zudem die UUIDs nicht übereinstimmen, dann müssen ggf. auch noch grub.cfg und fstab angepasst werden.
Ist aber alles kein Hexenwerk und normalerweise mit einer Live CD in max 30min erledigt.
 
Ob die UUID von Clonezilla mitkopiert wird, weiß ich nicht.
Aber letztendlich hat es mit grub-install ja doch noch funktioniert. Ob ich nun das mache oder irgendwelche anderen Anpassungen nötig sind, kommt dann wohl aufs Gleiche raus.
Doppelposting wurde automatisch zusammengeführt:

Verdammt, nach dem update auf 20.04LTS habe ich keinen Ton mehr. Weder über interne speaker noch über Kopfhörer noch über HDMI. Es tut aber so, als wären die Geräte vorhanden.
Nach einem Neustart tönt es wenigstens auf dem Bildschirm über DisplayPort. Egal, ob ich auf die Kopfhörer per Klinke oder Blauzahn umschalte, es tönt immer der Bildschirm. :(

Ich werde am besten gleich noch zu 22.04LTS weiterspringen und beten, dass der Sound dann wieder funktioniert.
 
Zuletzt bearbeitet:
Da würde ich mal kontrollieren, ob die richtigen Audioprofile für die Geräte ausgewählt sind. e.g. mit pavucontrol.
 
Da kann ich nichts Ungewöhnliches erkennen bzw. nichts Anderes einstellen.
bildschirmfotovom2022a6fnx.png

bildschirmfotovom202238itd.png
 
Ich werde am besten gleich noch zu 22.04LTS weiterspringen und beten, dass der Sound dann wieder funktioniert.
Meiner Meinung nach würde es tatsächlich Sinn machen, jetzt direkt das Upgrade auf 22.04 LTS durchzuführen, bevor Du irgendwelche Anpassungen an 20.04 LTS vornimmst, da nach meiner Erfahrung ein Upgrade immer mit einem gewissen Maß an Nacharbeiten verbunden ist. Wenn Du also jetzt direkt den Schritt auf 22.04 LTS gehst, hast Du die Nacharbeiten nur einmal und zusätzlich das aktuellere System ... und den Sound bekommen wir dann mit Sicherheit auch zum Laufen.

Gruß,
vnt
 
Update ist durch. Nun hab ich 22.04.
Das Sound-Problem besteht nun nur noch, wenn ich in den Klang-Einstellungen auf "Lautsprecher testen" gehe. Dann kommt es immer am Bildschirm raus, egal was ich wähle. Aber Youtube-Videos geben den Ton an der ausgewählten Stelle aus.
Nebenbei laufen nun Youtube-Videos in Full-HD mit 60fps ruckelfrei und ohne einen brüllenden CPU-Lüfter. Offenbar hat sich da bei den Videocodecs etwas getan und die laufen nun endlich auf der iGPU und nicht mehr auf den CPU-Kernen. :)
Hätte ich schon eher machen sollen.
4K ist aber immer noch ruckelig auf dem intel der 4. Generation.
 
Update ist durch. Nun hab ich 22.04.
*greater*

Das Sound-Problem besteht nun nur noch, wenn ich in den Klang-Einstellungen auf "Lautsprecher testen" gehe.
Ich halte es für durchaus denkbar, dass Altlasten der Soundkonfiguration hier eine Rolle spielen, weshalb ich Dir folgendes Vorgehen empfehlen würde:
Code:
pactl info
... falls Deine Installation PulseAudio als Soundserver nutzt, setze bitte die Konfiguration zurück:
Code:
mv ~/.config/pulse ~/.config/pulse-backup
pulseaudio -k
... sollte PulseAudio nun - warum auch immer - nicht automatisch neu gestartet werden, gib bitte folgenden Befehl ein:
Code:
systemctl --user restart pulseaudio.service

Funktioniert die Soundausgabe jetzt fehlerfrei?
Falls nein, gib bitte folgenden Befehl im Terminal ein und kopiere die Ausgabe vollständig hierher in Deine Antwort:
Code:
pactl list

Weitere Informationen zu PulseAudio findest Du hier: https://wiki.ubuntuusers.de/PulseAudio/

Gruß,
vnt
 
Zuletzt bearbeitet:
Code:
pulseaudio -k
... sollte PulseAudio nun - warum auch immer - nicht automatisch neu gestartet werden, gib bitte folgenden Befehl ein:
Code:
systemctl --user restart pulseaudio.service
Warum nicht einfach direkt systemctl --user restart …?
Das schießt dir pulseaudio genauso ab.
 
... falls Deine Installation PulseAudio als Soundserver nutzt, setze bitte die Konfiguration zurück:
Code:
mv ~/.config/pulse ~/.config/pulse-backup
pulseaudio -k
Danke, das hat geholfen!
 
Benutzt hier eigentlich Jemand zenpower3 als Basis für zenmonitor3 ?
Ersteres spuckt mir noch mehr Sensordaten aus als k10temp.
zenpower-pci-00c3
Adapter: PCI adapter
SVI2_Core: 957.00 mV
SVI2_SoC: 1.09 V
Tdie: +60.5°C (high = +95.0°C)
Tctl: +60.5°C
Tccd1: +59.0°C
Tccd2: +59.5°C
SVI2_P_Core: 62.81 W
SVI2_P_SoC: 11.59 W
SVI2_C_Core: 64.56 A
SVI2_C_SoC: 10.59 A

Problem: Das tut es nur direkt nach der Installation gemäß https://github.com/Ta180m/zenpower3
Nach dem Neustart wollte ich es dann erneut mit
sudo modprobe -r k10temp
sudo modprobe zenpower
starten, nur passiert einfach nichts, Sensors findet dann nix. Deinstallation und Neuinstallation (wie im Abschnitt update instructions) helfen zwar, aber ist doch etwas umständlich (ich teste gerade mit verschiedenen Bios-Einstellungen den Verbrauch)
Doppelposting wurde automatisch zusammengeführt:

Auf dem Nvidia-System probier ich das dann nächste Woche auch noch. Kann ich einfach 2 Befehle hintereinander in so eine unit packen? Bei AMD brauchts ja eine ganze Menge Befehle, für Nvidia sind das nur 2 - dann kann ich mir das separate .sh sparen.
Jein. Man kann Wege finden das hinzubekommen, allerdings ist es nicht so richtig so gedacht. Zum Einen kannst du es einfach in eine Shell packen, also z.B.:
ExecStart=/bin/bash -c 'progA; progB; progC'
(Alternativ auch mit && statt ; dann würde progB nicht ausgeführt, falls progA mit Exitcode ungleich 0 beendet.)
Das wäre dann im Grunde das gleiche wie deine .sh, nur halt in der Datei integriert.

Andererseits könnte man bei 2 Befehlen einen quasi als "Befehl vor dem Befehl" interpretieren, d.h.
ExecStartPre=progA
ExecStart=progB

ExecStartPost gäbe es auch noch.
Der Nachteil bei diesen Varianten ist, dass systemd nicht tracken kann, ob das noch läuft oder nicht, denn im ersten Fall wird ja /bin/bash als das Programm des service angesehen und im zweiten Fall nur progB. Das ist aber in deinem Fall (für eine oneshot unit) nicht so kritisch, da die Programme nach Ablauf ja eh beenden und nicht weiterlaufen.

Für "richtige" Serviceprogramme würde ich aber eher auch 2 service Dateien erstellen, so wie es z.B. auch für smbd und nmbd gemacht wird (die ja beide zu Samba gehören).

Übrigens, wenn du die Programme über den Paketmanager installiert hast, würde ich auch mal nachschauen, ob da nicht evtl. sogar schon service Files mitgeliefert werden, denn das ist relativ häufig sogar der Fall.

Ich habe das nun auf dem Nvidia-System probiert: (erst mit oneshot, dann simple) - funktioniert allerdings nicht.
[Unit]
Description=Nvidia Bremse 100W

[Service]
Type=simple
ExecStartPre=nvidia-smi -pm 1
ExecStart=nvidia-smi -pl 100

[Install]
WantedBy=multi-user.target
Ich kann es manuell mit sudo systemctl start nvidia-limit nach dem Booten starten. Aber während des Boot-Vorgangs bewirkt es nichts.
Ich hab es auch mit nur einer Zeile und sudo ( ExecStart=sudo nvidia-smi -pm 1 && sudo nvidia-smi -pl 100 ) probiert, keine Änderung.
Kann es sein, dass der Service zu früh ausgeführt wird und da der Nvidia-Treiber noch gar nicht geladen ist?

Nächster Versuch war, beide Befehle in eine .sh Datei zu packen und diese aufzurufen:
[Unit]
Description=Nvidia Bremse 100W

[Service]
Type=simple
ExecStart=/home/magiceye/nvidia-bremse.sh

[Install]
WantedBy=multi-user.target
Da klappt nicht mal das manuelle Ausführen des Dienstes, obwohl ich manuell die .sh Datei starten kann und sie macht dann, was sie soll.
log file:
ez 30 18:56:26 3950-3070 systemd[1]: Starting Nvidia Bremse 100W...
Dez 30 18:56:26 3950-3070 systemd[5185]: nvidia-limit.service: Failed to execute command: Exec format error
Dez 30 18:56:26 3950-3070 systemd[5185]: nvidia-limit.service: Failed at step EXEC spawning /home/magiceye/nvidia-bremse.sh: Exec format error
Dez 30 18:56:26 3950-3070 systemd[1]: nvidia-limit.service: Main process exited, code=exited, status=203/EXEC
Dez 30 18:56:26 3950-3070 systemd[1]: nvidia-limit.service: Failed with result 'exit-code'.
Dez 30 18:56:26 3950-3070 systemd[1]: Failed to start Nvidia Bremse 100W.
Jetzt bin ich erst mal ratlos.
 
Zuletzt bearbeitet:
Füge mal noch die After und die modprobe Zeile ein, siehe:
Code:
After=multi-user.target
Wants=modprobe@amdgpu.service
amdgpu dann eben auf den Modulnamen von dem nividia Modul ändern.

Wenn du es so startest wie von dir angegeben, dann hat das ja keine Abhängigkeiten, d.h. es wird gleich zu Beginn ausgeführt und evtl. ist da wirklich das Modul noch nicht verfügbar, oder irgendwelche Funktionen des Moduls, keine Ahnung.
 
Es gibt zumindest ein Service-Modul mit diesem Namen.
Heute boote ich aber nicht mehr.
 
also ihr seid echt die Linux-Helden des Jahres in m. Augen! :o
Das darf schon mal ganz nüchtern gesagt werden ohne jemandem schmeicheln zu wollen oder die anderen guten Beiträge hinten runterfallen lassen zu mögen...
Denn Ehre, wem Ehre gebührt - zum Ausgang des Jahres!

Meinen Linux-Helden jedenfalls mit ein, zwei weiteren - sowie allen anderen:

Kommt gut rüber ins neue Jahr und genießt mal die eher ruhigen Tage zum Wechsel noch!
Mit besten Wünschen aus 2022 direkt ins neue Jahr hinein getragen!

und ein super-großes DANKE! für alle Zeit und teils sehr persönliches und überaus freundliches Engagement von euch!

*party**party2**greater**party2**party**old*

.....

Euer Micha
 
Zurück
Oben Unten