Closed marcusmueller closed 7 months ago
laf0rge
commented
7 months ago thanks for the report!
It's maybe worth to note that this is a regression over uhd < 4.0.0.0 where the lack of said environment variables was non-fatal. So basically users of osmo-trx-uhd will upgrade their UHD version (e.g. as part of OS upgrade) and suddenly end up having non-working cellular base stations.
mbr0wn
commented
7 months ago Hey guys, thanks for reporting this. We have a fix rolling through CI pipelines and review etc.
As @marcusmueller writes, the intention was not to require people to specify these vars (although until our patch goes live, that's unfortunately required). The assumption that we could always find a $XDG_CONFIG_HOME by going through the list of rules was of course incorrect (as you point out, there's not always a user attached to a process). In other words, there was no intended policy change, but the introduction of the XDG standards compliance was buggy in a way that caused this to happen. And while this is clearly a standard case for you, it was obviously a niche enough case for it to be overseen all this while.
One more detail in case someone reads this at a later time (not directly related to this bug, but about finding images in general):
The Bugzilla page is closed, or I would have commented on there, but there is one thing that I would like to point out: @marcusmueller writes that specifically setting a images dir is a good idea, and I would like to add an explanation why. @laf0rge you point out that UHD should simply default to /usr/share/uhd/images, but that's actually more of a stretch than it might look. Until we have equivalent open-source FPGA tools (unfortunately, probably never) we have to do all the silly business about providing those bitstreams for download using the images downloader, or via our release binaries on GitHub (which is where some of the packaging people get them). That they then land in /usr/share/images/uhd is partly because we modify our uhd_images_downloader script based on the installation method, and partly because people are nice (see, e.g., https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/uhd/uhd-4.4.0.0.ebuild#n140). For example, if we can't find any environment vars to give us a clue, but we know that UHD is installed in /usr/lib/, then we go out on a limb and try /usr/share/uhd/images.
So, production or not, UHD will do its best to find the images (when its not stumbling over bugs introduced by the developers, ahem) but there's no guarantee it can always do that, because between OSes/distros/archs/personal preferences, they could be in all sorts of places.
Again, this is unrelated to this bug, and specifying the images dir would not have helped in this case because UHD would still have choked trying to find a HOME directory in case there's a config file. I'm just expanding on @marcusmueller's comment.
OK, I need to go back to destroying our brand name intentionally breaking people's downstream working on UHD stuff. Thanks again for the report!
Issue Description
https://osmocom.org/issues/6269
Basically, due to 1383fde3457168ed759d6ed3b913dfae8a6085ef , running an UHD-consuming application in an environment where there's no
$HOMEnor$XDG_CONFIG_HOMEfatally errors out.Setup Details
My repro: UHD4.4.0.0 on Fedora38;
yields
Expected Behavior
Running; not being able to find a config file is not fatal!
Also, the actual behaviour runs afoul of documentation:
Actual Behaviour
[INFO] [UHD] linux; GNU C++ version 13.0.1 20230127 (Red Hat 13.0.1-0); Boost_107800; UHD_4.4.0.0 [INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... Error: RuntimeError: get_xdg_config_home(): Unable to find $HOME or $XDG_CONFIG_HOME.
Steps to reproduce the problem
unset XDG_RUNTIME_DIR HOME uhd_usrp_probe
Additional Information
Issue arises when UHD-consuming Osmocom software is launched via systemd service.