Siduction Forum
Siduction Forum => Software - Support => Topic started by: harley-peter on 2018/10/27, 15:33:35
-
Hallo,
seit einiger Zeit funktoniert bei mir der Kernel-remover nicht mehr. Wenn ich ihn im Terminal aufrufe bekomme ich folgende Anzeige:
The current (active) kernel is 4.19.0-towo.1-siduction-amd64
( ) 1. 4.18.10-towo.2-siduction-amd64
( ) 2. 4.18.11-towo.1-siduction-amd64
( ) 3. 4.18.13-towo.1-siduction-amd64
( ) 4. 4.18.15-towo.2-siduction-amd64
( ) 5. 4.18.7-towo.2-siduction-amd64
( ) 6. 4.18.9-towo.1-siduction-amd64
Der Cursor steht auf dem ersten Buchstaben und die einzigen Tasten die reagieren sind die rechts und links Pfeiltasten, Q für quit und h für help aber das wars dann schon. Wo könnte das Problem liegen?
-
ich benutze die graphische Oberfläche des kernel-removers, die funzt ohne Probleme
su-to-root -X -c /usr/sbin/kernel-remover
wenn ich den in der Konsole aufrufe, bringt die space Taste den Sprung in die Auswahlkästchen...
-
Hi jure,
das funktioniert leider nicht so ganz. Ich bekomme zwar die grafische Oberfläche aber wenn ich einen Kernel entfernen möchte dann gibt es folgende Fehlermeldungen:
dpkg: Warnung: »ldconfig« wurde im PATH nicht gefunden oder ist nicht ausführbar
dpkg: Warnung: »start-stop-daemon« wurde im PATH nicht gefunden oder ist nicht ausführbar
dpkg: Fehler: 2 erwartete Programme nicht im PATH gefunden oder nicht ausführbar
Beachten Sie: PATH von root sollte normalerweise /usr/local/sbin, /usr/sbin und /sbin enthalten
E: Sub-process /usr/bin/dpkg returned an error code (2)
Ich vermute mal das hängt mit der geänderten su Aufrufvariante zusammen (mit oder ohne -)
-
hmm
wenn ich hier den Befehl oben kopiere und aufrufe, kommt die graphische Passwortabfage und dann das graphische remover Fenster, in dem ich auch einen alten Kernel entfernen kann...
-
harley-peter, was sagt
cat $PATH
?
-
[...]
Ich vermute mal das hängt mit der geänderten su Aufrufvariante zusammen (mit oder ohne -)
ja richtig!
-
@axt:
je nachdem ob ich mich mit su oder mit su - angemeldet habe ist das Ergebnis unterschiedlich.
Mit su:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
mit su -:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
@hendrikL:
wie bekomme ich denn su - in den Befehl su-to-root -X -c /usr/sbin/kernel-remover? Dann müsste es funktionieren.
Oder noch besser: wie bekomme ich sowohl für su als auch für su - dieselben ausreichenden Pfadangaben in $PATH? Ist es sinnvoll das in /etc/profile anzupassen?
-
Mit su:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
mit su -:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
das ist bei mir genau so, dennoch funzt "su-to-root -X -c /usr/sbin/kernel-remover" ohne Probleme
-
@harley-peter
Was passiert denn, wenn Du mit "su -" root wirst und dann "kernel-remover" aufrufst?
edit:
Ps.:Ganz vergessen, "man su" sagt einem, was man tuhen kann um das alte verhalten von su wieder zu erlangen.
-
@jure:
Das Interessante an der Sache ist dass das Spiel an meinem Laptop funktioniert aber nicht an meinem Desktop-Rechner obwohl beide das gleiche System installiert haben. Auch die unterschiedlichen Pfade sind bei beiden identisch.
@hendrikL:
wenn ich den kernel-remover mit su - aufrufe dann passiert genau das was ich im ersten Beitrag geschrieben habe. Nur su kennt keinen Befehl kernel-remover. Klar ihm fehlen die root Pfade.
Mir ist der Sinn von zweierlei root immer noch nicht klar. Wenn der default user des Kommando su root ist dann sollten auch die dazugehörigen Parameter identisch sein egal wie ich root werde. Aber vermutlich bin ich da zu naiv. :)
Eine weitere Stilblüte dieses - aus meiner Sicht - unsinnigen Unterschiedes ist dass z. B. der Editor xfwrite nur mit su funktioniert und nicht mit su -.
Sowas hatte ich vor Jahren schon mal bei Windows als ich feststellte dass es einen Admin und einen Superadmin gibt und habe über diesen Schwachsinn damals geschimpft und den Kopf geschüttelt. Und jetzt .... :-\
-
zmore /usr/share/doc/util-linux/NEWS.Debian.gz
gibt ein wenig Auskunft zu diesem Thema und warum so entschieden wurde.
Über Sinn und Unsinn kann man sich streiten.
Ich vermute mal, dass irgend eine Bibliothek oder Programm fehlt.
Hast Du es mal mit der Option -G versucht?
# kernel-remover -h
kernel-remover
-G parameter use parameter as the graphical frontend
one of text | dialog | kdialog | zenity
-f proceed without asking, do complete cleanup
-h show this usage
Edit: zenity installiert?
-
Auf die Gefahr hin, mich einfach mal unbeliebt zu machen: Probleme lösen gehört nicht zum Sinn dieses Dialogs, oder?
# apt show kernel-remover
Version: 3.1.17
Priority: extra
Section: misc
Maintainer: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Installed-Size: 209 kB
Depends: gettext-base, dctrl-tools, menu, ssft
Suggests: zenity
Wenn man das Teil aus dem Menu aufrufen möchte, dann sollte zenity installiert sein. Oder dialog - oder kdialog.
apt install zenity | dialog | kdialog
Und nun werfen wir mal einen kleinen Blick in die desktop-datei
nano /usr/share/applications/kernel-remover
...
Exec=su-to-root -X -c /usr/sbin/kernel-remover
...
Was ist nun dieses su-to-root?
% apt-file search su-to-root
menu: /usr/bin/su-to-root
menu: /usr/sbin/su-to-root
^^
ergo - falls nicht installiert: apt install menu
Nachdem das alles erledigt ist:
# su-to-root -X -c kernel-remover
und nü noch mal zum Mitmeisseln:
su - run a command with substitute user and group ID
* su ohne alles ist eigentlich nen su root - damit ändere ich nur den User
* su - ist eigentlich su -|-l|--login root - damit reisse ich ne login-shell auf
Und das hat unterschiedliche Auswirkungen, am besten erklärt durch
# su -c env > shell1
# su - -c env > shell2
# meld shell1 shell2
Mahlzeit :D
-
@melmarker:
Du darfst dich gerne unbeliebt machen - wenn's denn hilft! ;)
Das mit dem Unterschied zwischen su und su - ist mir durchaus klar, des lesens bin ich ja mächtig. Trotzdem bin ich in beiden Fällen hinterher root und da sollte es aus meiner naiven Nutzersicht keine so gravierenden Unterschiede geben dass ich z. B. zweierlei Variablen $PATH habe.
Nun zum Problem:
Alle von dir erwähnten Programme/Pakete sind installiert.
root@master:~# apt policy menu
menu:
Installiert: 2.1.47+b1
Installationskandidat: 2.1.47+b1
Versionstabelle:
*** 2.1.47+b1 500
500 http://ftp.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
root@master:~# apt policy zenity
zenity:
Installiert: 3.30.0-1
Installationskandidat: 3.30.0-1
Versionstabelle:
*** 3.30.0-1 500
500 http://ftp.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
root@master:~# apt policy kernel-remover
+kernel-remover:
Installiert: 3.1.17
Installationskandidat: 3.1.17
Versionstabelle:
*** 3.1.17 500
500 http://packages.siduction.org/extra unstable/main amd64 Packages
100 /var/lib/dpkg/status
Ein
su-to-root -X -c kernel-removerhilft nicht denn damit wird der Befehl nicht gefunden. Es muss schon ein
su-to-root -X -c /usr/sbin/kernel-removersein. Damit tritt aber das Problem auf wie im dritten Post beschrieben. Das Verhalten ist natürlich identisch wenn ich kernel-remover aus dem Menü aufrufe denn da ist der o. a. Befehl hinterlegt.
@hendrikL:
Habe ich auch schon probiert. Beim Aufruf von
kernel-remover -G zenity nachdem ich mich mit su - angemeldet habe passiert gar nichts.
-
Doch, soll -- wenn Du Bock hast, lass uns irgendwann nachmittags mit anydesk draufschauen, das muss ich sehen
-
Gerne doch. Wann hättest du denn Zeit?
-
irgendwann nach 17.00 - einfach im IRC anpingen - ich weiss auch, was passiert, nur nicht warum. Hintergrund: Bei mir wird das alles(tm) ein wenig anders verarbeitet und gesourced, ich hab zsh als shell
-
Nur so zum Test, auto-remove Mal probieren.Bei mir bleibt der aktuelle und der letzte Kernel übrig, alle anderen werden deinstalliert.
-
harley-peter und melmarker haben sich gestern über IRC kurzgeschlossen. Da wäre hier ja der Stand nach der Fernwartung sinnvoll (ich gehe davon aus, es ist gegessen).
-
Okay, dann kann hier ja geschlossen werden.
-
Ja, das Problem ist Dank der Geduld und der Kompetenz von melmarker behoben mit der Anpassung diverser Konfigurationsdateien bezügl. der Pfade. Obwohl melmarker sehr bemüht war mir die Vorteile des unterschiedlichen Verhaltens zwischen su und su - zu erläutern :) hat das bei mir nur bedingt gefruchtet. Im Umgang mit unterschiedlichen Nutzern mag das alles durchaus sinnvoll sein aber für mich persönlich darf es einfach keine zwei unterschiedlichen roots geben. root ist root! MIt allen Möglichkeiten und Konsequenzen und zwar egal wie ich mich einlogge.
Aber das ist nur die Ansicht eines naiven unbedarften Nutzers. :)
-
ja, ich hab mich wirklich bemüht - des Rätsels Lösung war bei harley-peter einfach die Erweiterung der PATH-Variable um /sbin und /usr/sbin in der ~/.bashrc. Ich hab mir sagen lassen, dass das durchaus legitim sein soll, weil: Wenn ein Programm da aus irgendwelchen Gründen rumlungert und als normaler User ausführbar ist, dann macht es keinerlei Sinn, das aus dem Suchpfad rauszunehmen - und wenn es erhöhte Rechte braucht, dann macht es noch weniger Sinn, den Suchpfad so kastriert zu lassen, wie mit ner login shell :D
export PATH=$PATH:/sbin:/usr/sbin
-
ist das nicht die grund fur benutzing su - ?
-
Ganz ehrlich? Ich hab zwar gelesen, dass es da durch die Verlagerung von su von login nach util-linux auch noch ein paar Änderungen gegeben hat, hab mich aber damit noch nicht wirklich auseinandergesetzt, weil diese Änderungen in zsh nicht wirklich so durchschlagen.
-
die - sulte die user in die /root environment shalten! "root path"
-
Der Grund für die Benutzung von su - hat mich in diesem Zeitraum (2018) diese Erläuterung (https://bbs.archlinux.de/viewtopic.php?pid=363717#p363717) überzeugt. :)
-
Ok. Nix gegen GerBra - der weiss eigentlich genau, wovon er schreibt - macht aber in dieser Erklärung einige Denkfehler. Oder zumindest empfinde ich das, was er da von sich gibt, als solche. Verdammt, ich bin mit oder ohne login-shell root. Und in dem Fall brauch ich nicht mal mehr evilnerd heissen, um dat script direkt nach /usr/bin zu hacken - ikke darf dat :D
Und ja - das strippen der Umgebung hat auch einiges für sich - und einiges halt gegen sich. .Xauthority hatten wir ja schon mal angesprochen. Und Pfadsetzung auch. Ich hab leider die doofe Erfahrung machen dürfen, dasss oftmals binaries halt nach /sbin oder /usr/sbin platziert werden und dann nicht gefunden werden - weil halt der doofe User per default /sbin und /usr/sbin nich im Pfad hat - find ich nicht schick.
Von dem ganzen xdg und X-Geraffel schweigen wir mal, na klar kann man so was auch missbrauchen. Ich seh aber nicht wirklich ein, dass ich mich selbst um Möglichkeiten bringe, die meine Leben erleichtern, nur weil das in einem anderen Kontext missbraucht werden kann :D - in diesem Moment ist das ganz einfach: Mein Rechner, meine Regeln. Und wenn da jemand reinmanscht (KDE mit dem check auf id=0 und nem erhobenen Zeigefinger in dolphin und kwrite/kate), dann löst das bei mir nen Beissreflex aus - einhergehen mit wilden Flüchen und schneller Benutzung von Editoren und Bauscripten um den "Mist" flugs zu beseitigen 8) - immer unter der Prämisse: Man sollte ansatzweise wissen, was man tut.
-
Amen! :)
-
@melmarker:
+1!
Es kann nur einen root geben! :)