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

Ich ergänze noch was zu meinem Posting hier:

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

Ich habe da Ubuntu Mate 20LTS drauf mit 5.4er Kernel. Ich bin eigentlich froh, dass damit und einem passenden AMDGPU-Treiber OpenCL auf der RadeonVII problemlos in allen Projekten funktioniert. Aber vermutlich brauche ich einen neueren Kernel, damit die Sensoren erkannt werden oder? Auch...
forum.planet3dnow.de forum.planet3dnow.de

Es gibt auch noch neofetch

1670774009552.png

Weil's so schön bunt ist wird das gerne auf Screenshots vom Desktop verwendet. Die Angabe zum Kernel ist optisch auch etwas ansprechender. ;)

Grüße, Martin
 
Ich hatte nun schon 2x einen Freeze nach weniger als 12 Stunden.
Aktuell läuft wieder der alte Kernel und das schon über 24h.
Also womöglich werde ich den neuen Kernel wieder entfernen.
Notfalls tausche ich eben den 3950X und den 5950X.
 
Was muss ich tun, damit der neue Kernel wieder deinstalliert wird?

sudo apt remove linux-generic-hwe-20.04 scheint nicht zu reichen, er taucht weiterhin im GRUB auf und ich traue mich auch nicht, wieder normal zu starten, sondern wähle weiterhin den alten Kernel 5.4....135 aus, damit nicht ein halb deinstallierter 5.15 irgendwas zerschießt.
 
update-grub

Falls das nicht reicht:

grub-mkconfig > grub.cfg
Diese grub.cfg kannst Du dann auf die alte Position der bisherigen Stelle (etwa /boot/grub/grub.cfg) kopieren, nachdem Du sie angesehen und für ok empfunden hast

Alles natürlich mit root-Rechten
 
Hallo Magic,
ergänzend zu tomturbos Antwort, von mir folgende Empfehlung zur Vorgehensweise:
  1. Starte zunächst die Synaptic-Paketverwaltung
  2. Suche nun in Synaptic nach dem Begriff "linux 5.15" und lasse Dir die Suchtreffer nach "Installierte Version" ordnen.
  3. Markiere alle gefundenen installierten Einträge als "Zum vollständigen Entfernen vormerken" (es sollten 5 Einträge sein: linux-headers-5.15.0-??; linux-headers-5.15.0-??-generic; linux-image-5.15.0-??-generic; linux-modules-5.15.0-??-generic; linux-modules-extra-5.15.0-??-generic)
  4. Klicke auf "Anwenden"
  5. Schließe Synaptic
  6. Folge der Empfehlung von tomturbo und öffne ein Terminal; gib dort folgende Befehlszeile ein:
    Code: 
    sudo update-grub
  7. Führe nun einen Neustart Deines PC durch
Gruß,
vnt
 
Zuletzt bearbeitet:
Die 5 Pakete habe ich in Synaptic (musste ich erst installieren) gefunden, es kam zwar erst diese Meldung:

E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
E: Das Verzeichnis zum Herunterladen kann nicht gesperrt werden

Aber beim 2. Versuch hat es dann geklappt. Evtl. war ja die Paketverwaltung im Hintergrund aktiv. Die Paketverwaltung hat dann auch nach dem Neustart (leider) alle älteren Kernel entfernt. Aktuell habe ich also nur noch den 5.4...135 drauf, aber der funktioniert ja.
Doppelposting wurde automatisch zusammengeführt:

Berniyh schrieb:
Warum so kompliziert? Ubuntu verwendet doch systemd. Einfach ein systemd Service ablegen und dann aktivieren.
Zum Vergrößern anklicken....
Ich greife das Thema nun mal auf.
Wie gehe ich da genau vor?
Ich habe das hier mal durchgelesen, allerdings außer der Tatsache, dass ich Änderungen mit systemctl machen kann nichts für die praktische Anwendung rauslesen können.
Hier wird noch mal genauer auf systemctl eingegangen.
Soll ich nun also eine neue "Unit" mit dem Parameter --system anlegen und dort meinen Befehl reinschreiben?
 
Zuletzt bearbeitet:
Die richtige Seite auf der Ubuntu Wiki wäre eher diese hier (ist in der zweiten Seite, die du verlinkt hast auch verlinkt):

Service Units › systemd › Wiki › ubuntuusers.de

wiki.ubuntuusers.de wiki.ubuntuusers.de
Da wird auf ein paar grundlegende Dinge zu den Units eingegangen. Je nachdem, was du genau vorhast (sorry, das weiß ich gerade nicht mehr …) könnten auch diese Seiten interessant sein:

User Units › systemd › Wiki › ubuntuusers.de

wiki.ubuntuusers.de wiki.ubuntuusers.de

Timer Units › systemd › Wiki › ubuntuusers.de

wiki.ubuntuusers.de wiki.ubuntuusers.de

Die grundlegenden Informationen zu den ganzen Variablen in den Units finden sich in der Manpage systemd.unit und systemd.service:
Wie so häufig lohnt sich auch ein Blick ins Arch Wiki:

systemd - ArchWiki

wiki.archlinux.org wiki.archlinux.org
Dort wird insbesondere auch darauf eingegangen was es für Service Types gibt.
Die meisten Informationen sind hier zwischen den Distributionen übertragbar, es könnte aber sein, dass Units hier und da mal etwas abweichend heißen, was relevant wird, wenn man Abhängigkeiten spezifiziert.

Generell finde ich es hier immer am Einfachsten, wenn man sich an bereits bestehenden Units orientiert. Daher hier als Beispiel eine Unit, die ich für mein System geschrieben habe um imwheel zu starten (ein ewig altes Programm, das man nutzen kann um Mausklicks in Tastenkombinationen umzusetzen).
Die Datei ist ~/.config/systemd/user/imwheel.service
Code: 
[Unit]
Description=IMWheel
Wants=display-manager.service
After=display-manager.service

[Service]
Type=simple
Environment=XAUTHORITY=%h/.Xauthority
ExecStart=/usr/bin/imwheel -d -k -b "0 0 6 7 0 0 10"

[Install]
WantedBy=graphical-session.target

Ich denke, die meisten Dinge sind hier selbsterklärend, bzw. zu Type=simple findest im Arch Wiki eine gute Erklärung. WantedBy ist relevant um systemctl zu sagen was passieren soll, wenn man diese Unit "enabled". In dem Fall hier würde die halt für das Target graphical (also meine Nutzersession) aktiviert, weil das bei WantedBy drin steht. Um herauszufinden, welche Targets es gibt, einfach `systemctl list-units` bzw. `systemctl --user list-units` ausführen.
(Achtung, die Ausgabe unterscheidet sich für system und user Level. e.g. graphical-session.target gibt es nur auf User Level, was ja auch Sinn macht.)
 
Zuletzt bearbeitet:
Berniyh schrieb:
Je nachdem, was du genau vorhast (sorry, das weiß ich gerade nicht mehr …)
Zum Vergrößern anklicken....
Ich möchte ein paar sudo Befehle an die Grafikkarte senden, um TDP und Lüfterdrehzahl zu begrenzen. Idealerweise erst, nachdem der Grafiktreiber mit Sicherheit auch geladen ist. Dieser Befehl muss auch nur einmalig gesendet werden, es ist kein Programm, was im Hintergrund aktiv bleibt.
Dann les ich mich mal weiter ein, Danke!

Würde so eine /etc/systemd/system/autostart.service datei funktionieren? Kann ich die einfach mit einem editor anlegen oder muss ich zwingend was mit systemctl machen?

[Unit]
Description=startet AMDGPUutils mit 1,3GHz und Fanspeed=38%

[Service]
Type=simple
ExecStart=/home/magiceye/amdgpu-utils/pac_1300_38.sh

[Install]
WantedBy=multi-user.target
Zum Vergrößern anklicken....

Notfalls noch mit einer zugehörigen xxx.timer, wo dann OnBootSec=1min drin steht.
 
Zuletzt bearbeitet:
Ah, ok. In dem Fall dann wahrscheinlich "Type=oneshot". Wird ja nur einmal ausgeführt.
Und wahrscheinlich möchtest du "Wants=modprobe@nvidia.service", was dann eben sagt, dass der Service möchte, dass das Modul nvidia geladen ist.
(Sofern das Modul auch so heißt.)
Kannst dich ein bisschen an dem hier orientieren:
Code: 
[Unit]
Description=Set custom amdgpu clocks & voltages
After=multi-user.target
Wants=modprobe@amdgpu.service

[Service]
Type=oneshot
ExecStart=/usr/bin/amdgpu-clocks
ExecStop=/usr/bin/amdgpu-clocks restore
ExecReload=/usr/bin/amdgpu-clocks

[Install]
WantedBy=multi-user.target
Das ist eine Unit für ein Programm, welches genau den Zweck für AMD GPUs erfüllt.

Etwas komplizierter wird es, wenn du suspend/hibernate nutzt, denn dann muss der Service nach dem resume wieder neu gestartet werden.
Falls nicht, dann sollte sowas wie das oben genügen.
 
Ich orientiere mich jetzt mal an einer mehr praxisorientierten Anleitung, die Wikis sind mir zu viel input, den ich höchstwahrscheinlich gar nicht brauche. http://blog.wenzlaff.de/?p=15477
Doppelposting wurde automatisch zusammengeführt:

Juhu, es hat alles geklappt. Wird nun beim Start geladen.
Ich hatte Type=oneshot noch geändert.
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.
 
Zuletzt bearbeitet:
MagicEye04 schrieb:
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.
Zum Vergrößern anklicken....
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.
 
amdgpu-utils habe ich nur entpackt, aber nvidia-smi kam als Paket. Mal sehen, was es da schon gibt.
Doppelposting wurde automatisch zusammengeführt:

Ich mach gleich mal die nächste Baustelle auf. SSH
In diversen Anleitungen wird geschrieben, dass SSH ganz einfach funktioniert.
Also habe ich es ausprobiert.
"ssh user@IP" ergibt:
" ssh: connect to host 192.*.*.* port 22: Connection refused"
Was mache ich denn da falsch? Ich habe es in beide Richtungen probiert, auch mit Rechnernamen statt IP und der Username ist sogar auf beiden Rechnern gleich. Beide Rechner hängen am gleichen Switch, der wiederum an der Fritzbox hängt.
Doppelposting wurde automatisch zusammengeführt:

"sudo service ssh status" ergibt:
"Unit ssh.service could not be found."
Passt irgendwie zum Autostart-Thema. Also muss ich SSH wohl noch zusätzlich als Server-Dienst installieren.
 
Zuletzt bearbeitet:
Der service heißt vermutlich sshd.service.
Und vermutlich läuft der nicht.

Für ssh würde ich dir zudem dringend empfehlen nur Authentifizierung per key file zu erlauben. Wie man die erstellt, dazu findest du sicher viele Seiten im Netz (bestimmt auch im Ubuntu Wiki).
Edit:
Code: 
systemctl list-units |grep ssh
hätte in dem Fall schnell geholfen. ;)
 
In einer anderen Anleitung hatte ich dann gefunden, dass man den Server erst installieren muss. Nur der Client ist immer drauf.
Schlüssel habe ich erstellt.
 
Ich mal wieder mit meinen Kernel-Fragen.
Auf meinem HTPC läuft Ubuntu 22.04.1LTS. Aktuell ist dort Kernel 5.15.0-27-generic
Der kommt mir im Gegensatz zu dem 5.15.0-54-generic auf dem Boinc-PC mit Ubuntu 20.04.5LTS irgendwie leicht veraltet vor.
Trotz apt-get update&upgrade wird der Kernel hier nicht aktualisiert.
Hängt hier irgendwas oder muss das so sein?
Edit: Nach einem Neustart hat sich die Aktualisierungsverwaltung gemeldet und hat das Kernel-update dann erledigt.

Irgendwo hing auch noch eine Frage mit dem IT87-Sensor in der Luft.
Auf dem Boinc-PC mit ASUS TUF X470-Plus Gaming und dem Kernel 5.15...54 bewirkt der Aufruf des IT87-Scriptes, dass die Spannungen und Lüfterdrehzahlen gefunden werden. Dort ist offenbar der IT8655 drauf.
 
Zuletzt bearbeitet:
MagicEye04 schrieb:
Auf meinem HTPC läuft Ubuntu 22.04.1LTS. Aktuell ist dort Kernel 5.15.0-27-generic
Der kommt mir im Gegensatz zu dem 5.15.0-54-generic auf dem Boinc-PC mit Ubuntu 20.04.5LTS irgendwie leicht veraltet vor.
Zum Vergrößern anklicken....
Generell ist auch die Frage, ob die Kernelversionen bei beiden gleich sein müssten.
Es scheint ja so zu sein, aber prinzipiell sind die -27 bzw. -54 hier keine Kernel minor releases, d.h. es sind nicht 5.15.27 bzw. 5.15.54, wie das jeder vernünftige Distributor machen würde, sondern es handelt sich um eine Ubuntu-eigene Versionierung und die könnte natürlich prinzipiell für verschiedene Releaseversionen auch wieder unterschiedlich sein.
Bin offensichtlich kein Fan von der Art Versionierung. Besser wäre es z.B. 5.15.85-3 oder so zu nehmen. (85 ist das aktuelle minor release von 5.15 und -3 wäre halt die dritte Version davon, z.B. wenn zusätzliche Patches eingepflegt wurden oder was an der Config angepasst wurde.
Aber immerhin scheinen sie es dann ja für beide Releases gleich zu versionieren, das macht es etwas leichter.
 
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.
 
Mir reicht ja das Patchlevel als Teil des Kernels. Mehr als 5.15 brauch ich nicht.
 
MagicEye04 schrieb:
Irgendwo hing auch noch eine Frage mit dem IT87-Sensor in der Luft.
Auf dem Boinc-PC mit ASUS TUF X470-Plus Gaming und dem Kernel 5.15...54 bewirkt der Aufruf des IT87-Scriptes, dass die Spannungen und Lüfterdrehzahlen gefunden werden. Dort ist offenbar der IT8655 drauf.
Zum Vergrößern anklicken....
Hallo MagicEye04,

wenn das Tool keine GUI hat, könntest Du es bei Bedarf z.B. einfach beim Systemstart automatisch starten lassen.
Der Original-IT87-Kerneltreiber unterstützt, wenn ich es richtig recherchiert habe, Deinen IT8655 Super I/O Chip nicht und der Entwickler der alternativen erweiterten Treiber-Version hat die Entwicklung irgendwann 2018 eingestellt.
Der Code der ist aber noch noch auf GitHub verfügbar, so dass Du Dir ggf. Deinen eigenen Treiber kompilieren und mit modprobe in den Kernel einbinden kannst ... ich würde mal vermuten, dass das IT87-Script genau auf dem Code basiert.
https://github.com/a1wong/it87

Gruß,
vnt
 
In den Autostart wollte ich es nicht packen, weil ich ab und zu auch mal die SSD von einem Rechner in den anderen stecke.
Ich dachte, dass das Script immer bereits eine Art Kompilierung+Kernel-Einbindung macht. Nur, dass dieser Teil halt den Reboot nicht überlebt.
 
MagicEye04 schrieb:
In den Autostart wollte ich es nicht packen, weil ich ab und zu auch mal die SSD von einem Rechner in den anderen stecke.
Ich dachte, dass das Script immer bereits eine Art Kompilierung+Kernel-Einbindung macht. Nur, dass dieser Teil halt den Reboot nicht überlebt.
Zum Vergrößern anklicken....
Das Skript kompiliert und installiert ein Modul, allerdings werden (wie bei den nct Modulen ja auch) die hwmon Module nicht immer automatisch geladen.
Müsst also dann nachträglich mittels modprobe it87 laden oder automatisch, wie wir es ja auch bei den nct Modulen schon diskutiert hatten.
Prinzipiell sollte es nicht schlimm sein, wenn du versuchst das it87 Modul auf einem System zu laden, auf dem es keinen derartigen Sensor gibt. Gibt dann halt eine Meldung in dmesg, dass kein passendes Gerät gefunden wurde.
 
MagicEye04 schrieb:
cp it87.ko /lib/modules/5.15.0-53-generic/kernel/drivers/hwmon/
Zum Vergrößern anklicken....
Ok, das Skript ersetzt offensichtlich das standardmäßig im Kernel enthaltene it87.ko Modul.

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.

Gruß,
vnt
 
tomturbo schrieb:
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.
Zum Vergrößern anklicken....
hi Tom,
Bitte was ist backportet?
Automatisch, muss ich da nichts machen oder wird mir das gemeldet? *noahnung*
 
S.I. schrieb:
Bitte was ist backportet?
Zum Vergrößern anklicken....
Die Patches aus neueren, aktuelleren Kernel werden auch in ältere Kernel »gepatcht«, das nennt sich dann »gebackported«.

Auf englisch: »backporting kernel patches«.

Du musst nichts machen. Außer eben die aktuellste Version von dem von dir verwendeten Kernel in der von dir verwendeten Distribution zu verwenden.

Grüße, Martin
 

Ähnliche Themen

RedBaron
Thema geschlossen - warum? Ubuntu für absolute Anfänger...Fragen, Tips, Tricks, ...
Antworten
2
Aufrufe
2K
RedBaron
RedBaron
S.I.
  • Gesperrt
AMD/ATI-Crossfire-Thread Tips, Tricks, Hilfe
111 112 113
Antworten
3K
Aufrufe
601K
Hübie
Hübie
Zurück
Oben Unten