fwupd <-- passim.service <- Avahi.. but using systemd-resolved

Cvlc · 2023-10-03 10:45:31

Hi,

After updating, I encountered the error message described here https://bugs.archlinux.org/task/79770

The workaround from the bug report is to run 'systemctl enable --now avahi-daemon.socket', however I'm using systemd-resolved, so I'd rather leave avahi disabled.

There's an upstream bug report as well, but the issue seems to be gone on its own (strange) : https://github.com/fwupd/fwupd/issues/6179

What's the proper way to work around this ?

Thanks !

3beb6e7c46a615a · 2023-10-03 12:41:10

Can't you just mask passim.service as suggested in that ticket?

Cvlc · 2023-10-03 15:19:01

It works, but it doesn't feel right to mask an unknown service after an update to clear errors.

3beb6e7c46a615a · 2023-10-03 15:26:04

Well, that's the standard systemd way to entirely disable a service you'd not like to use. And it's certainly not an unknown service; you can run "pacman -Si passim" and follow the website link to learn about what it does, and whether you need it.

seth · 2023-10-04 06:53:40

Can we please take a step back and record that a firmware updater hard depends on a distributed LAN cache that in turn hard depends on a *specific* mDNS implementation and figure how batshit crazy that all sounds? I mean, like, when did we stop designing stuff before just winging it?

@Cvlc, according to

https://archlinux.org/packages/extra/x86_64/passim/ wrote:

fwupd (requires libpassim.so)

the dependency only exists to resolve a library so it seems perfectly fine to disable that service. Notably if you're not benefitting from such distributed cache in your LAN itfp.

https://bugs.archlinux.org/task/79614 already ruled out the sane solution (splitting the shared object you need to resolve the linker dependency from the actual service you don't use) for reasons™

Bat.Shit.Crazy.

3beb6e7c46a615a · 2023-10-04 08:27:33

Stop shooting at the messenger. Complain to upstream. Maybe they'll listen if you start covering their CDN bills.

But don't waste our time with pointless rants.

PS: For this purpose (service discovery) Avahi is not just some specific mdns implementation, it's the only one in fact.

Last edited by 3beb6e7c46a615a (2023-10-04 08:48:19)

seth · 2023-10-04 09:00:08

What messenger and what CDN bills?
And there's nothing to report anymore, see the linked bug.

I get where the service requires mDNS to discover peers, but that doesn't explain to hard depend on it (let alone opecific one) and time out about it. You'd check for the service and use it if it's there, not fall oń your nose if there's no mDNS response. That's just inept.

I also get why firmware updates (or, anything...) might benefit from proxies but regardless of how silly it is to implement a proxy system in a random client, this is where arch takes over the crazy by turning an ld dependency into one of a running service that mandates yet another service on top of it.

This is crazy on three layers, the distro would be in position to cut this BS, upstream has even suggested that and the users fall through the cracks of this three stooges performance.

What brings us to Cvlc's question and my answer: you can safely mask that service because its involvement is the result of a coplete clownshow.
Sorry if you see that as a rant, but it's the reality of the status quo.

Edit: idk for certain, but it seems resolved's service discovery is just badly documented:
https://github.com/systemd/systemd/issues/19654
And that's besides the point.

Last edited by seth (2023-10-04 09:05:59)

3beb6e7c46a615a · 2023-10-04 13:40:05

I guess we have a different perspective on this "reality" you're talking about, and we certainly do have a very different attitude about respect for the (unpaid) time of (volunteer) upstream maintainers and the decisions they make between a rock and a hard place. With that said, and the OPs question answered, you'll forgive me if I leave it at that and unsubscribe from this thread.

seth · 2023-10-04 14:03:59

Fine, but there's neither a rock nor a hard place here.

The arch package maintainer suggests fwupd should™ have passim as runtime dep, fwupd suggests the package should™ make the service a runtime dep and only hard depend on the library.
Neither would be anywhere near impossible, nor a force to choose between two evils or whatever - it's just that every involved party considers this to be SEP and the users are expected to work around the resulting stalemate by installing a service only to immediately mask it.

This also has nothing to do with volunteering or payment - stop using "it's free" as an excuse for mediocrity.
Also nobody has asked "I don't know how to dlopen, can you help?" or "I don't have the time to split the package, can you help?"

You could rather claim and it's indeed easy enough to work around this sillyness by either compiling a custom fwupd or masking that service or just block it NoExtract or w/ a ALPM hook.
That just doesn't change anything about the status quo and how we got there.

brittyazel · 2023-10-09 21:59:50

I have filed a bug report about this against the Passim package here: https://bugs.archlinux.org/task/79897

In Richard Hughes's own words: "In fedora passim-libs is installed by default, but the passim package (the daemon) is only installed when wanted. Can arch split up the passim package like that too?"

As such, if we were to follow the author's suggestion and package in the way that Fedora does, fwupd would only depend on passim-libs, while Passim itself (the service) would be user opt-in via installing the package knowingly.

EDIT: Nvm the bug report was closed as a wontfix due to "We don't do split packages for libs."

Last edited by brittyazel (2023-10-09 23:20:12)

seth · 2023-10-10 07:02:04

The problem here is a stalemate - everyone has kinda point, but the result is a clusterfuck.

- It's perfectly fine to write a client-side distributed local cache (I'm not saying that that's very effective, but neither is your average hello-world) that operates on a very specific network stack
- It's perfectly fine to wanting to pot. benefit from that system and allow your client to be compiled w/ support for it
- It's perfectly fine to compile packages w/ the default config out of principle
- It's perfectly fine to not split packages out of principle reasons

The consequence however is that a single client mandates you to arrange your network around it to accommodate a client-side cache with benefits and that is, to quote myself: batshit crazy.
If we spin this approach into insanity, you might have some systemd-curld replacing curl that mandates mDNS resolution via systemd-resolved and firefox that mandates mDNS via ahavi and a campus firewall/policy that says "we're not doing weird-ass zeroconf magic bus into the disaster zone here!" and then what?

Clients are supposed to make network requests on the stack they operate on, not try to re-arrange that. There was this entire network-layer thing about that…
Next step:

chromium wrote:

What, copper? I'm not downloading that porn for you. I am a optical fiber browser and I have my standards.

Bat.Shit.Crazy.

jdane · 2023-10-12 08:47:37

I wrote a PKGBUILD for my own use that makes a passim-lib-bin package from the Arch Linux passim package: https://dpaste.com/5UMRW8XE9.txt

After building and installing that, fwupd can be installed without it pulling in passim. I'm not sure it is needed but I appended this line to /etc/fwupd/fwupd.conf to tell fwupd to not publish any files with passim:

P2pPolicy=none

Afterwards fwupdmgr get-updates works fine.

I have only one device using fwupd so using passim wouldn't reduce my downloads, as I understand it.

cmm11 · 2023-10-12 13:12:35

Was wondering too why this package and it's releated service account was created and it's due to fwupd depending on passim, and kinfocenter depending on fwupd.
As someone who only tries to install what they plan to use (never going to use fwupd) i ended up editing the pkgbuild of kinfocenter to not depend on fwupd.
Debian's kinfocenter package does not depend on it and fedora lists it in the spec file as a recommend not a requirement.

Last edited by cmm11 (2023-10-12 13:12:49)

3beb6e7c46a615a · 2023-10-12 17:17:39

Again, you can just mask passim with "systemctl mask passim.service".

cmm11 · 2023-10-12 19:30:55

You completely missed my point lunaryorn.

Last edited by cmm11 (2023-10-12 19:31:02)

seth · 2023-10-12 19:36:14

Check

ldd /usr/lib/qt/plugins/plasma/kcms/kinfocenter/kcm_firmware_security.so

to make sure it doesn't end up w/ unresolved dependencies and then you could file a bug against the package to turn fwupd into an optional dependency.

That's however also only tangential to the core issue, there might be enough users w/ desire for fwupd but not avahi.

cmm11 · 2023-10-12 19:48:10

seth wrote:

you could file a bug against the package to turn fwupd into an optional dependency.

I did and fwupd has been changed to be an optional dependency, so many thanks to arojas for the quick change.

Last edited by cmm11 (2023-10-12 19:48:25)

3beb6e7c46a615a · 2023-10-12 21:26:18

cmm11 wrote:

You completely missed my point lunaryorn.

I did not specifically reply to you, for as said before, your point was only tangential to the issue of this thread.

Last edited by 3beb6e7c46a615a (2023-10-12 21:27:16)

Cvlc · 2023-10-26 15:39:41

Thanks everyone for their answers, sorry I somehow never got the subscription notices.

lunaryorn wrote:

Well, that's the standard systemd way to entirely disable a service you'd not like to use. And it's certainly not an unknown service; you can run "pacman -Si passim" and follow the website link to learn about what it does, and whether you need it.

What I meant is that this showed up after a regular update, not after installing fwupd. I'm OK with disabling an unwanted service after installing something or when setting up the system, but it doesn't feel right to reboot after an update and discover a failed service.

Anyway, thanks and I've masked it.

Arch Linux

#1 2023-10-03 10:45:31

fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#2 2023-10-03 12:41:10

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#3 2023-10-03 15:19:01

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#4 2023-10-03 15:26:04

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#5 2023-10-04 06:53:40

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#6 2023-10-04 08:27:33

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#7 2023-10-04 09:00:08

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#8 2023-10-04 13:40:05

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#9 2023-10-04 14:03:59

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#10 2023-10-09 21:59:50

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#11 2023-10-10 07:02:04

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#12 2023-10-12 08:47:37

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#13 2023-10-12 13:12:35

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#14 2023-10-12 17:17:39

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#15 2023-10-12 19:30:55

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#16 2023-10-12 19:36:14

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#17 2023-10-12 19:48:10

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#18 2023-10-12 21:26:18

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

#19 2023-10-26 15:39:41

Re: fwupd <-- passim.service <- Avahi.. but using systemd-resolved

Board footer