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

[MagicEye04]

Nee, /com/ gibt es bei mir nicht.
Ich habe die erste Zeile daher einfach mal gelöscht, hat aber auch nix gebracht.

PS: Ich bin ja echt dankbar, dass man bei Linux alles selbst einstellen kann. Aber muss das denn echt immer noch auf den Stand 1990 passieren und in jeder Distri anders sein? (rhetorische Frage)
Mal abgesehen davon verstehe ich auch nicht, warum man die Scrollleisten so verkrüppelt hat. Das kann man ja gern als zusätzliche Option anbieten für die Leute, die es mögen.

 

[vnt]

Aber muss das denn echt immer noch auf den Stand 1990 passieren und in jeder Distri anders sein? (rhetorische Frage)

Gute Frage ... nächste Frage!

... aber ich habe vielleicht hilft Dir diese Forumsdiskussion weiter, so dass Du doch noch an die vollständigen gtk.css Dateien kommst und diese anpassen kannst: https://askubuntu.com/questions/124...s-gtk-css-resource-com-ubuntu-themes-yaru-lig

Versuch mach klug

Hoffe, es klappt!
Nach dem erfolgreichen Extrahieren sollte der Weg aus Beitrag #646 dann aber nun endlich funktionieren, wobei Du in dem modifizierten Thema die originalen gtk.css jeweils durch die extrahierten vollständigen Versionen ersetzt.

Gruß,
vnt

 

[MagicEye04]

Mach ich morgen, heute ist mein Gehirn schon im standby. Es war übrigens ne doofe Idee, die erste Zeile zu löschen. Die Konsole hatte dann keine Ränder mehr, sie bestand nur noch aus dem Textfenster - nicht verschiebbar und nicht in der Größe änderbar.

 

[enigmation]

Ich möchte gerne dauerhaft unter Linux Mint die GCN3-Karte R9 380X mit nur maximal 100W betreiben. Es soll bei Systemstart automatisch so eingestellt sein/werden, nicht erst bei Anmeldung.

Damit müsste es gehen: 100000000µW = 100W

echo 100000000 > /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap

Quellen:

Reduce AMD GPU Wattage

How would I reduce the Wattage (is that a word?), of a somewhat recent open source AMDGPU supported GPU on Linux? The objective here is to reduce power consumption and get closer to the Performace/...

unix.stackexchange.com

GPU Power/Thermal Controls and Monitoring — The Linux Kernel documentation

 

[MagicEye04]

Kann man irgendwie sein Passwort auslesen oder resetten, wenn man Auto-Login aktiviert hat?
Beim Odroiden hatte ich das Standardpasswort geändert und nun kenne ich es nicht mehr.
Recovery-Modus von GRUB scheint es auf ARM keinen zu geben.
Alles was sudo erfordert, klappt nicht, weil ich das Passwort ja dann eingeben müsste.

 

[Berniyh]

Kann man irgendwie sein Passwort auslesen oder resetten, wenn man Auto-Login aktiviert hat?

Nein. Es wird im Normalfall nur ein Hash gespeichert und der ist natürlich nicht trivialerweise zurückzuverfolgen. Wäre ja auch noch mal schöner.
Man kann aber als Admin natürlich ein neues Passwort setzen, vorausgesetzt du kennst das root Passwort.

Beim Odroiden hatte ich das Standardpasswort geändert und nun kenne ich es nicht mehr.
Recovery-Modus von GRUB scheint es auf ARM keinen zu geben.
Alles was sudo erfordert, klappt nicht, weil ich das Passwort ja dann eingeben müsste.

Wenn du weder das Benutzerpasswort noch das root Passwort kennst, dann gibt es eigentlich nur noch die Möglichkeit es in einer chroot Umgebung zu ändern.
d.h. dann mit Hilfe von einem Live System. Dort kannst du root Rechte erlangen, das Host System in einer chroot Umgebung aufrufen und hast automatisch root Rechte. Die Passwörter lassen sich dann mit passwd neu setzen.

 

[MagicEye04]

Ich weiß nicht, ob es auf dem Odroiden ein extra root passwort gab.
Man hat sich ja dort immer mit dem Standarduser Odroid angemeldet.
Ich hoffe, dass der 2. Odroid funktioniert und dann versuche ich mit dem das root passwort zu setzen. Live system gibt es ja meines Wissens keins dafür.

Boinc aus dem Fremd-Repo läuft leider auf dem einen Rechner (htpc) noch nicht wirklich stabil. Beim Start musste man immer eine Weile warten, damit der Boinc Manager "mit dem client kommuniziert" und irgendwann war er dann damit fertig. Nun dauert das schon 10 Minuten und ich fürchte, die Beiden haben sich nichts mehr zu sagen.

 

[Berniyh]

Ah, das ist ein Android System. Ja, da ist die Sache etwas anders.
In dem Fall musst du wohl spezifisch suchen, ob sich da was machen lässt.

 

[MagicEye04]

Nein, nicht Android, OOOOdroid.
Also Ubuntu auf ARM.

Boinc auf dem HTPC ist weiterhin sehr bockig. Evtl. darf man nicht direkt den neueren Boinc-Manager aus dem zusätzlichen Repo installieren, sondern sollte vorher das veraltete Boinc nehmen, was Ubuntu anbietet - und dann erst updaten. Selbst das Icon ist irgendwie falsch auf dem Rechner (ein Zahnrad).

 

[Berniyh]

Nein, nicht Android, OOOOdroid.
Also Ubuntu auf ARM.

Mag schon sein, aber darum ging es nicht, sondern eher darum, dass diese Geräte oft einfach anders zu handhaben sind.
Ist halt eine spezielle Situation.

 

[S.I.]

Grafiktreiber-Update

wieder mal ne Frage an die Profis:

Wenn ein Treiber-Update, etwa im monatlichen Standardupdate, nicht den Wünschen entspricht oder sonst wie Probleme macht, und ich via timeshift eine Systemwiederherstelung mache ist dann wieder der alte Treiber aktiv oder behält der den neuen wie bei Windows manchmal, das man nicht mehr zurück kann?


(Bitte kein "sollte, könnte oder ich denke" - sondern echte Selbsterfahrung)

Danke schon mal

 

[Berniyh]

Wenn du einen Snapshot des Systems vor dem Update erstellst und danach wiederherstellst, dann ist das System auf dem gleichen Stand wie vor dem Update.
Das gilt aber dann natürlich nicht nur für den Treiber, sondern ggf. auch für andere aktualisierte Pakete die installiert wurden.
Das ist ja auch der Sinn eines Snapshots, den Zustand eines Systems zu einem bestimmten Zeitpunkt einzufrieren. Sollte eigentlich auch bei Windows sein, wenn man wirklich mit Snapshots arbeitet und nicht nur den Treiber reinstalliert/downgradet.

Prinzipiell sollte unter Linux aber auch ein reines "Downgrade" des Treibers funktionieren, solange der Treiber über den Paketmanager installiert wurde.
Der Paketmanager trackt und entfernt bei einer Deinstallation (einer Version) alle Dateien, die installiert wurden. Ausgenommen davon sind im Normalfall nur Dateien die nach /etc installiert wurden.
Je nach Implementierung (also je nach Paketmanager) werden diese entweder nie entfernt, oder nur entfernt, insofern sie nicht modifiziert wurden.
Generell muss man auch davon ausgehen, dass modifizierte Dateien nicht entfernt werden (aber ggf. durch ein Update überschrieben). Das ist einer der Gründe, warum man nicht in Dateien in /usr rumpfuschen sollte.

Wenn der Treiber über einen externen Installer (also z.B. diese Shellskripte von Nvidia) installiert wurde, dann würde ich nichts darauf geben, dass das sauber abläuft, das kann dann auch genauso vermurkst sein wie unter Windows. Mit einem Snapshot ist man da aber auch auf der sicheren Seite.

 

[S.I.]

ja, so dachte ich auch, und so wusste ich das auch im Prinzip. Wollte nur sicher gehen das der Treiber dann auch zurückgesetzt wird.
vielen Dank Berniyh

 

[MagicEye04]

Ich bräuchte mal Hilfe, wie ich einen deutlich älteren Kernel booten kann. Ich habe nur Fernzugriff, kann also Grub nur so ändern, dass beim Booten eine Vorauswahl gebootet wird.

Eigentlich sollten jede Menge Kernel vorhanden sein:
tpc@htpc:~$ dpkg -l | grep linux-image
rc linux-image-5.15.0-25-generic 5.15.0-25.25 amd64 Signed kernel image generic
rc linux-image-5.15.0-27-generic 5.15.0-27.28 amd64 Signed kernel image generic
rc linux-image-5.15.0-56-generic 5.15.0-56.62 amd64 Signed kernel image generic
rc linux-image-5.15.0-58-generic 5.15.0-58.64 amd64 Signed kernel image generic
rc linux-image-5.15.0-60-generic 5.15.0-60.66 amd64 Signed kernel image generic
rc linux-image-5.19.0-35-generic 5.19.0-35.36~22.04.1 amd64 Signed kernel image generic
rc linux-image-5.19.0-38-generic 5.19.0-38.39~22.04.1 amd64 Signed kernel image generic
ii linux-image-5.19.0-40-generic 5.19.0-40.41~22.04.1 amd64 Signed kernel image generic
ii linux-image-5.19.0-41-generic 5.19.0-41.42~22.04.1 amd64 Signed kernel image generic
ii linux-image-generic-hwe-22.04 5.19.0.41.42~22.04.14 amd64 Generic Linux kernel image

Wenn ich etc\grub editiere und GRUB_DEFAULT="1" (vorher war es 0) setze, wird trotzdem noch der neueste kernel gebootet:
htpc@htpc:~$ uname -r
5.19.0-41-generic

im Grub Customizer sehe ich nur
5.19.0-40-generic
5.19.0-41-generic
und jeweils noch mit recovery modus.
Ich würde aber gern den hier booten:
rc linux-image-5.15.0-60-generic 5.15.0-60.66 amd64 Signed kernel image generic
Gibt es da eine Möglichkeit?

 

[Berniyh]

Die (direkte) Konfiguration von GRUB befindet sich nicht in /etc/default/grub, sondern normalerweise in /boot/grub/grub.cfg
Letztere Datei wird auf Ubuntu iirc über ein Tool wie update-grub(?) bei Installation oder Update eines Kernelpakets automatisch generiert, wobei die Parameter in /etc/default/grub in die Generation eingehen. d.h. also, dass du hinterher auch noch update-grub o.ä. ausführen müsstest, damit die Änderungen in dieser Datei auch beim Bootvorgang übernommen werden.
Der Eintrag GRUB_DEFAULT wählt dann im Menü den Eintrag vor (und bootet den auch automatisch nach Zeitablauf), der im Menü zu sehen ist.
Wenn also der Kernel, den du booten willst dort nicht gelistet ist, dann kannst du den mit GRUB_DEFAULT auch nicht booten.

Wenn im GRUB Menü nur die zwei (bzw. drei(?)) Einträge auftauchen, dann werden die anderen wohl schon bei der Generation von grub.cfg aus irgendwelchen Gründen nicht berücksichtigt. d.h. hier wäre bei der Fehlerbehebung anzusetzen.
Ich bin leider kein dpkg Experte, aber wenn ich das hier:

dpkg › Wiki › ubuntuusers.de

wiki.ubuntuusers.de

richtig interpretiere, dann bedeutet das "rc" vor den meisten Zeilen, dass diese Kernel entfernt wurden und nur etwaige noch Konfigurationsdateien verbleiben (wovon es für Kernelpakete eigentlich keine geben sollte).
Installiert wären nur die drei letzten Kernelimages und die sollten dann auch in GRUB auftauchen?
Prüfe das also mal, ob der gewünschte Kernel auch installiert ist.

 

[MagicEye04]

update-grub lasse ich danach laufen und das findet eben auch nur die 2 neuesten Kernel.
Gut, dann werden die älteren wohl nicht mehr drauf sein.
Aktuell scheint die 5.19.0-40 stabil zu laufen, daher lass ich die erst mal.

 

[MagicEye04]

Prüfe das also mal, ob der gewünschte Kernel auch installiert ist.

OK, wie genau kann ich das machen?

Heute war der boinc client wieder abgeschmiert. Also muss ich wohl doch auf den 5.15 Kernel zurück.

Was würde passieren, wenn ich linux-image-generic-hwe-22.04 deinstalliere?

 

[Berniyh]

Prüfe das also mal, ob der gewünschte Kernel auch installiert ist.

OK, wie genau kann ich das machen?

Alles was als Kernel verfügbar ist liegt im Normalfall in /boot
Um die nutzen zu können müssen natürlich auch die zugehörige initrd und die Module (zu finden in /lib/modules) vorhanden sein.
Ich halte es aber für unwahrscheinlich, dass die Dateien noch da sind, wenn das Paket ja entfernt wurde.

Heute war der boinc client wieder abgeschmiert. Also muss ich wohl doch auf den 5.15 Kernel zurück.

Halte ich tendenziell auch für empfehlenswert, wenn der vorher auf dem System funktioniert hat (oder hast du ein System Upgrade auf eine neuere Ubuntu Version durchgeführt?). Evtl. gibt es ein kernel-lts Paket, notfalls gibt es das sicher in einem ppa. Da sollte man aber überprüfen, dass das ppa keinen Schindluder treibt, sondern möglichst die kernel.org Versionen vertreibt (oder meinetwegen auch die Ubuntu-spezifischen Versionen, so es die denn gibt).
Der 5.15er Kernel ist im Gegensatz zum 5.19er ein offizieller LTS Kernel. Der 5.19er wurde von Seiten der Kernel Entwickler schon vor Ewigkeiten (genauer: im Oktober) eingestellt, siehe hier:

The Linux Kernel Archives

www.kernel.org

Kann natürlich gut sein, dass Ubuntu den 5.19er eigenhändig weiter patcht.
Solchen Vorhaben stehe ich persönlich aber eher kritisch gegenüber, weil da tendenziell weniger Leute drüberschauen, würde mich eher an die originalen Versionen von kernel.org halten, soweit es geht.

Was würde passieren, wenn ich linux-image-generic-hwe-22.04 deinstalliere?

Das kann ich dir nicht sicher sagen, da das sicher spezifisch für Ubuntu ist und ich selbst ja seit ca. 10 Jahren kein Ubuntu mehr angerührt habe.
Wenn ich raten müsste, dann würde ich vermuten, dass es sich um ein generisches initrd handelt, welches Microcode und/oder Firmware enthält und vor dem Kernel selbst geladen wird, z.B. um die CPU zu patchen. (die initrd mit den Modulen etc. wird nach dem Kernel geladen). So etwas in der Art gibt es jedenfalls bei Arch Linux.
Wenn ich da richtig läge, dann sollte nix unmittelbar schlimmes passieren, wenn du das deinstallierst, die CPU sollte ja prinzipiell auch ohne neuen Microcode funktioniert. Allerdings wärst du dann wohl auch nicht vor diversen CPU Bugs und/oder Sicherheitslücken geschützt.

 

[MagicEye04]

Alles was als Kernel verfügbar ist liegt im Normalfall in /boot

OK, da liegen auch nur die beiden Letzten.

Ich hab das System erst vor wenigen Monaten installiert, direkt Ubuntu22LTS. Vermutlich mit dem ersten Kernel, der in der Liste steht.
Irgendwann hab ich dann wohl aus Versehen das upgrade angestoßen.
Ubuntu hat den 5.19 für die Version 22.04.2LTS (im Februar erschienen) vorgesehen und wird ihn auch bis 2027 unterstützen laut

Ubuntu – Wikipedia

de.wikipedia.org

Sicherheitslücken sind mir relativ egal. Das ist ein reiner Boinc/Filme-Guck-Rechner, ohne persönliche Daten. Aktuell will ich ihn einfach nur stabil boincen lassen, in 2 Wochen kann ich den im schlimmsten Fall wieder platt machen.
Ich kann leider nicht mehr sagen, wann genau ich welche Aktualisierung zugelassen habe. Aber am Wochenende lief er noch normal.

 

[S.I.]

Gibt es eigentlich einen Grund nicht bei dem Kernel 5.15 zu bleiben, wenn der so stabil ist?
Ich meine, wenn man nicht ständig neue Hardware einbinden oder upgraden will, weil man eh längst die Top-Teile etwa verbaut hat,
ist doch ein stabiler Kernel das Optimum oder?
Nur weil "jeder" unter Windows etwa, meint ständig das allerneueste Update aufspielen zu müssen weil Windows eh Flickwerk ohne Ende ist - kann man doch mit dieser Angewohnheit brechen oder sehe ich hier was falsch?

hier und da ggf. einen Browser mal updaten, etwa wenn er dies als dringend meldet etc. ist ja ggf. nicht verkehrt, aber den Kernel immer wieder ersetzen, ist das wirklich nötig,- insbesondere wo er stabil und rund läuft?

Ich frag ja nur mal unbedarft so in die Welt hinein... *

 

[MagicEye04]

Neue Hardware wäre für mich der einzige Grund. Sensorwerte waren bei mir z.B. mit den alten Kernels nur durch Zusatzmodule aufrufbar. Wobei 5.15 in dem Sinne ja schon recht neu ist. Den 5.19 wollte ich nicht unbedingt haben.
Und natürlich kann ein alter Kernel auch Sicherheitslücken haben - aber die Alten werden ja auch sehr lange noch gepflegt. Die 3.14 auf dem Odroid könnte man als hoffnungslos veraltet ansehen.

 

[Berniyh]

@MagicEye04: dann installier dir doch einfach den 5.15er Kernel. Auf irgendeine Art wird man den für Ubuntu 22.04 schon auch bekommen, notfalls halt über ein ppa. Wie genau kann ich leider nicht sagen, da es halt wieder spezifisch für die Distribution ist.

Gibt es eigentlich einen Grund nicht bei dem Kernel 5.15 zu bleiben, wenn der so stabil ist?

Es ist absolut legitim bei einer Kernelversion zu bleiben, so lange diese noch unterstützt wird und man zufrieden damit ist wie es läuft.

Ich meine, wenn man nicht ständig neue Hardware einbinden oder upgraden will, weil man eh längst die Top-Teile etwa verbaut hat,
ist doch ein stabiler Kernel das Optimum oder?

Jein, es wird über die Kernelversionen hinweg ja nicht nur Hardwaresupport verbessert, sondern es kommen auch andere Features etc. dazu.
Die müssen natürlich nicht zwangsläufig für einen relevant sein, je nach Anwendungsfall ist es aber möglich.
Einfaches Beispiel wäre hier z.B. wenn man ein Dateisystem nutzt das noch aktiv in der Verwendung ist. Also z.B. btrfs.
Da kommen dann mit einer neuen Kernelversion auch mal ein neuer Kompressionsalgorithmus oder eine neue Version davon. Oder sonstige Verbesserungen des Dateisystems (muss sich nur mal die Manpage dazu anschauen, da ist eine Liste der Verbesserungen drin).
Aber auch andere Verbesserungen, wie z.B. die immer weiterschreitende Einführung von eBPF, was ursprünglich ein Paketfilter ist, inzwischen aber zu einem Subsystem ausgeweitet wird, mit welchem man noch viel mehr machen kann.
Gut, derzeit ist das noch nicht so hilfreich, weil sehr neu, aber in Zukunft könnte alleine das schon ein Grund sein neuere Versionen zu nutzen, je nach Anwendungsfall.

Nur weil "jeder" unter Windows etwa, meint ständig das allerneueste Update aufspielen zu müssen weil Windows eh Flickwerk ohne Ende ist - kann man doch mit dieser Angewohnheit brechen oder sehe ich hier was falsch?

Auch jein. Prinzipiell hast du schon recht. Genau aus dem Grund gibt es ja auch diverse LTS Versionen von verschiedenen Distributionen, die genau so ein Konzept verfolgen und hauptsächlich Bugfixes einspielen.

Auch hier denke ich aber es kommt auf den Anwendungsfall an.
Ich persönlich nutze seit inzwischen über 15 Jahren rolling-release auf dem Desktop und mache das auch beim Kernel so (wobei ich immer noch einen LTS Kernel in der Hinterhand habe, für den Fall der Fälle) und bin damit sehr gut gefahren.
Im Vergleich zu Ubuntu und Fedora, welche ich auf verschiedenen Rechnern nebenbei betreut habe, hatte ich hier nicht, das Gefühl, dass es zu signifikant mehr Problemen kam, bzw. es gab auch bei den Release (oder sogar LTS) Versionen genügend Probleme, so dass ich nicht denke, dass es einen großen Unterschied macht. Ist aber natürlich nur meine persönliche Erfahrung, your milage might vary!
Man muss hier halt auch bedenken, dass sich gerade Open Source Entwickler meist intensiver mit den aktuellsten Versionen beschäftigen und selbst diese mehr testen. Natürlich schließt das aber neue Bugs nicht aus.

 

[Mike]

Unter Ubuntu ist es recht einfach den passenden Kernel zu installieren.
Ich hatte bei Mint immer UKUU installiert, da geht es rats fats.

Bei Solus ist das schon etwas anderes, und da Solus eine Rolling Distro ist muss man alles installieren.
Wenn ich einen LTS Kernel installieren würde bekäme ich halt nur Sicherheits updates.
Im Moment bin ich happy damit alles läuft super auch unter Kernel 6.2.14.
Und das mit meiner recht betagten Hardware.

 

[MagicEye04]

Die eine Woche versuche ich es mal noch ohne den alten Kernel, heute hat der Boinc Client schon 24h durchgehalten.
Danach bin ich wieder vor Ort und dann kann ich auch direkt am Rechner was machen. Dann probier ich mal ukuu

 

[S.I.]

Und das mit meiner recht betagten Hardware.

hehe whw not, wenns läuft und genügt. und 16 GB cl. 14 ist doch ordentlich, insbesondere unter Linux!
Mein alter (noch) Windows Rechner, derzeit nicht benötigt, ist im Herbst 15 Jahre alt geworden, mit jew. 3 Upgrades bis auf max. einen 6 Core Thuban und 16 GB Ram. Damit erledigt er heute noch alles was ich so brauche.
Hoffe der jetzige rennt wieder sehr sehr lange, denn das muss ein Rechner bei mir einfach.
(Und das sollte auch gehen, wenn ich keine extrem neuen Programme oder Games meine installieren zu müssen o.ä- - denn mit etwa der ursprünglichen Hardware rennt so ne Kiste prinzipiell 20 Jahre theoretisch jedenfalls. Ein paar Hardware-Upgrades ggf. je nach dem und das geht in etwa auch.)
Wünsche dir das die Kiste noch recht lange läuft, etwa wie mein Thuban,
... als "Rentner" inzwischen macht er aber nur noch Alters-Teilzeit und die auch sehr bescheiden in wenigen Stunden.