udisks2 und systemd

[fischig]

Unter buster ist hier udisks2 über libpam-systemd von systemd abhängig.
Unter bullseye ist hier libpam-systemd nur noch eine Empfehlung für udisks2. Kann man hinkriegen, dass auch in buster udisks2 ohne systemd installierbar wird?

[JTH]

Die betreffende Änderung an udisks2 hat tatsächlich nur die Abhängigkeit verändert (Demote libpam-systemd to Recommends), nichts am Build des Pakets. Damit könntest du das wohl auch in Buster erreichen (warum kein Upgrade zu Bullseye? ).

Entweder baust du das Paket aus den Quellen sauber mit obiger Änderung neu, baust dir mit equivs einen Dummy für libpam-systemd oder machst es quick-and-dirty:

Code: Alles auswählen

~$ mkdir ~/fischigs-udisks2
~$ cd ~/fischigs-udisks2
~/fischigs-udisks2$ apt download udisks2
~/fischigs-udisks2$ dpkg-deb -R udisks2_2.8.1-4_amd64.deb fischigs-udisks2
~/fischigs-udisks2$ sed -i '/^Depends:/s/, libpam-systemd//; /^Recommends:/s/$/, libpam-systemd/' fischigs-udisks2/DEBIAN/control
~/fischigs-udisks2$ fakeroot dpkg-deb -b fischigs-udisks2
~# dpkg -i /home/fischig/fischigs-udisks2/fischigs-udisks2.deb

Dateinamen sind für dpkg völlig irrelevant, deshalb verkürzt ohne Version im Namen.

[fischig]

Danke sehr! Sieht ja gut aus. Find ich gut, was der Entwickler/Paketbetreuer da gemacht hat.

warum kein Upgrade zu Bullseye?

Och, ich hab's nicht so eilig. Ich schau lieber vorher etwas länger, was so alles auf mich zukommt. udisks2 interessiert mich im Zusammenhang mit diesem Thread viewtopic.php?f=27&t=182138

[fischig]

Code: Alles auswählen

udisksctl power-off -b /pfad/zum/block/device

Geht das nur mit /dev/...? In der manpage steht was von --object-path, aber mit dem Einhängeverzeichnis hat das hier nicht funktioniert. Übrigens auch nicht ohne vorheriges Aushängen des Laufwerks. Ich benutze weder systemd noch policykit1.

[willy4711]

Geht das nur mit /dev/...?

Wo hängt denn ein Laufwerk bei dir, wenn ich auf /dev ?
Naja warum sollte das mit einem kastriertem (wahrscheinlich unvollständigem) System funktionierten ?
Es sollte doch aber eine Fehlermeldung kommen (oder log)

Code: Alles auswählen

~$ apt depends udisks2
udisks2
  Hängt ab von: dbus
  Hängt ab von: libblockdev-fs2
  Hängt ab von: libblockdev-loop2
  Hängt ab von: libblockdev-part2
  Hängt ab von: libblockdev-swap2
  Hängt ab von: parted
  Hängt ab von: udev
  Hängt ab von: libacl1 (>= 2.2.23)
  Hängt ab von: libatasmart4 (>= 0.13)
  Hängt ab von: libblockdev-utils2 (>= 2.24)
  Hängt ab von: libblockdev2 (>= 2.25)
  Hängt ab von: libc6 (>= 2.14)
  Hängt ab von: libglib2.0-0 (>= 2.50)
  Hängt ab von: libgudev-1.0-0 (>= 165)
  Hängt ab von: libmount1 (>= 2.30)
  Hängt ab von: libpolkit-agent-1-0 (>= 0.102)
  Hängt ab von: libpolkit-gobject-1-0 (>= 0.102)
  Hängt ab von: libsystemd0 (>= 209)
    libelogind0
  Hängt ab von: libudisks2-0 (>= 2.9.0)
  Hängt ab von: libuuid1 (>= 2.16)
  Empfiehlt: dosfstools
  Empfiehlt: e2fsprogs
  Empfiehlt: eject
  Empfiehlt: libblockdev-crypto2
  Empfiehlt: ntfs-3g
  Empfiehlt: policykit-1
  Empfiehlt: libpam-systemd
  Empfiehlt: exfatprogs
  Schlägt vor: btrfs-progs
  Schlägt vor: f2fs-tools
  Schlägt vor: libblockdev-mdraid2
  Schlägt vor: mdadm
  Schlägt vor: nilfs-tools
  Schlägt vor: reiserfsprogs
  Schlägt vor: udftools
  Schlägt vor: udisks2-bcache
  Schlägt vor: udisks2-btrfs
  Schlägt vor: udisks2-lvm2
  Schlägt vor: udisks2-zram
  Schlägt vor: xfsprogs

[JTH]

Übrigens auch nicht ohne vorheriges Aushängen des Laufwerks.

Das ist der Manpage („ensuring that no process is using the drive“), einem Ausprobieren („Error powering off drive: The drive in use“) und dem Code nach so gewollt.

Geht das nur mit /dev/...?

-b oder die Langform --block-device nehmen anscheinend /dev/… an, ja.

In der manpage steht was von --object-path, aber mit dem Einhängeverzeichnis hat das hier nicht funktioniert.

Das --object-path nimmt anscheinend Gerätenamen, wie UDisks sie per D-Bus auflistet. Für einen meiner USB-Sticks wäre es hier z.B.:

Code: Alles auswählen

udisksctl power-off --object-path drives/Intenso_Ultra_Line_12345678901234

Das willst du vermutlich nicht von Hand benutzen, sondern dann, wenn du mit UDisks programmatisch kommunizierst.

Der Mountpoint wird mit power-off nicht funktionieren, da das Gerät dafür, wie oben beschrieben, nicht mehr in Benutzung sein darf (= nicht gemountet).

Ich benutze weder systemd noch policykit1.

Sollte wohl funktionieren, wenn du udisksctl dann halt als root verwendest (oder?).

[fischig]

Ich freue mich über diese prima Hilfe! Danke!

Übrigens auch nicht ohne vorheriges Aushängen des Laufwerks.

Das ist der Manpage („ensuring that no process is using the drive“), einem Ausprobieren („Error powering off drive: The drive in use“) und dem Code nach so gewollt.

Ich wollt's halt nur erwähnt haben, weil hikaru im anderen Thread vermutete, das man's vielleicht nicht brauchte.

Die „schnelle und schmutzige“ Inst-Variante auf einem Buster-System habe ich probiert, funktioniert aber nicht. fehlendes udevadm wird angemeckert (@willy: Meldung habe ich auf meinem „kaputten“ System leider nicht gesichert ).
Wir können es weiter verhandeln mit der bullseye-Version von udisks2. Auf einem alten X31 läuft das.
Auf meinem Hauptsystem bereite ich einstweilen den Übergang von Buster auf Bullseye vor. Wird etwas dauern. Ohne Verifizierung/Austesten, das Backup notfalls wieder benutzen zu können, mach' ich sowas nicht mehr

udisksctl power-off --object-path drives/Intenso_Ultra_Line_12345678901234

Wie komme ich an sowas ran? Staat dessen die entsprechende Gerätedatei jeweils unter /dev herauszusuchen, finde ich ziemlich unpraktisch. Ich hänge meine Sticks/USB-Festplatten in der Regel über Labels (angegeben in /etc/fstab) ein/aus.

wenn du udisksctl dann halt als root verwendest.

Zumindest so lange, bis ich's ordentlich gescriptet habe.

[JTH]

Ich freue mich über diese prima Hilfe! Danke!

Solange du mir nicht wieder mit Dattel-Stracciatella-Eis um die Ecke kommst gerne

Die „schnelle und schmutzige“ Inst-Variante auf einem Buster-System habe ich probiert, funktioniert aber nicht. fehlendes udevadm wird angemeckert […].
Auf meinem Hauptsystem bereite ich einstweilen den Übergang von Buster auf Bullseye vor.

Hmm, udev hat das System aber schon? Aber wenn du der Stabilität wegen noch vorsichtig mit Bullseye bist, ist ein Modifizieren von Paketen vielleicht auch nicht die beste Idee. Auch wenn UDisks jetzt kein essentielles Paket ist.

Wie komme ich an sowas ran? Staat dessen die entsprechende Gerätedatei jeweils unter /dev herauszusuchen, finde ich ziemlich unpraktisch. Ich hänge meine Sticks/USB-Festplatten in der Regel über Labels (angegeben in /etc/fstab) ein/aus.

Der einfachste Weg wäre dann wohl so etwas, am Beispiel meines erwähnten USB-Sticks:

Code: Alles auswählen

udisksctl unmount -b /dev/disk/by-label/INTENSO
udisksctl power-off -b /dev/disk/by-label/INTENSO

Die /dev/disk/by-label/... sind einfach nur Symlinks auf die /dev/sdxY, aber du kannst deine bekannten Labels benutzen. Ansonsten könnte man per udisksctl dump an diese Daten rankommen oder dann gleich das Ganze in Python o.ä. lösen und dabei per D-Bus mit UDisks kommunizieren.

wenn du udisksctl dann halt als root verwendest.

Zumindest so lange, bis ich's ordentlich gescriptet habe.

Auch dann wirst du udisksctl ohne policykit (wie du oben angemerkt hast) als normaler Benutzer wahrscheinlich nicht benutzen können.

[fischig]

Hmm, udev hat das System aber schon?

Eben nicht. Sonst hätte ich das schon mit /dev/disk/label probiert. Aber nun legt ja der Name wohl nahe, dass das Paket mit udev zusammenarbeitet. Das Einzige, was mich momentan an udisks interessiert, ist die Möglichkeit, via udisksctl per USB angeschlossene externe Platten stromlos zu machen. Bisher trenne ich die USB-Verbindung mechanisch, wenn ich den Datenträger ausgehängt habe. Aber wenn's ohne udev nicht machbar ist (es keinen object-path gibt), dann bleib' ich halt bei diesem Verfahren. Bisher ist mir wohl noch keine Platte abgeraucht.

[JTH]

Wie weit die Funktionalität von UDisks von udev abhängt kann ich dir ohne Recherche nicht sagen. udisks2 hängt aber immerhin hart von udev ab, hast du daran etwas gedreht? Edit: Wenn ich die Implementierung von udisksctl power-off so überfliege, tauchen da ein paar udev-bezogene Funktionsaufrufe auf. Wirst also, wenn du udev vermeiden möchtest, damit anscheinend nicht glücklich werden. Vielleicht könntest du die Funktionalität mit sync, (evtl.) hdparm und Schreiben nach /sys/… nachstellen – aber ob du das möchtest?

Den Objektpfad ohne /dev/… anhand des Labels auflösen ginge etwa so (braucht libglib2.0-bin; funktioniert mit dbus-send aus dbus leider nicht):

Code: Alles auswählen

~$ gdbus call --system --dest=org.freedesktop.UDisks2 --object-path=/org/freedesktop/UDisks2/Manager --method=org.freedesktop.UDisks2.Manager.ResolveDevice "{'label':<'INTENSO'>}" "{}"

Label INTENSO passend ersetzen. Liefert eine Ausgabe in folgender Form:

Code: Alles auswählen

([objectpath '/org/freedesktop/UDisks2/block_devices/sda1'],)

[smutbert]

[...] Bisher trenne ich die USB-Verbindung mechanisch, wenn ich den Datenträger ausgehängt habe. Aber wenn's ohne udev nicht machbar ist (es keinen object-path gibt), dann bleib' ich halt bei diesem Verfahren. Bisher ist mir wohl noch keine Platte abgeraucht.

So mache ich es auch und bei mir hat sich ebenfalls noch keine Platte beklagt.

Du könntest statt umount auch eject versuchen – es dient eigentlich dem Auswerfen von CDs, DVDs, Bändern, Disketten,... aber davor hängt es das Dateisystem aus und zumindest bei einer USB-Platte, die ich hatte, hat es auch die Platte ausgeschaltet.