Are you doing any weird mount tricks?
None that i know of. I boot from SD-card. I disabled udev-mounting of cards by adding /dev/mmcblk0 and /dev/mmcblk1 to /etc/udev/mount.blacklist .
This is my fstab: ------------------------------------------------------------- rootfs / auto defaults,async,noatime 1 1 proc /proc proc defaults 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 usbfs /proc/bus/usb usbfs defaults 0 0 tmpfs /var/volatile tmpfs defaults 0 0 tmpfs /dev/shm tmpfs mode=0777 0 0 tmpfs /media/ram tmpfs defaults 0 0
# The /boot kernel volume on the OpenPandora NAND. #ubi1:boot /boot ubifs defaults 0 0
#swap-memory /dev/mmcblk0p2 none swap sw -------------------------------------------------------------
This is my "mount"-output: ------------------------------------------------------------- # mount rootfs on / type rootfs (rw) /dev/root on / type ext2 (rw,noatime,errors=continue) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) none on /dev type tmpfs (rw,mode=755) devpts on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) tmpfs on /var/volatile type tmpfs (rw) tmpfs on /dev/shm type tmpfs (rw,mode=777) tmpfs on /media/ram type tmpfs (rw) -------------------------------------------------------------
ie: The path to find it (unless chanign g a lot) would find the same one each time;
I thought of that too. Espcially since i set up a path-definition in a .bashrc and a .bash_profile. But i checked them and both are equal. ALso: I did no precise tests but didn't find a real pattern about when this occurs. Yesterday when loggin in from ssh using dropbear on the pandora it hang with the /usr/bin/su-version multiple times, but worked with /bin/su. I just tested the same thing again, first it worked. But at a certain constellation it does not. I connected twice via ssh, after that ran xterm in xfce from the pandora and did "su" there to switch to root (I did set a password for root). When i then tried to do a "/usr/bin/su lomaxx" in a ssh-shell on my Gentoo-pc, the su-process hang. I tried this again to verfiy it, closed all connections and xterms, opened them as in the first time, but then failed to trigger the issue again. =( This is very weird. So now -regarding "su" - i am not sure if the problem is the busybox-version. But so far i didn't notice any hangs when using /bin/su after defining the alias. Might be luck though. I will have to investigate more into this, if i want to find the source of the problem.
In any way i want to point out the following:
I mean, you could copy /bin/ls into 37 directories, and aside from looking like a virus attack, it should be harmless?
The point is: busybox-versions and the seperate installed versions are not the same and behave different. Sometimes options are missing in the one version which exist in the other (although i haven't got a good example for a missing option right now).
Examples executed as root: ------------------------------------------------------------ /sbin/blkid #doesn't output anything ------------------------------------------------------------ /usr/sbin/blkid /dev/mmcblk0p1: LABEL="root" UUID="32c3f5c1-658e-4524-9be9-90a2a0417bbe" TYPE="ext2" /dev/mmcblk0p2: LABEL="swap" UUID="f8aaee7f-af8b-4f5f-baad-01369b0cf2f8" TYPE="swap" ------------------------------------------------------------
or
------------------------------------------------------------ /bin/su --help Tinylogin v1.4 (2010.06.27-16:08+0000) multi-call binary
Usage: su [OPTION]... [-] [username] ------------------------------------------------------------ /usr/bin/su --help Usage: su [options] [LOGIN]
Options: -c, --command COMMAND pass COMMAND to the invoked shell -h, --help display this help message and exit -, -l, --login make the shell a login shell -m, -p, --preserve-environment do not reset environment variables, and keep the same shell -s, --shell SHELL use SHELL instead of the default in passwd ------------------------------------------------------------
On 08.07.2011 15:54, skeezix wrote:
If everyone would put barbecue sauce on their food, there would be no war.
Speaking of it: I have to leave for barbecue. ;) Lomaxx