So, I think I have a better handle on Appimage. It isn't a container in the same way as chroot/docker. So we do not package up or mirror any system files, it basically contains the libraries for the application and preprends it's folder containing these to the LD_LIBRARY_PATH. A side effect of this is that if we depend on a library that isn't included but happens to be on your system we will continue on quite happily. I don't think we can realistically actually add the file in question to the Appimage as it isn't something we can (or should) be packaging up.
From this thread https://lists.dyne.org/lurker/message/20190308.124740.2b7329de.en.html it looks like Devuan (at least back in March) doesn't supply /etc/machine-id as it normally is created by systemd at installation time. But if I am reading correctly dbus supplies /var/lib/dbus/machine-id which will often be a symbolic link to the /etc one. What happens if you run dbus-uuidgen --get (after removing the file you created). Is it possible something was squiffy in your dbus installation? The manpage for dbus-uuidgen suggests it is normally called in the post installation process. If you don't have one, then perhaps try running dbus-uuidgen --ensure Paul On Wed, Sep 18, 2019 at 9:14 PM David Tillotson <[email protected]> wrote: > > On Wed, 18 Sep 2019 20:03:00 +0100 > Paul Buxton <[email protected]> wrote: > > > Hmm, this looks pertinent > > https://wiki.debian.org/MachineId > > Interesting article. Reading that, I'm now even more puzzled as to what > this is for. Every claimed use is already covered by other mechanisms > as far as I know. > > > Can I ask when you added the file, was that in your local system, or > > did you somehow insert it into the appimage? My guess is the former... > > You are right with that guess - not sure how it would be added to the > appimage! > > > The end of that article assumes that chroot/container environments > > would populate the machine id from the host system into the container. > > I confess I am not 100% clear on how Appimage works, but I suspect it > > is combining the folders in the Appimage mount with the host system > > folders, and as your system doesn't use systemd this file doesn't > > exist. > > That does seem to be what is happening - creating a valid(ish) file > works, so whatever is using it doesn't care what is in the file. > Changing the file to a different one (32 1s) had no effect. > > > I will try and understand a bit more about how appimage works and see > > if I can suggest a proper solution unless someone who knows better can > > fix it first. :-) > > I would guess that adding a file to the appimage would work, if I could > figure out how. I'm happy to test any attempted fixes in the meantime. > > > On Wed, Sep 18, 2019 at 9:05 AM David Tillotson > > <[email protected]> wrote: > > > > > > I have discovered an issue with the layest AppImage, that seems to > > > be the result of an assumption by the included systemd components. > > > > > > On my Devuan system, I was unable to launch the AppImage, and on > > > checking found that it was due to a missing file > > > ("/usr/local/var/lib/dbus/system-id" or "/etc/system-id"). An empty > > > file isn't sufficient, as dbus expects a 32 char hex string, so I > > > just created a random one, which worked. > > > > > > Hopefully this is just a flaw in the AppImage build, and not > > > another step along the path from GNU/Linux to Systemd/GNU/Linux! ;-) > > > > > > David Tillotson > > > _______________________________________________ > > > subsurface mailing list > > > [email protected] > > > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
