eXtrema 4.7.0 failing to launch on HP thin clients running Ubuntu 16.04 LTS

[mj162]

1. Expected Behaviour

$ chmod +x ./eXtrema-x86_64.AppImage
$ ./eXtrema-x86_64.AppImage

[ App Launches ]

2. Actual Behaviour

$ chmod +x ./eXtrema-x86_64.AppImage
$ ./eXtrema-x86_64.AppImage
(extrema:10693): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
/tmp/.mount_eXtremKup812/usr/local/bin/extrema: symbol lookup error: /tmp/.mount_eXtremKup812/usr/lib/libgtk-3.so.0: undefined symbol: g_log_structured_standard

3. Platform

HP ThinPro 7.1.0 SP-19.5 (Ubuntu 16.04.7 LTS (Xenial Xerus)) OS is in R/O flash -- no chance of user writing to /usr.

[esternin]

Sorry to hear this, @mj162, but

Ubuntu Linux 16.04 LTS reached the end of its five-year LTS window on April 30th 2021 and is no longer supported

The current version (4.7.0) was developed and AppImage compiled and tested on Ubuntu 18.04LTS and on RedHat 7. I don't really have any 16.04 platforms at my disposal, to reproduce the error. Could you update your installation, maybe?

Did the above suggestion

gdk-pixbuf-query-loaders > /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

work?

[esternin]

OS is in R/O flash -- no chance of user writing to /usr.

@mj162 I did not notice this the first time, sorry. It's been a while since we ran on thin clients.

Did you try fsunlock / fslock, or you do not have privileges and are not friendly with sysadmin?

I guess one solution is to find or create a Ubuntu 16.04 installation and re-compile wx and eXtrema from source, and use this instead of the AppImage.

[mj162]

On Mon, 24 Oct 2022 11:32:05 -0700, E Sternin wrote:

OS is in R/O flash -- no chance of user writing to /usr.

@mj162 I did not notice this the first time, sorry. It's been a while since we ran on thin clients.

Did you try fsunlock / fslock, or you do not have privileges and are not friendly with sysadmin?

I guess one solution is to find or create a Ubuntu 16.04 installation and re-compile wx and eXtrema from source, and use this instead of the AppImage.

@esternin: Thanks for your follow-up. Regrettably, I am the belegeured sysadmin of a clutch of 20 HP thin clients. HP advised how the flash can be unlocked but at the risk of invalidating OS support. Over the years, a sizeable collection of apps -- some free, others commercially paid -- have been "installed" onto an NFS mounted share. A little less than a half are AppImages on the share. Each app has a custom launcher that checks for availability of the app on the share or a local removable flash drive, sets installation home and, in some cases, copies user profile info under /tmp either for execution speed and/or for non-persistence.

Inevitably, being warned of the support implications of installing apps using the package installer and investing a lot of time in arranging for apps to function from a single copy on a share, the announcement of a new release of the OS was greeted with mixed feelings.

The work of building an image based on the now later release of HP's thin client OS is not there yet. For now, I will just have to chalk-up eXtrema to one of the (increasing) number of updates to apps that no-longer work on 16.04. There are a number of updates to apps that continue to work on 16.04, e.g. LibreOffice, Zoom, etc. that tardy migration off of HP's previous OS release hasn't been a show stopper. But each day, another app release requires later-than 16.04 meaning that the older release has to be frozen-in. A case in point; Citrix Workspace App 2209 released last month requires later libraries so that upgrade from 2207 will not be possible until OS migration. I guess I have my work cut out...

[esternin]

@mj162: since you are the sysadmin, I would try the

gdk-pixbuf-query-loaders > /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

suggestion first. If that allows eXtrema to proceed, then the problem is actually with the gd installation, and if you fix that, the AppImage should run as is. The AppImage was created on RHEL 7, and RHEL 7 pre-dates Ubuntu 16.04, I believe (kernel 3.10.0, gcc 4.8.5 20150623), so an update to HP's OS is not likely to resolve the problem.

eXtrema 4.7.0 is the first AppImage release ever, as the program was static for 10 years or so, and my priority is to debug a few remaining issues that arose in converting to wxWidgets 3.x. For my releases, I will continue to use RHEL 7, as this is still our production version, though I am hoping to convince our sysadmins to finally move up. RHEL 7 is the oldest platform I am ever likely to release on.

You could rebuild from source on a Ubuntu system whose executable are compatible with your thin client library collection. It would be unproductive for me to try to do it since I do not have a thin client to test it on, and you have a custom way of launching things from nfs mounts, anyway. My experience with thin clients is all in the world of NCD Xterminals, and is therefore server-centered; I was never a fan of the way HP went about their thin client model, precisely for the reasons you describe.

I just updated to wxwidgets 3.2.1 and had to recompile everything. It took an hour or so, and was not particularly painful.

[esternin]

@mj162: I ran into the exact same issue on the latest revision of Debian Linux on a Chromebook, but there it was a benign problem: it was just a WARNING from the GDK system due to some internal incompatibility, but eXtrema itself launched just fine.

I re-read your post again and realized that you do not really say whether eXtrema itself launched or not. Please, let me know whether this is actually a critical problem for you.

[mj162]

Hi @esternin, "Failing to launch" is literally correct. Minor defects like bad icons, warnings, opening full screen and obliterating the entire desktop etc., would haver drawn a grizzled sigh rather than a raised issue. I do accept that 16.04 is a bit long in the tooth but then it becomes a matter of pots and kettles. If nothing new worked on 16.04 I'd get my finger out. However plenty of frequently updated apps just keep going so I've been spoiled and haven't been as serious about migrating off ThinPro 7.1 (16.04) to ThinPro 7.2 (18.04) as perhaps I should, but equally looking forward to a long life doesn't seem so unreasonable (in apps).

Best,

----- Original Message ----- Date: Wed, 23 Nov 2022 08:45:47 -0800 From: esternin @.> To: esternin/eXtrema @.> Cc: mj162 @.>, Mention @.> Subject: Re: [esternin/eXtrema] eXterma 4.7.0 Failing to launch on Ubuntu 16.04 LTS (Issue #55)

@mj162: I ran into the exact same issue on the latest revision of Debian Linux on a Chromebook, but there it was a benign problem: it was just a WARNING from the GDK system due to some internal incompatibility, but eXtrema itself launched just fine.

I re-read your post again and realized that you do not really say whether eXtrema itself launched or not. Please, let me know whether this is actually a critical problem for you.

-- Reply to this email directly or view it on GitHub: https://github.com/esternin/eXtrema/issues/55#issuecomment-1325367206 You are receiving this because you were mentioned.

Message ID: @.***>

[esternin]

Thanks. I guess the only way then is to find or make a VM with 16.04 with tools and compile on it. I can do it, but no way to test.

[mj162]

@esternin, no, thank you. Obviously I am very willing to be test guinea pig.

Kindest regards

----- Original Message ------- Date: Wed, 23 Nov 2022 14:05:13 -0800 From: esternin @.> To: esternin/eXtrema @.> Cc: mj162 @.>, Mention @.> Subject: Re: [esternin/eXtrema] eXterma 4.7.0 Failing to launch on Ubuntu 16.04 LTS (Issue #55)

Thanks. I guess the only way then is to find or make a VM with 16.04 with tools and compile on it. I can do it, but no way to test.

-- Reply to this email directly or view it on GitHub: https://github.com/esternin/eXtrema/issues/55#issuecomment-1325711114 You are receiving this because you were mentioned.

Message ID: @.***>

[esternin]

@mj162: please try this

Unfortunately, this only seems to work on 16.04, but has theme images unrecognized on Ubuntu 22.04, and is younger than RHEL 7 (GLIB incompatible), so it cannot become the release image, and I cannot make my 16.04 virtual box be the production machine. But it might be good enough for your needs.

[esternin]

@mj162 Another thing to try. I noticed on Ubuntu, gdk-pixpuf-query-loaders never gets installed where the other gdk-pixbufs-* tools are, in /usr/bin. Instead, it gets left in /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --- but it is there!

So, put in the full path:

sudo bash
mkdir -p /usr/lib64/gdk-pixbuf-2.0/2.10.0
cd /usr/lib64/gdk-pixbuf-2.0/2.10.0/
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders > loaders.cache

and then try to run the AppImage again.

[esternin]

Since this seems like a unique platform situation, and since a native build as well as an AppImage built under Ubuntu 16.04 work without issues, I am assigning this a low priority, and since no testing has been reported for almost a year, I think we can close this issue.

[mj162]

On Fri, 27 Oct 2023 08:40:13 -0700, esternin wrote:

Since this seems like a unique platform situation, and since a native build as well as an AppImage built under Ubuntu 16.04 work without issues, I am assigning this a low priority, and since no testing has been reported for almost a year, I think we can close this issue.

I won't comment on your opinion of the uniqueness or rarity of HP ThinPro as a platform.

# os-release -a
HP ThinPro 7.1.0 SP-11.5 (Ubuntu 16.04.5 LTS (Xenial Xerus))
# which gdk-pixpuf-query-loaders
# find /usr -name gdk-pixpuf-query-loaders
#

It isn't there in HP ThinPro 7.1.

Even had it been, being an HP thin client, this would have invalidated HP support:

sudo bash
mkdir -p /usr/lib64/gdk-pixbuf-2.0/2.10.0
cd /usr/lib64/gdk-pixbuf-2.0/2.10.0/
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders > loaders.cache

Solutions need to free of changes to /usr /bin etc controlled by HP.

[esternin]

@mj162: I did not mean to offend your ThinPro (I just remembered that I may actually still have one somewhere...) ;-)

As I reported last year, I made a virtual machine with Ubuntu 16.04, installed its compilers, and compiled both wxWidgets and eXtrema on in, then packed it into a custom AppImage for you. I have not heard if you actually tried that custom AppImage and whether this Ubuntu 16.04 executable was compatible with your particular version of Ubuntu 16.04 installation.

If you are willing to keep testing things and are interested in the program, we can reopen the issue.

[mj162]

On Fri, 27 Oct 2023 09:16:49 -0700, esternin wrote:

@mj162: I did not mean to offend your ThinPro (I just remembered that I may actually still have one somewhere...) ;-)

Ouch! Don't take my word for it -- ask HP Support: We have a very love/hate relationship... ;-)

You know what it's like; one evaluates, chooses and eventually ends-up investing a lot of money and one's own time in a particular vendor's technology. You're then so far in that switching is painful.

I really, really, need to get off ThinPro 7.1. They've updated it several times to more recent, supported versions of Ubuntu.

I guess that when the pain of keeping an Ubuntu 16.04-based OS exceeds the pain of migrating to a more recent release, I'll do so (and no doubt find that actively maintained apps have a version that will run).

While so many things run just fine, then unless HP or Canonical pack some must-have feature, they're still to overcome my not inconsiderable inertia!

Enjoy your weekend :)

[esternin]

Just for you, I re-compiled static wxWidgets-3.2.3 and the current eXtrema (4.7.2rc) into eXtrema-x86_64-U1604.AppImage. It is now 46MB, and hopefully more stuff is in there, not requiring it to be in your ROM. Of course, certain run-time libraries will need to be there, they simply do not exist in static form, and it may well include gtk3 stuff, but it was completely compiled and assembled into an AppImage on a Ubuntu 16.04 virtual machine, so here's hoping.

Please, test.

As to the larger issue: you are in a trap. I have been in this trap many times before, and it hurts. I experience physical pain when I cart away old, perfectly functional, hardware, just because there is no-one but me interested in keeping it going. I will resist with all my might the temptation to dust off and revive the ThinPro that I have stashed away in a drawer in my lab good 12 years ago. But it's a trap nevertheless, so all I can say is: get out! save yourself! :-)

Cheers

[mj162]

On Fri, 27 Oct 2023 11:43:04 -0700, esternin wrote:

Just for you, I re-compiled static wxWidgets-3.2.3 and the current eXtrema (4.7.2rc) into [eXtrema-x86_64-U1604.AppImage]

(https://www.physics.brocku.ca/Labs/extrema/Downloads/eXtrema-x86_64-U1604.AppImage ). It is now 46MB, and hopefully more stuff is in there, not requiring it to be in your ROM. Of course, certain run-time libraries will need to be there, they simply do not exist in static form, and it may well include gtk3 stuff, but it was completely compiled and assembled into an AppImage on a Ubuntu 16.04 virtual machine, so here's hoping.

Please, test.

Oh man - thanks! Worked straight-off. (We'll elide the arguments over why anyone continues to package apps with dynamic libraries in an era when size doesn't matter...)

As to the larger issue: you are in a trap. I have been in this trap many times before, and it hurts. I experience physical pain when I cart away old, perfectly functional, hardware, just because there is no-one but me interested in keeping it going. I will resist with all my might the temptation to dust off and revive the ThinPro that I have stashed away in a drawer in my lab good 12 years ago. But it's a trap nevertheless, so all I can say is: get out! save yourself! :-)

While intuitively I know you're right, the corollary is that we all cede everything to Alphabet, Amazon, Apple, Meta or Microsoft; just have the dumbest thing in our hands or on our desktop and have every bit of the intelligence and storage -- a one-app phone and a one-app desktop; a browser.

(I too have tens of old Igel and HP thin clients gathering dust. If that's the price worth paying of "ploughing your own furrow" then begone Alphabet, Amazon, Apple, Meta and Microsoft!

Cheers

No, cheers to you!

[esternin]

Glad it worked out, so this is [solved].

No, you do not need to sell your soul to "Alphabet, Amazon, Apple, Meta or Microsoft". It's just that the hardware evolved so rapidly, the "thick" clients with an up-to-date Ubuntu install can now be had for a pittance, and they will self-update, and can be centrally managed, etc. So the time where thin-client model was the way to go may have passed.

Best of luck.

[mj162]

On Mon, 30 Oct 2023 08:46:30 -0700, esternin wrote:

Glad it worked out, so this is [solved].

Joy! Yes thanks it ran first time and I'm keen to cut my teeth on it.

No, you do not need to sell your soul to "Alphabet, Amazon, Apple, Meta or Microsoft".

Just their mention is ghoulish ahead of All Saints and All Souls...

It's just that the hardware evolved so rapidly, the "thick" clients with an up-to-date Ubuntu install can now be had for a pittance, and they will self-update, and can be centrally managed, etc. So the time where thin-client model was the way to go may have passed.

Sure I need to catch up!

"Thin" was atrractive both for centralised management but also because it militated against storing stuff on the device in "home" directories ("profile" in Windows-speak).

App launchers here force apps to run in a changed HOME of /tmp/user. That stops stuff being left-around and runs faster. Worthwhile customisations get promoted to site config in /etc.

Browsers are notoriously r/w intensive. A "thin" device thrashing its NAND flash not only reduces its life but runs noticeably slower.

Happy to revisit standard desktop self-updating Ubuntu if the world has settled on that as the model. Last I looked, too many download-and-go packaging standards (AppImage, Flatpak, SNAP) and too many individual apps (including AppImages) "helpfully" self-updating to somewhere buried in HOME directories making them suddenly balloon overnight.

Best of luck.

Thank you -- I hope more discover eXtrema appimage and give it a try!