[gelöst]Bookworm: Frage zu /bin und /sbin

[halo44]

Habe heute den Wechsel vollzogen von Bullseye zu Bookworm. Meine Bookworm-Installation habe ich schon seit Monaten immer wieder aktualisiert, aber nicht sonderlich viel getestet und auch nicht viel gearbeitet.

Nun ist seit heute meine Bookworm-Installation die Default für Grub. Läuft auch alles bisher recht ordentlich. Bis mir jetzt in einem Skript /bin/mount nicht ausgeführt wurde.

Was mich erstaunt: in /bin haben fast alle Einträge in Dolphin ein kleines Symbol mit ! vor dem Namen. Sehe ich mir die Eigenschaften von /bin/mount an, erfahre ich "kein zugehöriges Programm" statt "Gemeinsame Bibliothek".

Könnt ihr mich bitte aufklären, ob ich hier etwas verpasst habe oder was hier falsch ist. Verschiedene Suchbegriffe habe ich versucht, aber finde nichts. Formulierung?

Gruss H.

[rhHeini]

Stichwort usrmerge

[halo44]

Danke Dir für den Hinweis. Jetzt weiß ich, um was es geht. Zumindest lese ich das so, dass /bin, /sbin und /lib jetzt unter /usr zuhause sind. Aber auch da sind alle Einträge mit ! und "kein zugehöriges Programm" eingetragen.

Wenn ich versuch usrmerge zu installieren, erhalte ich "usrmerge ist schon die neueste Version (35)".

Die Debian wiki-Seite klärt mich nicht wirklich auf.

Gruss H.

[rjh]

/bin und /sbin sind seit Jahren Symlinks zu /usr/bin und /usr/sbin. Gib mal im Terminal

Code: Alles auswählen

which mount

ein und versuche in Deinem Skript den kompletten Pfad.

[chrbr]

Hallo halo44,
die Einträge mit dem Ausrufungszeichen sind Links. Hier ist eine gestutzte Ausgabe von ls -li. Aus Kompatibilitätsgründen gibt es noch /bin und so weiter, allerdings als Link. In späteren Debian Versionen werden /bin, /lib und so weiter wegfallen.

Code: Alles auswählen

      12 lrwxrwxrwx   1 root  root      7 23. Okt 2022  bin -> usr/bin
      14 lrwxrwxrwx   1 root  root      7 23. Okt 2022  lib -> usr/lib
      15 lrwxrwxrwx   1 root  root      9 23. Okt 2022  lib32 -> usr/lib32
      16 lrwxrwxrwx   1 root  root      9 23. Okt 2022  lib64 -> usr/lib64
      17 lrwxrwxrwx   1 root  root     10 23. Okt 2022  libx32 -> usr/libx32
      13 lrwxrwxrwx   1 root  root      8 23. Okt 2022  sbin -> usr/sbin

[halo44]

Danke Euch allen. Ganz offensichtlich ist usrmerge bei mir korrekt gelaufen. Das Problem sind offensichtlich Pfadangaben wie /bin/mount. Richtig muss das heißen /usr/bin/mount oder einfach mount mit Rootrechten.

Richtig so?

Gruss H.

[JTH]

Das Problem sind offensichtlich Pfadangaben wie /bin/mount. Richtig muss das heißen /usr/bin/mount oder einfach mount mit Rootrechten.

Richtig so?

Nee, eigentlich nicht. Bei einem korrekten usrmerge – nach dem es bei dir durchaus aussieht korrigiere: das kam ja von chrbr – muss alles drei funktionieren, auch als nicht-root:

Code: Alles auswählen

~$ mount
[…]
~$ /bin/mount
[…]
~$ /usr/bin/mount
[…]

Die letzte Variante ist nun durch den usrmerge-Symlink möglich, aber keineswegs zwingend überall zu benutzen.

Wie sieht bei dir denn die Ausgabe von

Code: Alles auswählen

ls -ld /bin /sbin /lib

aus, halo44?

[halo44]

Das ergibt:

Code: Alles auswählen

lrwxrwxrwx 1 root root 7 13. Okt 2021  /bin -> usr/bin
lrwxrwxrwx 1 root root 7 13. Okt 2021  /lib -> usr/lib
lrwxrwxrwx 1 root root 8 13. Okt 2021  /sbin -> usr/sbin

Gruss H.

[rhHeini]

In einem Skript hilft es wenn Du anfangs den Pfad definierst so wie Du ihn brauchst. So ein Skript macht eine neue Shell auf die erst mal keinen Pfad kennt.

[halo44]

Danke, schon wieder was gelernt.

Gruss H.

[MSfree]

In einem Skript hilft es wenn Du anfangs den Pfad definierst so wie Du ihn brauchst. So ein Skript macht eine neue Shell auf die erst mal keinen Pfad kennt.

Danke, schon wieder was gelernt.

Gruss H.

Dann vergiß das Gelernte gleich wieder, denn es stimmt nicht.

Ein Skript öffnet keine neue Shell, das Skript wird von der Shell, in der man das Skript startet, direkt interpretiert und ausgeführt.

Ausserdem erbt jedes Programm und jedes Skript sämtliche Umgebungsvariablen, die in der aufrufenden Shell gesetzt sind, also auch die PATH-Variable.

Es gibt natürlich Methoden, die diesen Vererbungsmechanismus ausschalten oder manipulieren, diese sind jedoch die Ausnahme und nicht die Regel.

[rhHeini]

In einem Skript hilft es wenn Du anfangs den Pfad definierst so wie Du ihn brauchst. So ein Skript macht eine neue Shell auf die erst mal keinen Pfad kennt.

Danke, schon wieder was gelernt.

Gruss H.

Dann vergiß das Gelernte gleich wieder, denn es stimmt nicht.

Ein Skript öffnet keine neue Shell, das Skript wird von der Shell, in der man das Skript startet, direkt interpretiert und ausgeführt.

Ausserdem erbt jedes Programm und jedes Skript sämtliche Umgebungsvariablen, die in der aufrufenden Shell gesetzt sind, also auch die PATH-Variable.

Es gibt natürlich Methoden, die diesen Vererbungsmechanismus ausschalten oder manipulieren, diese sind jedoch die Ausnahme und nicht die Regel.

Nö, Deine Aussage halte ich für ein Gerücht. Widerspricht den Ratschlägen in Skripten entweder den vollen Pfad vor einem Befehl oder zu Beginn gleich den Pfad zu definieren. Hab ich mühsam so gelernt. Gibt es x Tutorials und 100000 Fäden in verschiedenen Foren dazu.

[MSfree]

Nö, Deine Aussage halte ich für ein
Gerücht.

Probier es selbst aus:

Öffne eine Schell und tippe dort ein:

Code: Alles auswählen

echo $PATH

Schreibe ein kleines Testscript mit folgendem Inhalt:

Code: Alles auswählen

#!/usr/bin/bash
echo $PATH

und führe das Testscript in derselben Shell aus.

Widerspricht den Ratschlägen in Skripten entweder den vollen Pfad vor einem Befehl oder zu Beginn gleich den Pfad zu definieren.

Nein, es widerspricht dem nicht.

Wenn du Skripte z.B. von cron ausführen läßt, erbt das Script die Umgebungsvariablen von cron und nicht die der Loginshell. Unter anderem ist dann auch die PATH-Variable anders oder nicht definiert. Und genau darum wird empfohlen, mit Absolutpfaden (oder auch mit der Definition von PATH) zu arbeiten.

[JTH]

Das ergibt:

Code: Alles auswählen

lrwxrwxrwx 1 root root 7 13. Okt 2021  /bin -> usr/bin
lrwxrwxrwx 1 root root 7 13. Okt 2021  /lib -> usr/lib
lrwxrwxrwx 1 root root 8 13. Okt 2021  /sbin -> usr/sbin

Das sieht erstmal richtig aus.

Code: Alles auswählen

~$ mount
[…]
~$ /bin/mount
[…]
~$ /usr/bin/mount
[…]

Was machen diese drei Aufrufe bei dir in ner interaktiven Shell? Bisher schriebst du ja nur von Problemen in einem Skript. Und wenn bisher nichts weiterführt, müsstest du mal verraten, um was für ein Skript es sich handelt und wie, in welcher Umgebung es aufgerufen wird – interaktiv, in nem .desktop-Starter wie manch einer das macht, in nem Cronjob, wie MSfree gerade schrieb, als systemd-Dienst, per udev-Trigger, etc. etc.

Nö, Deine Aussage halte ich für ein Gerücht. Widerspricht den Ratschlägen in Skripten entweder den vollen Pfad vor einem Befehl oder zu Beginn gleich den Pfad zu definieren. Hab ich mühsam so gelernt. Gibt es x Tutorials und 100000 Fäden in verschiedenen Foren dazu.

Das ist so als ausschließliche Vorgehensweise wirklich nicht richtig. Es gibt Situationen/Umgebungen, in denen es sinnvoll sein kann oder notwendig ist, selbst einen PATH zu definieren. Das ist – in meiner Erfahrung und spontanen, groben Einschätzung – aber wirklich die Ausnahme. Und besonders bei Skripten, die man interaktiv ausführt, kaum notwendig. Bei letzterem gelegentlich sogar kontraproduktiv, weil du evtl. einen im Benutzerkontext festgelegten und so gewollten PATH a la

Code: Alles auswählen

PATH=/home/user/bin:/usr/bin:/bin

mit

Code: Alles auswählen

PATH=/usr/bin:/bin:$PATH

in einem Skript überschreibst. Beides der Übersichtlichkeit halber verkürzt. Das ist zugegeben konstruiert, man würde eigentlich hinten etwas anhängen. Taugt hoffentlich trotzdem als Beispiel, warum PATH nicht immer neu gesetzt werden muss/sollte.

Du kannst ja mal in /bin und /sbin gucken:
Dort gibt es bei mir hier beispielsweise 420 Dateien/Anwendungen, die eine Shell-Shebang haben:

Code: Alles auswählen

~$ grep -EIlr '^#!/bin/.*sh' /{,s}bin | wc -l
420

aber nur 28, die eine Zeile mit PATH= oder export PATH= enthalten:

Code: Alles auswählen

~$ grep -EIlr '^\s*(export)*\s*PATH=' /{,s}bin | wc -l
28

Das ist nicht repräsentativ und auch nicht fehlerfrei, ein PATH kann ja in einem eingebundenen, ge-source-ten Skript definiert werden. Aber ich denke, es gibt dir einen Anhalt, dass nicht überall ein PATH extra festgelegt wird.

[tobo]

Ein Skript öffnet keine neue Shell, das Skript wird von der Shell, in der man das Skript startet, direkt interpretiert und ausgeführt.

Nö, ein Skript öffnet eine neue Subshell. Willst du die Skript-Befele in derselben Shell ausführen lassen, dann muss die Datei an source aufgerufen werden.

[halo44]

...

Code: Alles auswählen

~$ mount
[…]
~$ /bin/mount
[…]
~$ /usr/bin/mount
[…]

Was machen diese drei Aufrufe bei dir in ner interaktiven Shell? Bisher schriebst du ja nur von Problemen in einem Skript. Und wenn bisher nichts weiterführt, müsstest du mal verraten, um was für ein Skript es sich handelt und wie, in welcher Umgebung es aufgerufen wird – interaktiv, in nem .desktop-Starter wie manch einer das macht, in nem Cronjob, wie MSfree gerade schrieb, als systemd-Dienst, per udev-Trigger, etc. etc.

Alle drei bringen die gleiche Ausgabe

Code: Alles auswählen

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=7836864k,nr_inodes=1959216,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1575500k,mode=755,inode64)
/dev/sdb8 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13812)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /Daten-1 type autofs (rw,relatime,fd=57,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15634)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sdb7 on /Daten-1 type ext4 (rw,relatime)
/dev/sdb9 on /home type ext4 (rw,relatime)
/dev/sdb7 on /nfs4exports/daten-1 type ext4 (rw,relatime)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1575496k,nr_inodes=393874,mode=700,uid=1000,gid=1000,inode64)
/dev/mapper/_datenpartition on /Datenpartition type ext4 (rw,relatime)
/dev/mapper/_lokalsicherung on /lokalsicherung type ext4 (rw,relatime)

Das Skript liegt in einer Datenpartition des Users und wird in einem cronjob (/etc/crontab) aufgerufen und sah zum Fehlerzeitpunkt so aus

Code: Alles auswählen

#!/bin/sh
#
if [ -e /home/halo44/m2-ssd ]; then
/bin/mount /dev/mapper/_m2-kopie /M2-Kopie
rm /home/halo44/m2-ssd
fi
#
exit 0

Unter Bullseye lief das problemlos. Ich habe es inzwischen auf /usr/bin/mount geändert und es läuft jetzt auch unter Bookworm.

Vielen Dank für Eure zielführende Hilfe.

Gruss H.