Resending to list not Stefan!
On 01/26/2015 06:20 PM, Mike wrote:
On 01/26/2015 05:02 PM, Stefan Baur wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 26.01.2015 um 22:44 schrieb Short, Kermit:
It's certainly something I'd like to try, but if I recall correctly, the firmware is only loosely based on LTS. The actual OS on the thin client is heavily customized. Well, I hope I'm not talking out of my lower back here, but it can't be much more complicated than grabbing our packages, unpacking them, and checking for any dependencies that they need to have met.
Possibly apply some ldd and strace to see where things are going wrong. Yes, excellent advice! Although I'm a lazy admin and don't see the need for ldd or strace here. The .deb package info is able to give us all the reverse dependency information. Many ways to obtain it I'm sure, apt-cache showpkg or using the package search on the Debian website should revel all the needed information. Surely Ubuntu has a similar webpage available.
Working with debian packages is not something I've done much, and then only to build them rather than deconstruct them. It's actually not that hard. If you have a copy of midnight commander (mc) installed, you can usually go inside them like any other virtual file system (like when you "open" a *.tar.gz file with mc). There are also command line tools available to unpack Debian/Ubuntu packages without installing them.
ar x some-package_0.1.2.deb . dpkg --extract some-package_0.1.2.deb . dpkg -x some-package_0.1.2.deb .
Certainly there are other ways...
I do really like the idea of a chroot shell, though. I'm currently using AIDE to look at changes pre and post build, and then I go through interactive error messages on the IGEL to determine what additional libraries are necessary.
The last time I did this, there were several libraries provided by the LTS footprint that were not provided on the IGEL, so it's a little easier for me to do the scratch build, since I have to do some by hand tracing anyway. That sounds really painful. In a first step, I'd try to parse the output of ldd for every executable I want to copy, then make sure I have those files either available on the IGEL, or know I have copy them over along with the executable.
for example (this is on Debian Wheezy, not Ubuntu, but the process should be the same):
dpkg -L libnx-x11
gives
/.
<chopped some dpkg output>
and just grabbing one sample from here, /usr/lib/nx/X11/libNX_Xrender.so.1,
ldd /usr/lib/nx/X11/libNX_Xrender.so.1 gives
linux-gate.so.1 => (0xb7702000) libNX_Xext.so.6 => not found libNX_X11.so.6 => not found libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7583000) /lib/ld-linux.so.2 (0xb7703000)
As this is from a working system, I would assume the two "not found"s are harmless, but I need to make sure I have the other files on my target system in some way - either from the original OS image, or by copying them over. If memory serves X2Go is setting LD_LIBRARY_PATH to where the libNX* and probably other NX specific libs live. The dependency information of the .deb file(s) should point these out without having to use ldd.
Being able to do this from a debian package in a root shell would be very handy, though!! Well, I can't do more than suggest you try it and see if it turns out to be the easier way. :-)
How large is that extra partition you can access, anyway? Large enough to untar a complete non-IGEL linux distribution there and chroot or possibly even kexec into it?
Another option would be to offer one or more of your IGELs to interested developers so they can do the grunt work for you.
- -Stefan
Hopefully some of this can be of some help. If I can get away without building things from scratch I'm all for it. Like I said I'm a lazy admin, building software isn't one of my favorite things in life.
Mike
-
Mike