Baslinux mailing list

[Sindi Keesan <keesan AT iamjlamb.com>]

On Thu, 1 Apr 2004, James Miller wrote:

> On Thu, 1 Apr 2004, Sindi Keesan wrote:
> 
> > I also discovered that you cannot boot with BL2 ramdisk and use installpkg
> > to install packages easily to the hard drive BL2.  First, BL2 ramdisk has
> > no installpkg (which is a script).  So I tried /mnt/sbin/installpkg to
> > install a package and it could not find /var/log/packages and quit.
> > I could possibly rewrite the script to /mnt/var/log/packages.

I read the man page for installpkg and learned that you can do
ROOT=/mnt /mnt/sbin/installpkg name.tgz to install name.tgz to /mnt 
using installpkg from mount but BL2 from RAMdisk.

> I think you might need to chroot to do this: I think Steven said chroot
> works in BL.  To do that, mount your HD BL install somewhere on the
> ramdisk you've booted to - say at /hd.  Then, do chroot /hd .  Once you do
> that, you'll be logged in and functioning as root in the BL filesystem on
> the HD (don't ask me much about how this works: I can sort of feel my way
> through it and have read about it and done it before, but am not real
> clear on exactly how it works).  You should be able to use installpkg or
> any other installed progs/libs on the system installed on the HD using
> that technique.  Again, I'm going on the recollection that Steven said
> recently that chroot'ing works under BL

> > While hunting for library downgrade help, I ran across the fact that mc
> > can be used to look at the files inside an rpm package and copy over just
> > the ones you want.  Has anyone tried this?  mc/mc-menu did not work for me
> > to install a couple of rpm packages, said they were the wrong format or
> > something similar.
> 
> If you install the full-blown MC from Slack, it should be able to do this:
> it should have installed all necessary dependencies (e.g., file
> compression/uncompression utils, its mailcap or whatever it uses to find
> the progs it needs for certain operations) etc.  I use the full-blown MC
> on my Debian system to do this sort of thing all the time - real handy.
> If you want to use the slimmed down version of MC from, say, JP's site,
> you'll have to do some manual tweaking and related package install to get
> that working.
> 
> James


Does the full mc also work for you to install rpm packages?  

I did a lot of poking around, remade three more links back to 2.1.3 
library files where the 2.2.5 files were not named 2.2.5, and found two 
additional files present in 2.2.5 but not in 2.1.3, one of which is needed 
by one of the two programs that I was unable to compile (that complained 
it could not find GLIBC_2.2) and by whatever version of perl I installed.  
(I thought I used the one from SW71 but maybe I got it from 8.1).

version 'GLIBC-2.2' not found (required by /lib/libdb.so.3)

I checked and libdb.so.3 is pointing to a file found in glibc 2.2.5 but
without any equivalent I could find in 2.1.3, so I was trying to compile a
program that does require the later library.  So it appears that some 
programs are written to require later libraries.  (Kermit is not one of 
them - the latest version compiled perfectly on BL1.)  This is a good 
reason for me to give up and put back glibco-2.2.5, which will also let me 
use Opera without a script to changing symlinks before and after use, and 
use packages from SW81.  

These five files from 2.2.5 were all dated May 18, and the 2.1.3 files
March 20 or 21.  I figured out what links had been remade by glibcso-
2.2.5-i386 from reading that file in /var/log/scripts with less.

This still leaves unexplained why I get ELF header error messages for the 
binaries from SW71 binutils including as and ar (which I used to use, and 
which Matrix Mole says still works for him):

error in loading shared libraries:  libc.so.6:  invalid ELF header.

Libc.so.6 is currently symlink to the 2.1.3 version (libc-2.1.3.so?)

I did strings lib/libc.so.6 |grep GLIBC  as instructed at one website 
and the answer contained only 2.1.3 or older, meaning it is indeed the 
2.1.3 glibc.

I did this on ALL the files in /lib and the only ones with 2.2 or 2.2.3 in 
them were the files left over from glibcso 2.2.5 which I had not deleted 
after I remade the symlinks.

There was something at another site about ld.so.cache having been changed 
to match the new library, but it is a binary file and I can't read it.
At this point I gave up for a while.

Time to read about ELF headers and what they do and where to find them.

Sindi