When an user logs in in Dropbear, dropbear complains about not able to chown a /dev/pts entry. (Otherwise it would start to cry over openpty). exit after auth (root): chown(/dev/pts/0, 0, 5) failed: Function not implemented An user can not login now. Another quite annoying problem with the new busybox is the 'look-i'm-root-but-you-are-not' functionality. If only the thing would switch to a real non-user, dbclient/dbscp would work. Now they complain about the user not being present and not respecting the HOME env variable, and break.
you didnt give any information about your system /dev/pts should be mounted as devpts and with a /dev/ptmx node, there's no reason for dropbear to try and change anything in /dev/pts
I know for sure /dev/pts is mounted, if it isn't dropbear reports the openpty() issues. I can't verify if /dev/ptmx exists, but since it is in my makedev I expect it to be there too. > there's no reason for dropbear to try and change anything in /dev/pts Why not? The pty's won't get ownership out of the blue. While trying to reproduce it, the most likely thing could be a missing /etc/group, though it never reports the same chown error on the host system. The reason I can't give any 'information' about the system would be because it is a binary merge of the needed packages { grub, busybox, uclibc, dropbear } in a new environment based on what emerge produced. And since the issue doesn't exists in current form on the host system, I wonder where the 'Function not implemented' comes from. Since the url described the issue of the chown not being present in 2001 I wonder why this issue is back in 2006.
> > there's no reason for dropbear to try and change anything in /dev/pts > > Why not? The pty's won't get ownership out of the blue. i'm pretty sure devpts takes care of that, but i have nothing to back up such a claim > The reason I can't give any 'information' about the system would be because it > exists in current form on the host system, I wonder where the 'Function not > implemented' comes from. Since the url described the issue of the chown not > being present in 2001 I wonder why this issue is back in 2006. sounds like mismatch between host build kernel headers and the target kernel version
(In reply to comment #3) > sounds like mismatch between host build kernel headers and the target kernel > version Linux 2.6.15 on host and Linux 2.6.16_rc1 on target seems to be incompatible, thanks for the answer.