[lfs-support] More Control and Package Management using Package Users - LFS 7.2+

David Buchan davidsbuchan at gmail.com
Wed Oct 10 00:41:50 PDT 2012


Hi,

Sorry if this is the second time I have sent this (not sure if I sent it
right the first time).

I am building the current development lfs and am having the following
problem.
At the start of Chapter 6, once inside the chroot environment I am using
the hint "More Control and Package Management using Package Users".
Packages are installed as a unique user that is created specifically for
each package.
Since the first package is linux-libc-headers, the hint tells you to create
a user and group called linux-libc-headers.
The hint provides handy scripts to do the job of creating these new users
and groups.
One of these scripts tries to execute su - linux-libc-headers
But since su no longer exists in the /tools environment it fails.
su used to be in coreutils (therefore when compiling coreutils in chapter 5
you could (as part of the hint) copy su into /tools).
But now su is only in shadow which is not installed in chapter 5.

I have tried installing shadow in /tools as an extra to chapter 5, but
after executing su I get an exit status of 1 which means "permission
denied" according to "exitcodes.h" within shadow's source.

I have installed strace (again in /tools) and executed su -
linux-libc-headers and get the following output:

strace output:
---------------------------------------
execve("/tools/bin/su", ["su", "-", "linux-libc-headers"], [/* 8 vars */])
= 0
brk(0)                                  = 0xa7d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f7d5083a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
directory)
open("/tools/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("/tools/lib/tls/x86_64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
stat("/tools/lib/tls/x86_64", 0x7fff774afca0) = -1 ENOENT (No such file or
directory)
open("/tools/lib/tls/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
stat("/tools/lib/tls", 0x7fff774afca0)  = -1 ENOENT (No such file or
directory)
open("/tools/lib/x86_64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
stat("/tools/lib/x86_64", 0x7fff774afca0) = -1 ENOENT (No such file or
directory)
open("/tools/lib/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\f\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=40840, ...}) = 0
mmap(NULL, 2318880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f7d503e4000
mprotect(0x7f7d503ec000, 2093056, PROT_NONE) = 0
mmap(0x7f7d505eb000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f7d505eb000
mmap(0x7f7d505ed000, 184864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7d505ed000
close(3)                                = 0
open("/tools/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200)\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=97169, ...}) = 0
mmap(NULL, 2182456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f7d501cf000
mprotect(0x7f7d501e4000, 2093056, PROT_NONE) = 0
mmap(0x7f7d503e3000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f7d503e3000
close(3)                                = 0
open("/tools/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\30\2\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1966853, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f7d50839000
mmap(NULL, 3820672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f7d4fe2a000
mprotect(0x7f7d4ffc6000, 2093056, PROT_NONE) = 0
mmap(0x7f7d501c5000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19b000) = 0x7f7d501c5000
mmap(0x7f7d501cb000, 15488, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7d501cb000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f7d50838000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f7d50837000
arch_prctl(ARCH_SET_FS, 0x7f7d50838700) = 0
mprotect(0x7f7d501c5000, 16384, PROT_READ) = 0
mprotect(0x7f7d505eb000, 4096, PROT_READ) = 0
mprotect(0x7f7d5083b000, 4096, PROT_READ) = 0
brk(0)                                  = 0xa7d000
brk(0xa9e000)                           = 0xa9e000
getuid()                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
fstat(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
stat("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
open("/etc/login.defs", O_RDONLY)       = -1 ENOENT (No such file or
directory)
open("/tools/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_FILE, sun_path="/dev/log"}, 110) = 0
sendto(3, "<10>Oct  8 19:31:11 su: cannot o"..., 97, MSG_NOSIGNAL, NULL, 0)
= 97
exit_group(1)                           = ?
+++ exited with 1 +++
-----------------------------------
strace output finished.

Can anyone read that mess? Is the problem 3 lines above the bottom +++:
connect(3, {sa_family=AF_FILE, sun_path="/dev/log"}, 110) = 0

I have also tried running strace su - in my host environment, but it fails
authentication (different error, but still doesn't work) so this may be a
duff test.

The only solutions I can think of is to chroot in and out of LFS for each
user/package up until shadow, after which the hint should work as normal.
Or as someone suggested on IRC #lfs-support yesterday, I could install
everything up to and including shadow in chapter 6 as root. Then start
chapter 6 again using the hint. That would take much much longer as each
installation would fail for every file it tried to install, because each
package/user would try to overwrite each root owned file, failing each
time, and I'd have to manually correct these one at a time.
Or I could run through LFS 6.x where su is still inside coreutils.

I have installed LFS using this hint in the past so I know it works, not
sure what versions though.

Any thoughts would be greatly appreciated.

----- additions as of 10/10/2012 -----
This morning I added printf lines to the main method in su.c and recompiled
it into /tools
Now when I execute su, I'm getting "No such file or directory". The file
/tools/bin/su exists and it's my new version with the printf's in it. I'm
not getting any of the printfs though. :( This could be a completely
separate problem. So I'm not too fussed about this. I'd like to get su
working in /tools somehow.

Cheers

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20121010/7246588f/attachment.html>


More information about the lfs-support mailing list