[Gelöst] Kein "update-grub" in Buster mehr?

[ottonormal]

Hallo,

ich habe mein Test-Sparky auf Buster aktualisiert. Das klappte auch alles gut, nur wenn ich nun:

Code: Alles auswählen

update-grub

eingebe, erhalte ich die Meldung:

Code: Alles auswählen

bash: update-grub: Kommando nicht gefunden.

Im Netz gibt es viele Artikel zu dem Thema. Leider immer nur alles in englisch und für mich unverständlich. Es zeigt aber, dass ich mit dem Thema nicht alleine bin.

Wie komme ich nun wieder an mein altgewohntes "update-grub"?

[michaa7]

Hast du das als root ausgeführt?
Wie bist du root geworden, mit "su" oder mit "su -"? Versuche mal letzteres.

[MSfree]

/usr/sbin/update-grub

[MaGe]

su - root statt su root
hast du gemacht?


gruss MaGe

[atarixle]

/usr/sbin/update-grub

... ja, da war doch was, dass sbin nicht mehr im Standard-Pfad sein soll ...

War es /sbin oder /usr/sbin oder war das zeitgleich mit dem Verschieben von /sbin nach /usr/sbin ...

[ottonormal]

Ja klar, immer als root, das weiß ich schon.
Aber was bedeutet das, sbin nicht mehr im Standard-Pfad? Was muss ich da genau machen und warum ist es "werksseitig" nicht da wo es hingehört?

[michaa7]

Nicht einfach irgendwie als root ...

Die obigen beispiele wollten dir klarmachen, dass man root mit unterschiedlichen umgebungsvariablen werden kann, in soweit hat sich "su" geändert! Wenn du einfach nur "su" eingibst bleibt für root der normaluserkontext erhalten (das ist nun z.b. wichtig wenn du programme wie gparted aufrufen willst). Dann werden programme die root privilegien erfordern nicht gefunden, weil sie nicht im *user*-pfad enthalten sind. Um root im root kontext aufzurufen *musst* du root wie schon oben beschrieben aufrufen: "su -" Dann klappt es auch mit "update-grub" .

[MSfree]

Aber was bedeutet das, sbin nicht mehr im Standard-Pfad?

Das sollte dir doch aus DOS-Zeiten noch bekannt sein

PATH ist eine Umgebungsvariable, die eine mit Doppelpunkten getrennte Liste von Verzeichnissen enthält, entlang derer ausführbare Programme gesucht werden, wenn man sich nicht mit Absolutpfad aufruft.

Checken kannst du das mit

Code: Alles auswählen

echo $PATH

Seit Buster sind /sbin und /usr/sbin nicht mehr in der PATH-Variable, wenn man sich nur mit su zu root macht. su - bringt wieder den vollen Pfad. Alternativ kann man sich auch direkt als root anmelden oder den (meiner Meinung nach) Blödsinn rückgängig machen, indem du die Variable ENV_SUPATH in der Datei /etc/login.defs wieder um /sbin und /usr/sbin ergänzt.

Warum das entfernt wurde,ist mir völlig unklar. Ein Sicherheitsgewinn ist durch weglassen von PATH-Elementen überhaupt nicht gegeben. Root darf schließlich alles, auch Programme mit Absolutpfad aufrufen. Es ist also nur (mal wieder) irgendwas unbequemer geworden.

[TuxPeter]

Wenn es das ist, dann bin ich über diesen Stolperstein bin ich auch schon gestolpert, und mir wurde hier geholfen.

Code: Alles auswählen

man su meint:
      Aus  Gründen  der Abwärtskompatibilität wechselt su standardmäßig nicht
       das aktuelle  Verzeichnis und setzt  lediglich  die  Umgebungsvariablen
       HOME  und  SHELL  (plus USER und LOGNAME, falls der Ziel-Benutzer nicht
       Root ist). Es wird empfohlen, stets die  Option  --login  (statt  deren
       Kurzform  -)  zu verwenden, um durch Mischen der Umgebungen verursachte
       Nebenwirkungen zu vermeiden.

Jedenfalls wird, wenn man mit "su" root wird, einiges nicht gefunden, was mit "su -" einwandfrei gefunden wird.

edit: unsere Beiträge haben sich überkreuzt

[ottonormal]

Jedenfalls wird, wenn man mit "su" root wird, einiges nicht gefunden, was mit "su -" einwandfrei gefunden wird.

Ja, danke, JETZT habe ich es verstanden. Und es hat funktioniert

[halo44]

Wenn Du das "alte" Verfahren mit nur su (ohne -) beibehalten willst, musst Du (MSfree bezog sich schon darauf) in der /etc/login.defs diesen Abschnitt modifizieren:

Code: Alles auswählen

#
# *REQUIRED*  The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH	PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH	PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
ALWAYS_SET_PATH yes

Das "alte" Verfahren hat den Vorteil, daß Du beim anmelden als root im aktuellen Verzeichnis bleibst un nicht nach /root umgeleitet wirst.

Das "neue" Verfahren ist schlicht Unsinn und bringt weder Vorteile noch Sicherheitsgewinn.

Gruss H.

[TuxPeter]

Das "neue" Verfahren ist schlicht Unsinn und bringt weder Vorteile noch Sicherheitsgewinn.

Ich würde lieber sagen, es ist halt anders. Und wenn ich solche Config-Dateien ändere, dann kann das a) Nebenwirkungen haben (in dem Fall aber wohl eher nicht) und wird b) eventuell bei einem Update oder Upgrade wieder überschrieben. Und dann stehe ich, vielleicht, wieder auf dem Schlauch. Und noch: Ich betrachte es eher als Vorteil, mich nach Anmeldung als root auch im root-Verzeichnis zu befinden.

echo $PATH, hier mit "su"
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
hier mit "su -"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[MSfree]

Und wenn ich solche Config-Dateien ändere, dann kann das a) Nebenwirkungen haben (in dem Fall aber wohl eher nicht) und wird b) eventuell bei einem Update oder Upgrade wieder überschrieben.

Updates haben mir noch nie ungefragt Konfigurationsdateien überschrieben. Man hat immer die Option, seine angepaßte Datei beizubehalten.

Ganz nebenwirkungsfrei ist aber das Beibehalten der angepaßten Datei auch nicht immer Denn wenn sich der Syntax der Datei geändert hat, kommt die neue Softwarerevision ggfls. mit der alten Konfigurationsdatei nicht mehr zurecht. So richtig geklemmt hat es bei mir aber noch nie, wenn auch z.B. Apache und Squid bei einem Versionssprung gerne mal alte Optionen entfernen und/oder neue einführen. Auch sshd_config hat schon einige Änderungen hinter sich, die man sich lieber genau ansehen sollte, um keine Sicherheitslöcher zu aufzureißen.

[Strunz_1975]

Hallo,

ich habe das gleiche Problem!

su -
/sbin/apt-install paketname

hat nichts gebracht

[ingo2]

Hallo,

ich habe das gleiche Problem!

su -
/sbin/apt-install paketname

hat nichts gebracht

Das Problem liegt wo anders - nämlich zwischen Keyboard und Stuhl:
Der Befehl heißt entweder

Code: Alles auswählen

apt-get install

oder

Code: Alles auswählen

apt install