[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Almost ready for v2.1.2

On Wed, 6 Nov 2002, R P Herrold wrote:
>On Tue, 5 Nov 2002, Eric Harrison wrote:

>My instinct is the answer will turn out to be that we do need
>to address this for cross-arch installs; that x86 is
>compatible across the line [see below -- the 686 library build
>variant linker is present on the current LTSP production
>release]; that the answer for 32 and 64 bit Sparc or a MIPS
>4000 RISC box is unknown; and that 32 and 64 PA-RISC will be
>interesting [the buildout of the 64 bit PA-RISC is in the
>early stages for the Linux kernel; if we are providing a
>binary tftp image from the manufacturer there is no
>maintenance capability and thus no issue, absent sources.]

Just to make sure we're on the same page, I was trying to point out
that the LTSP code can be served by a non-Linux server. All of the
interfaces between the server and the client (dhcp, nfs, X, etc) are
standard protocols - the server and the client do not need to be binary 

>> It seems to me that the right way to deal with this is have the client
>> run ldconfig itself. This avoids all of the cross-platform issues:
>> 	cp /sbin/ldconfig /opt/ltsp/i386/sbin/  # the i386 version of ldconfig!
>This is not the present case, interestingly ...
>[herrold www ltsp]$ ldd ./i386/lib/ld-linux.so.2 ; pwd
>./i386/lib/ld-linux.so.2: ./i386/lib/ld-linux.so.2: version 
>`GLIBC_PRIVATE' not found (required by /lib/i686/libc.so.6)
>        statically linked
>[herrold www ltsp]$

I happened to be testing a P100. When I copied over the ldconfig from my
PIII server, the P100 client would spit out an "illegal instruction" (or
something similar). I had to extract the ldconfig out of the i386 build
of glibc before it would work.

>> 	cd /opt/ltsp/i386/etc/
>> 	rm -f /opt/ltsp/i386/etc/ld.so.cache
>> 	ln -s /tmp/ld.so.cache /opt/ltsp/i386/etc/ld.so.cache
>> and then edit /opt/ltsp/i386/etc/rc.local, adding the following line right
>> after the "Creating ramdisk on /tmp" section (about line 69):
>> 	/sbin/ldconfig -C /tmp/ld.so.cache
>The scripting looks fine -- the statement that a chrooted
>ldconfig is sufficient is not clear (although in simple cases
>it seems to be).  Thus my initial qualification that testing
>must demonstrate such a change "(and must be) harmless"  "Is
>it harmless?" remains an open question.

Testing? We don't need no stinkin' testing! ;-)

My money is on moving the ldconfig over to the client. That's the only
way I can envision a mix of architectures and/or OSs working.

As today's thread on booting old Macs shows, there is a demand for
mixing different hardware.

This will be a fun one to work out!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]