Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I've attempted to upgrade from fun_plug-0.2 to fun_plug-0.3, but I'm having trouble starting dropbear in the chrooted etch environment. I get the following error:
/usr/sbin/dropbear: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory
If I switch back to 0.2, everything works great. I'm also starting sysklogd, cron, dovecot, and rsync and they all seem to work fine with 0.3.
I did some searching and came up with the idea that it may be related to environment variables persisting, but I haven't been able to confirm that. I've tried manually chroot'ing with "chroot etch /bin/sh -ls" and "chroot etch /bin/bash --login" and then starting dropbear, but I get the same error. I also noticed that even when starting like this, many environment variables persist, but the PATH looks correct (PATH=/usr/local/bin:/usr/bin:/bin:/usr/games).
If it isn't glaringly evident, I'm only familiar enough with linux to be dangerous. Any ideas?
Thanks,
Brian
Here is my 03_etch.sh from the fun_plug start directory: (the 03 ensures it runs after 01_telnetd.sh)
#!/bin/sh cd $VOL1 # Bind mount disk1 mkdir -p $VOL1/etch$VOL1 mount --bind $VOL1 $VOL1/etch$VOL1 # Bind mount disk2 # mkdir -p $VOL1/etch$VOL2 # mount --bind $VOL2 $VOL1/etch$VOL2 # Bind mount rootfs mkdir -p $VOL1/etch/mnt/root mount --bind / $VOL1/etch/mnt/root # Mount proc mkdir -p $VOL1/etch/proc mount --bind /proc $VOL1/etch/proc # Mount dev/pts mkdir -p etch/dev/pts mount --bind /dev/pts $VOL1/etch/dev/pts # Copy resolv.conf cp -f /etc/resolv.conf $VOL1/etch/etc # Set hostname hostname bandknas01 hostname >$VOL1/etch/etc/hostname # Copy hosts cp -f /etc/hosts $VOL1/etch/etc #chroot $VOL1/etch /linuxrc
And, here's my linuxrc:
#!/bin/sh # SYSLOG /etc/init.d/sysklogd start # Cron /etc/init.d/cron start > /var/log/cron-start.log 2>&1 # SSH /etc/init.d/dropbear start > /var/log/dropbear-start.log 2>&1 # Rsync /etc/init.d/rsync start > /var/log/rsync-start.log 2>&1 # Dovecot IMAP /etc/init.d/dovecot start > /var/log/dovecot-start.log 2>&1
Offline
It does not look like a PATH problem, but rather access to the library. Not sure, but I think that LD_LIBRARY_PATH is now defined in version 0.3, which could be a good reason why the .so lib is not found.
Offline
That was it! LD_LIBRARY_PATH was persistent. I manually started the chroot with "env -i", and dropbear starts normally.
Thanks,
Brian
Offline
Things seem to be working well again. In case it help someone else, I'm posting my chroot-related script files. Also, if you see something that could be done better or "more properly", please point it out.
Brian
03_etch.sh (runs after 01_telnetd.sh and 02_timezone.sh):
#!/bin/sh CHROOT=$VOL1/etch # Bind mount disk1 mkdir -p $CHROOT$VOL1 mount --bind $VOL1 $CHROOT$VOL1 # Bind mount disk2 # mkdir -p $CHROOT$VOL2 # mount --bind $VOL2 $CHROOT$VOL2 # Bind mount rootfs mkdir -p $CHROOT/mnt/root mount --bind / $CHROOT/mnt/root # Mount proc mkdir -p $CHROOT/proc mount --bind /proc $CHROOT/proc # Mount dev/pts mkdir -p $CHROOT/dev/pts mount --bind /dev/pts $CHROOT/dev/pts # Copy resolv.conf cp -f /etc/resolv.conf $VOL1/etch/etc # Set hostname hostname bandknas01 hostname >$CHROOT/etc/hostname # Copy hosts cp -f /etc/hosts $CHROOT/etc # Start chroot env -i TERM=vt102 USER=root $BINDIR/chroot $CHROOT /linuxrc
linuxrc (in root of chroot, your services may vary):
#!/bin/sh /etc/init.d/sysklogd start /etc/init.d/cron start /etc/init.d/dropbear start /etc/init.d/rsync start /etc/init.d/dovecot start
Offline
This is so strange...I was pointed here because I'm having problems with my .so files, but this is actually the script I'm running myself. If I start everything up manually, things work fine. If I load the script through the fun_plug, it messes up.
Also, my path is /mnt/HD_a2/fun_plug.d/bin:/usr/bin:/bin:/usr/sbin:/sbin
Anyone got any current "cures" ?
Offline
Haven't you forgot the "env -i" when actually chrooting?
"env -i TERM=vt102 USER=root $BINDIR/chroot $CHROOT /linuxrc".
In chrooted, your PATH should be "/usr/bin:/bin:/usr/sbin:/sbin"
Last edited by dkl (2007-11-28 13:20:27)
Offline
No, that was actually in the script I originally used. But...I will try using just that line and not the rest of the script.
Offline
Ok, chrooting with that command without running the rest of the above script fixed it for me, so I'm pretty happy now. The only thing I cannot figure out now is the samba thing in my server...
Offline
Thanks
Offline