Some Notes on Installing Eggplant Functional on Current Ubuntu LTS

I wanted to share my notes on installing Eggplant Functional 22.5.0 on Ubuntu 22.04.2 LTS. It was successful and I’ve connected to our license server, created a new suite and starting working on new scripts under it. Additionally, I connected to a SUT and overall feel I’m ready to move forward. Without repeating steps already found in the online Eggplant documentation (I’ll link where relevant) here is the process I followed. I wrote it as experienced, mistakes and all, since it’s a good real-time expression of what you might experience yourself if you plan to run this same installation. Mileage may vary, of course…

Note: Eggplant officially supports Ubuntu 16, 20 64-bit for Eggplant Functional 22.5 so the experience here is based upon users who are running the latest LTS (Ubuntu 22.04.2) or a later version. The last LTS is going out of support, btw:

End of standard support for 18.04 LTS - 31 May 2023

0.Preparation: Read InstallNotes.txt that comes with the software archive download :slight_smile: I didn’t realize that already having GNUstep installed would be an issue and reading that first might have tipped me off. As you’ll note below, I had a dpkg error installing Eggplant initially as it could not overwrite my /etc/GNUstep/GNUstep.conf so I had to take a second stab at it.

Also, the installation documentation has some pre-requisites to install for Ubuntu so I installed Metacity GNOME Desktop prior to moving on:

1.Initial Install: I went with dpkg out of habit to install my Eggplant22.5.0.deb file. Having not read InstallNotes.txt I didn’t force the install into /usr/GNUstep/ - even though that requirement doesn’t affect Ubuntu I would have reviewed the install a little closer to see just where it was installing. Executing this:

$ sudo dpkg -i Eggplant22.5.0.deb


dpkg: error processing archive Eggplant22.5.0.deb (--install): trying to overwrite '/etc/GNUstep/GNUstep.conf', which is also in package gnustep-common 2.9.1-2

I decided to use apt instead and executed:

$ sudo apt install ./Eggplant22.5.0.deb

Now, I got the same GNUstep.conf error as with dpkg because… yep, apt uses dpkg to install/remove packages. Since I already have GNUstep installed on another system, I decided to simply remove it from my Ubuntu instance and gave the installation another go:

$ sudo apt install ./Eggplant22.5.0.deb

Unfortunately, it turns out that even after removing GNUstep and the /etc/GNUstep/ directory, the install generated the same overwrite error. It looks as though the Eggplant installation creates the directory later attempts to overwrite the GNUstep.conf file. An additional error that appeared this time was:

"N: Download is performed unsandboxed as root as file

…and noting the path of my downloaded file as:

couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Executing the following solved the problem as this is a known bug that’s been around for some time in Ubuntu which generally assumes you’re installing everything via the remote package manager fetch:

$ sudo chown -Rv _apt:root /var/cache/apt/archives/partial/
$ sudo chmod -Rv 700 /var/cache/apt/archives/partial/
$ sudo chown -R _apt:root /var/lib/apt/lists

So why not simply right-click the file and select “Open with Software Install”? Well, I did exactly that next instead of re-running apt and it generated the same GNUstep.conf overwrite error. I remembered the failed install had likely created the directory since I had made sure it was deleted before executing my apt install, I went to delete it and discovered it wasn’t there…

Well, invisible directories aside, I decided to return to apt and then I remembered: Metacity; I forgot to log out and back in using Metacity desktop. I promptly did that and sure enough, the /etc/GNUstep/ directory was there. So, I promptly removed it and started again using Software Install:

And, the same error. So, it’s clear now that after removing this directory several times it is re-created by the installer and it sets itself up for failure down the road. Plan B:

$ dpkg --force-all -i Eggplant22.5.0.deb

Honestly, it was the last resort but after I did my forced install I was able to open Eggplant :wink:

Only to encounter the following:

$ eggplant -LicenserHost <ip-addr>

/usr/GNUstep/System/Tools/gpbs: error while loading shared libraries: cannot open shared object file: No such file or directory
/usr/GNUstep/Local/Applications/ error while loading shared libraries: cannot open shared object file: No such file or directory

So having installed tons of software on GNU/Linux systems I knew at least what this meant. The libraries needed weren’t in a standard location. I quickly identified where Ubuntu was keeping the main x86_64-linux-gnu libraries and found them at /lib/x86_64-linux-gnu/.

From the errors I already knew the Eggplant library locations:


Next, I searched for at least one of the libraries not found (Note: one of them turned out to be provided by libssl1.0.0 which is obsolete and no longer updated, something we need to return to later):

$ sudo find . -name

Which gave me:


Oh, snap - of course… So, after doing some ln -s on the first six libraries Eggplant complained about, I realized symlinks was not the way to go. It was starting to pile up. And since this library directory was under snap I figured it needed to get into Ubuntu’s library path, so first I ran:

$ cat /etc/*

Which gave me:

# libc default configuration
# Multiarch support

No surprise this was missing:

So, I did two things (possibly only one was needed, but to be sure…)

$ sudo ldconfig -n /snap/core/14946/usr/lib/x86_64-linux-gnu/ - ldconfig creates, updates, and removes the necessary links and cache.

And I added the snap libraries path to /etc/ and then I went and ran Eggplant again…

Note on libssl1.0.0: I’ll reach out to Eggplant on this. Obsoleted libraries should not be linked to in practice, although it’s common enough to do for software that is older and no longer under development. Even then there should be some safeguard against potential exploitation. I suspect there needs to be a general update to the Linux installers as most of the list of libraries I encountered missing were older ones removed by recent Ubuntu releases. Disclaimer: I have no idea if this is an issue, just noting it.

2.Executing Eggplant: Now, there are two ways to execute Eggplant. You can click the shortcut from the Ubuntu menu (assuming you’ve properly set up your LicenseHost.lic or simply run it from the command-line with the host identified. I chose the latter:

$ eggplant -LicenserHost <ip-addr>

From here all was good.

I should note in closing (although there is much to note for future updates) that in another VM I have of Ubuntu, after installation of Ubuntu 23.04 pretty much every library has been upgraded so Eggplant was not possible to install. This is fine since the target should be the LTS version, but even with the LTS Ubuntu there are some hurdles to jump over. However, once those were jumped over, all was good.

1 Like

Hey Chris,
thanks for putting it together and pretty sure you had some fun while doing it as well as the contribution here.
I can feel the same which I had when getting EPF finally startet on Ubuntu 20.04 and 22.04 :wink:
And good find with the LTS end date.


1 Like

@Karsten It was definitely fun :wink: I may return to a Red Hat or similar install when I have the time, but for now things are humming on Ubuntu! It’s important folks realize it isn’t all about the Eggplant installer, either. Windows and OS X keep very locked down and stable release cycles. While things may change across major releases for all OS, the major releases on these two are far enough apart that you rarely run into issues like these. I tend to prefer GNU/Linux but I also know (mostly) the ins and outs of changes between OS point releases, individual packages and all the other fun configuration-related pains that go with free and open source software. In the end, if you need it to work, you’ll get it to work and then you get to work :slight_smile: