Luis F Urrea wrote:
> 
> By default if I am not mistaken, flashdist does not include the "pkg_add"
> binary and therefore for the chroot suggestion you would at least need to
> get the "pkg_add" binary into the flash image.
> 
You are correcet


Luis F Urrea wrote:
> 
> The technique used in the flashdist script for getting things installed
> uses
> `ldd` on a binary to find it's library dependencies and have them copied
> to
> the image. This is more likely to work at least for dinamically linked
> binaries which are fairly straightforward and in which you often do not
> need
> anymore files than the binary and shared libraries.
> 
> You could use ldd as follows for wget as example:
> 
>  ldd /usr/local/bin/wget 2>/dev/null | egrep 'rlib|rtld' | awk '{print
> $7}'
> \
>     |sort -u | xargs tar -cvf - | tar -C /mnt/flashdist-image -xpf -
> 
> Where flashdist-image is the directory in which you have mounted the
> flashdist image
> 
> 
> Now, if you run ldd on the pkg_add binary you would get:
> 
> ldd: /usr/sbin/pkg_add: not an ELF executable
> 
> and I am not really sure why is that. Experts comments welcome here!
> 
First attampt didn't work, but I'll work with it some more.


Luis F Urrea wrote:
> 
> Another option may be to use the -B option from pkg_add to define the
> chrooted environment as the destination dir, but I can't confirm that it
> would work as expected.
> 
Tryed the -B option but I couldn't get that to work either



Luis F Urrea wrote:
> 
> For packages in which the structure of required files is more complex,
> daemons such as samba an the like, using ldd may not suffice and such
> programs may fail to execute mysteriously. In  such cases, the ktrace(1)
> and
> kdump(1) may come in handy.
> 
> ktrace followed by the filename will produce an output file named
> ktrace.out
> in the directory in which you run it. Then you need to use kdump command
> to
> inspect the previously generated ktrace.out, look for files that the
> program
> is attempting to open, particularly for the NAMI (name-to-inode)
> translation
> in order to get a clue of what files may be missing.
> 
> A third option involves creating a chroot sandbox environment and use two
> cookies to track file changes in the filesystem as described here:
> 
> http://labs.calyptix.com/openbsd-binary-patches-chroot.php
> 
> Readers familiar with OpenBSD ports will notice that this cookie technique
> is borrowed from the make system in the OpenBSD ports tree.
> 
> Hope this helps
> 
I'll read up on this.


Thanks Luis, the help is very appreciated.

Cheers
Brad

-- 
View this message in context: 
http://www.nabble.com/SOEKRIS---How-to-install-MTR-to-a-Flashdist-image-tp22636740p22668748.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Reply via email to