Change:
Describe the bug From IRC: ; Looks like we currently just use their appimage: and our appimage tooling uses buildUserFHSEnv: It seems like we can either: using (build from source, maybe?) similar to how iohk patches Daedalus.
I tried packaging it with yarn2nix, but stumbled upon , unfortunately.
I don't know much about the appimage architecture. Why exactly can we not run appimages natively without FhsUserEnv? Is it just because binaries linking against fhs paths? In this case we probably could run autoPatchelfHook on the contents of the appimage and produce a new image that links against nix libs. EDIT: I just tried this. Extracted the appimage contents, patched all binaries, but then when executing ledger-live-desktop, I'm getting: Currently I'm running ledger live via qemu + usb device passthru via . That works fine.
how difficult would it be to lift Daedalus's patch and use it for the libudev inside the fhs? I've never worked with FHS before, but also don't want to build ledger live from source...
I tried to build ledger live from source and it didn't work because of the issue that mentioned. Patching libudev worked though.
can you link to the patch? It would be great to be able to use my more-trusted nixos machines for these types of activities.
I already created a PR for it and it's referenced above. This one:
Feel free to comment in the PR whether it actually works for you :)
The patch had to be re-done in Should this problem probably be communicated to upstream, so we can think about how to fix this long-term in a more sustainable fashion?

Discussion:
<del> { lib, fetchurl, appimageTools, imagemagick }: </del> <ins> { lib, fetchurl, appimageTools, imagemagick, systemd }: </ins> let pname = "ledger-live-desktop";

appimageContents = appimageTools.extractType2 { inherit name src; }; <del> in appimageTools.wrapType2 rec { </del> <ins> # Hotplug events from udevd are fired into the kernel, which then re-broadcasts them over a # special socket, to every libudev client listening for hotplug when the kernel does that. It will # try to preserve the uid of the sender but a non-root namespace (like the fhs-env) cant map root # to a uid, for security reasons, so the uid of the sender becomes nobody and libudev actively # rejects such messages. This patch disables that bit of security in libudev. # See: https://github.com/NixOS/nixpkgs/issues/116361 systemdPatched = systemd.overrideAttrs ({ patches ? [ ], ... }: { patches = patches ++ [ ./systemd.patch ]; }); in appimageTools.wrapType2 rec { </ins> inherit name src; <ins> extraPkgs = pkgs: [ systemdPatched ]; </ins> extraInstallCommands = '' mv $out/bin/${name} $out/bin/${pname} install -m 444 -D ${appimageContents}/ledger-live-desktop.desktop $out/share/applications/ledger-live-desktop.desktop

<ins> diff --git a/src/libsystemd/sd-device/device-monitor.c b/src/libsystemd/sd-device/device-monitor.c index fd5900704d..f9106fdbe5 100644 --- a/src/libsystemd/sd-device/device-monitor.c +++ b/src/libsystemd/sd-device/device-monitor.c @@ -445,9 +445,6 @@ int device_monitor_receive_device(sd_device_monitor *m, sd_device **ret) { "sd-device-monitor: No sender credentials received, message ignored."); cred = (struct ucred*) CMSG_DATA(cmsg); -        if (cred->uid != 0) -                return log_debug_errno(SYNTHETIC_ERRNO(EAGAIN), -                                       "sd-device-monitor: Sender uid="UID_FMT", message ignored.", cred->uid); if (streq(buf.raw, "libudev")) { /* udev message needs proper version magic */ </ins>