On 09/04/2012 01:57 PM, John Burrell wrote: > > >My guess is simply grabbing from the host as Bruce suggested is the > easiest option. > >Firerat > > I intuitively don't like that solution because if someone grabs my > script to play around with it, they will likely have a different host > and su could be in a different location from my host. > > I tried compiling shadow at the end of chapter 5 and using that su - > but it doesn't work. It doesn't appear to execute the bashrc file in > the package user directory. I went back to try coreutils-8.17 and that > version of su works okay. I don't understand why at the moment. > > What is likely to be the difference between the coreutils-8.17 version > and the shadow version of su, that I compiled, to make it behave this way? > > jb. I'm building LFS 7.1 right now (my third LFS build), so at first I was confused about the problem, but as a devoted package user user :-) I'm very interested in the solution.
Quick recap to see if I'm on the right page: (1) coreutils used to have su, but as of version 8.18, it doesn't, (2) LFS 7.2 uses the new coreutils; and (3) shadow does have su, but shadow isn't built in chapter 5. Regarding why the shadow su and coreutils su would behave differently, I can only guess that the shadow su is expecting /etc/passwd, /etc/shadow, and /etc/login.defs to be available too. It seems that the simplest solution would be to build coreutils-8.15 or some other version prior to 8.18. Run configure and make, then copy the uninstalled version to /tools/bin/su: 'cp src/su /tools/bin' Until somebody can figure out why the shadow su is behaving differently, the above option seems to be a good one. Thoughts? -Drew Ames -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
