4.9.3 AppImage issue

Paul Buxton paulbuxton.mail at googlemail.com
Wed Sep 18 23:59:41 PDT 2019


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 <david at acmelabs.co.uk> wrote:
>
> On Wed, 18 Sep 2019 20:03:00 +0100
> Paul Buxton <paulbuxton.mail at googlemail.com> 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
> > <david at acmelabs.co.uk> 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
> > > subsurface at subsurface-divelog.org
> > > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>


More information about the subsurface mailing list