Remote Boot Nodes Update Problem

[PCZ]

All my windows and linux PC's updated fine. :bouncy:
The remote boot nodes didn't however, they got the update ok distribfold-update.tar.gz but didn't unpack it. :bang:
I had to manually extract the updated files from the archive.

Did the same thing happen to you IB ?

[rsbriggs]

Wonder if they have everything necessary to unpack the update?

[Welnic]

I usually change all of my farm, 2 duals and 5 single nodes that use a single for a server, to no net on the day of a changeover and then update them manually. On the last update I was gone but everything except the nodes updated with no problem. The nodes all had distrib-update files in their folders but they were not unpacked. I think that there was some kind of message in the error.log but I don't remember what it was. That's the only time I have tried, but I'll try with one of my nodes this time and see what happens.

[PCZ]

They probably didnt have gzip.
It would have been nice if they autoupdated but I expected problems.

Perhaps we can fix the image so they work properly next time ?

[rsbriggs]

I'll have to take a look tonight, but I would guess that if gzip is the problem we probably can:

1.) find gunzip or gzip or whatever is missing (probably in /usr/bin or /bin)

2.) copy it to corresponding directory in the image, something like /opt/ltsp/i386/usr/bin ( or maybe /opt/ltsp/i386/bin ) just remember that the mapping is /opt/ltsp/i386 == what the clients mount as /

Then, assuming that there aren't any lib dependencies, it's instantly fixed for all the clients. If there are dependencies, then the lib files would need to be moved over, too. I'd guess it needs, at a minimum, whatever the current equivalent of libc or libstdc is these days.

Let's see, you could try doing an ldd on /usr/bin/gzip for a dependency "quick check" - then see if all the required libs are already in the client image in the same place as on our system - again, remember that the /opt/ltsp/i386 is what the clients mount as / so that our /usr/lib -> /opt/ltsp/i386/usr/lib

You might just try moving over the gzip executable, telnet to one client, and then try to manually run the update to see what happens - it should tell you about any missing lib files. This shouldn't be very hard to fix, unless we start running into long chains of lib file dependencies...

[Welnic]

There is both gunzip and gzip in /opt/ltsp/i386/bin, but they are both links pointing at busybox in the same directory. Tar was not in there but when I just copied it over it didn't help. The client is reporting a SIG 11 fault in error.log when it tries to unpack the update. With the links pointing to this busybox thing I am way over my head. So if you guys figure anything out let me know, OK? :confused:

[Welnic]

So I got onto one of my nodes and tried to inflate a .tar.gz file. The gzip went fine. When I tried tar on the .tar file then it missed librt.so.1. I copied that to the directory and then I needed libc.so.6. After copying that I got:
ld-linux.so.2.: "version GLIBC 2.2.3 " not found (needed by libc.so.6)
After copying that file the next time I got the same message.

I also tried linking to lib files that were already in the node /bin directory, after the first two errors I ended up with "Bus error".

[Welnic]

I finally got tar to work, but for one reason or another I don't really know if the update will work or not.

Copied tar to /opt/ltsp/i386/bin (I miss tab completion when typing here)
Copied librt.so.1 to /opt/ltsp/i386/lib
Copied libc.so.6 to /opt/ltsp/i386/lib
ln -s ld-linux.so.2.new ld-linux.so.2 in /opt/ltsp/i386/lib

After that tar worked but my testing of whether the update actually worked went poorly.