Re: GCC: Attempting to run tests as "tester" user results in "su: Cannot drop the controlling terminal"
| Newsgroups | gmane.linux.lfs.support |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 2025-01-11 at 15:12 +0000, kevadesu wrote: > Xi Ruoyao ([email protected] via lfs-support Mailing List) <[email protected]> wrote: > > On Sat, 2025-01-11 at 14:48 +0000, [email protected] wrote: > > > Xi Ruoyao ([email protected] via lfs-support Mailing List) <[email protected]> wrote: > > > > On Sat, 2025-01-11 at 10:55 +0000, [email protected] wrote: > > > > > > > > &gt; (lfs chroot) root:/# ls -l / > > > > &gt; ls -l /lib64 > > > > &gt; ls -l /lib/ld-linux-x86-64.so.2 > > > > &gt; ls -l /bin/bash > > > > &gt; total 84 > > > > &gt; lrwxrwxrwx 1 root root 7 Oct 23 19:46 bin -&gt; usr/bin > > > > &gt; drwxr-xr-x 2 root root 4096 Dec 21 19:28 boot > > > > &gt; drwxr-xr-x 21 root root 4720 Jan 11 11:15 dev > > > > &gt; drwxr-xr-x 6 root root 4096 Jan 8 20:28 etc > > > > &gt; drwxr-xr-x 3 root root 4096 Dec 21 21:13 home > > > > &gt; lrwxrwxrwx 1 root root 7 Oct 23 19:46 lib -&gt; usr/lib > > > > &gt; drwxr-xr-x 2 30034 root 4096 Nov 7 19:02 lib64 > > > > > > > > Hmm who is &quot;30034&quot;? Is that the UID for the lfs user on the host > > > > distro? But we have > > > > > > > > case $(uname -m) in > > > > x86_64) chown --from lfs -R root:root $LFS/lib64 ;; > > > > esac > > > > > > > > in section 7.2 which should have changed the owner to root, so this > > > > shouldn&#x27;t happen anyway. > > > > > > > > And what does &quot;ls -l /usr&quot; output in the chroot environment? > > > > > > > > -- > > > > Xi Ruoyao &lt;[email protected]&gt; > > > > School of Aerospace Science and Technology, Xidian University > > > > -- > > > > http://lists.linuxfromscratch.org/sympa/info/lfs-support > > > > Unsubscribe: See the above information page > > > > > > (lfs chroot) root:/# ls -l /usr > > > total 60 > > > drwxr-xr-x 2 root root 12288 Jan 8 20:26 bin > > > drwxr-xr-x 47 root root 12288 Jan 8 20:26 include > > > drwxr-xr-x 26 root root 12288 Jan 8 20:26 lib > > > drwxr-xr-x 6 root root 4096 Nov 10 17:22 libexec > > > drwxr-xr-x 8 root root 4096 Dec 21 19:28 local > > > drwxr-xr-x 2 root root 4096 Jan 8 20:26 sbin > > > drwxr-xr-x 20 root root 4096 Jan 3 18:55 share > > > drwxr-xr-x 2 root root 4096 Dec 21 19:28 src > > > drwxr-xr-x 4 root root 4096 Nov 10 16:31 x86_64-lfs-linux-gnu > > > (lfs chroot) root:/# > > > > Try "chmod -v 755 /" in chroot. > > > > Also you need to fix those directories owned by "30034" despite they > > seem not the cause of the su issue. They'll be a security hole when the > > LFS system is completed. > > > > -- > > Xi Ruoyao <[email protected]> > > School of Aerospace Science and Technology, Xidian University > > -- > > http://lists.linuxfromscratch.org/sympa/info/lfs-support > > Unsubscribe: See the above information page > > Holy shit, it worked! Thank you!! Well but still this shouldn't happen. I'm unsure if this is your human error or some insane configuration of the host distro. If this is a human error we cannot do anything, but if it's an insane configuration I've just pushed some changes to the book attempting to protect us from it. -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/sympa/info/lfs-support Unsubscribe: See the above information page