[lfs-support] Getting <su> in Chapter 5 [SOLVED][RESURRECTED]

Dan McGhee beesnees at grm.net
Mon Oct 14 07:52:04 PDT 2013

On 10/13/2013 11:02 PM, Bruce Dubbs wrote:
> Drew Ames wrote:
>> On 10/13/2013 06:48 PM, Dan McGhee wrote:
>>> I got to chroot and the copied su from shadow in Ch 5 didn't work. I
>>> can find no reason that it didn't. What I want to do now is compile it
>>> in chroot environment and install only it there. Just in case I missed
>>> some kind of linking. That seems unlikely, but.... ldd /tools/bin/su
>>> (on the copied version) provided:
>>>> linux-vdso.so.1 (0x00007ffff9b38000)
>>>> libcrypt.so.1 => /tools/lib/libcrypt.so.1 (0x00007f20fb668000)
>>>> libc.so.6 => /tools/lib/libc.so.6 (0x00007f20fb2b8000)
>>>> /tools/lib64/ld-linux-x86-64.so.2 (0x00007f20fb8a0000)
>>> as did ldd on my DESTDIR install, so it looks like everything is there.
<did some snipping>
>> Dan, Bruce, and Ken,
>> I've been following this thread with interest. I'm into my fourth LFS
>> build, using LFS 7.4.
>> For my previous three builds, I successfully use the package user hint
>> without any problems. Now I'm facing the same issues as Dan.
>> <more snipping>
>> I tried building su from an old source at this link, starting at line 802:
>> http://wiki.linuxfromscratch.org/hints/browser/trunk/PREVIOUS_FORMAT/more_control_and_pkg_man.txt?rev=904
>> I built it with GCC at the end of chapter 5 (I typed 'gcc -o su su.c'),
>> then copied it to /tools/bin.
>> When I got to chapter 6, as the root user in the chroot environment,
>> that copy of su would not switch users to the linux-libc-headers user I
>> created for the first package. I got the error:
>> bash: /tools/bin/su: No such file or directory
>> I then copied su from the host system and got the same results.
>> Dan, when you say that su didn't work for you. Did you get an error message?
> I don't know, but I wonder if the problem is the lack of passwd, group,
> shadow, etc files.  You need to track the source to find out.  Just add
> printf statements at strategic places.
Bruce, I think your on to something. Thank goodness for this list. Many 
times I can get into a "thinking rut" when I'm troubleshooting. Fresh 
minds really help.

I'm thinking that the previous version of su supplied with coreutils was 
a "stand alone" binary. The versions supplied now by shadow and 
util-linux depend on "auxiliary stuff" as you mentioned; i.e., we don't 
install su from util-linux because it depends on pam, which we don't 
use. Shadow, I think, integrally supplies the monitoring that pam does. 
When I examined shadow's "configure --help" this AM, I found this:

> --enable-shadowgrp enable shadow group support [default=yes]
> ...
> --enable-account-tools-setuid
> Install the user and group management tools setuid
> and authenticate the callers. This requires
> --with-pam.
Additionally, shadow tracks the number of logins, failed logins and all 
that other stuff. But I don't know how few of these additional files are 
needed to run it.

If someone were familiar with printf, Bruce, I think you're right. :) 
I've been trying to learn about it this morning and know that I can 
change decimal numbers to octal or hex or any combination of that. I 
found that I can make pretty tables and center text, but I could find no 
examples of how to use it in the way you described. What kind of 
"strategic places" were you thinking and in what context?

Until I understand more than what I do now about printf, I need to use 
brute force. :) My first thought is to try to use shadow's su from my 
DESTIR install without configuring shadow. If this works, I could then 
start removing stuff from DESTDIR/bin until su fails. Absent success 
there, I could do the same thing in chroot environment. I don't like to 
"erase the slate" but I could always "nuke" my build thus far, bring in 
my backed up /tools, and do the shadow stuff as lfs.

For the "package users" who are monitoring this thread, Rob Taylor 
installed and configured shadow at the beginng Ch. 6. He then overwrote 
it in its regular sequence. There were a few "hiccups" as he noted in 
his build notes, but package users know how to get past those. :) Here's 
a link to his notes:


I'm always interested in learning more about this stuff. I would 
appreciate it, Bruce, if you could share some of your ideas about the 
printf strategy, if you can spare the time.


More information about the lfs-support mailing list