udisks2 und systemd

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
fischig
Beiträge: 3602
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

udisks2 und systemd

Beitrag von fischig » 27.09.2021 19:11:51

Unter buster ist hier Debianudisks2 über Debianlibpam-systemd von Debiansystemd 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
Moderator
Beiträge: 3015
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: udisks2 und systemd

Beitrag von JTH » 27.09.2021 20:34:37

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 Debianequivs 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.
Manchmal bekannt als Just (another) Terminal Hacker.

fischig
Beiträge: 3602
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: udisks2 und systemd

Beitrag von fischig » 27.09.2021 20:46:01

Danke sehr! Sieht ja gut aus. Find ich gut, was der Entwickler/Paketbetreuer da gemacht hat.
JTH hat geschrieben: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
Beiträge: 3602
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: udisks2 und systemd

Beitrag von fischig » 28.09.2021 13:48:58

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

Re: udisks2 und systemd

Beitrag von willy4711 » 28.09.2021 15:45:24

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
Moderator
Beiträge: 3015
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: udisks2 und systemd

Beitrag von JTH » 29.09.2021 13:50:51

fischig hat geschrieben: ↑ zum Beitrag ↑
28.09.2021 13:48:58
Ü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.


fischig hat geschrieben: ↑ zum Beitrag ↑
28.09.2021 13:48:58
Geht das nur mit /dev/...?
-b oder die Langform --block-device nehmen anscheinend /dev/… an, ja.

fischig hat geschrieben: ↑ zum Beitrag ↑
28.09.2021 13:48:58
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).

fischig hat geschrieben: ↑ zum Beitrag ↑
28.09.2021 13:48:58
Ich benutze weder systemd noch policykit1.
Sollte wohl funktionieren, wenn du udisksctl dann halt als root verwendest (oder?).
Manchmal bekannt als Just (another) Terminal Hacker.

fischig
Beiträge: 3602
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: udisks2 und systemd

Beitrag von fischig » 29.09.2021 14:56:12

Ich freue mich über diese prima Hilfe! Danke! :THX:
JTH hat geschrieben:
fischig hat geschrieben:Ü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 :wink: ).
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
JTH hat geschrieben: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.
JTH hat geschrieben:wenn du udisksctl dann halt als root verwendest.
Zumindest so lange, bis ich's ordentlich gescriptet habe.

JTH
Moderator
Beiträge: 3015
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: udisks2 und systemd

Beitrag von JTH » 02.10.2021 18:27:42

fischig hat geschrieben: ↑ zum Beitrag ↑
29.09.2021 14:56:12
Ich freue mich über diese prima Hilfe! Danke! :THX:
Solange du mir nicht wieder mit Dattel-Stracciatella-Eis um die Ecke kommst gerne ;)

fischig hat geschrieben: ↑ zum Beitrag ↑
29.09.2021 14:56:12
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, Debianudev 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.

fischig hat geschrieben: ↑ zum Beitrag ↑
29.09.2021 14:56:12
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.

fischig hat geschrieben: ↑ zum Beitrag ↑
29.09.2021 14:56:12
JTH hat geschrieben: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.
Manchmal bekannt als Just (another) Terminal Hacker.

fischig
Beiträge: 3602
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: udisks2 und systemd

Beitrag von fischig » 02.10.2021 20:53:29

JTH hat geschrieben: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
Moderator
Beiträge: 3015
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: udisks2 und systemd

Beitrag von JTH » 03.10.2021 12:38:25

Wie weit die Funktionalität von UDisks von udev abhängt kann ich dir ohne Recherche nicht sagen. Debianudisks2 hängt aber immerhin hart von Debianudev 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 Debianlibglib2.0-bin; funktioniert mit dbus-send aus Debiandbus 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'],)
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
smutbert
Moderator
Beiträge: 8320
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: udisks2 und systemd

Beitrag von smutbert » 03.10.2021 12:58:50

fischig hat geschrieben: ↑ zum Beitrag ↑
02.10.2021 20:53:29
[...] 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 Debianeject 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.

Antworten