[lfs-support] su: Cannot drop the controlling terminal - 6.25 GCC
Good afternoon Pierre, Thank you for your response and suggestions. --QUOTE Hmmm, this is dubious. /dev/pts mounted on /dev/pts... what does "ls /dev/pts" say (as root, from host) If it returns /dev/pts/dev, then try "umount /dev/pts/dev/pts" then rm -r /dev/pts/dev Or reboot, login as root, set LFS (important!), mount the virtual filesystems again. Try findmnt at this point, chroot again, and try again to su in gcc. ---ENDQUOTE Please find below a copy and paste of the exact commands and response upon a fresh boot of my computer (before even opening anything else such as my browser): al-lfs:~$ sudo su - [sudo] password for al-lfs: root@debian-al:~# echo $LFS /mnt/lfs root@debian-al:~# mount -v --bind /dev $LFS/dev && mount -vt devpts devpts $LFS/dev/pts -o gid=5,mode=620 && mount -vt proc proc $LFS/proc && mount -vt sysfs sysfs $LFS/sys && mount -vt tmpfs tmpfs $LFS/run mount: /dev bound on /mnt/lfs/dev. mount: devpts mounted on /mnt/lfs/dev/pts. mount: proc mounted on /mnt/lfs/proc. mount: sysfs mounted on /mnt/lfs/sys. mount: tmpfs mounted on /mnt/lfs/run. root@debian-al:~# findmnt TARGETSOURCE FSTYPE OPTIONS / /dev/sdb9 ext4 rw,relatime,errors=remo ├─/syssysfs sysfs rw,nosuid,nodev,noexec, │ ├─/sys/kernel/security securityfs securit rw,nosuid,nodev,noexec, │ ├─/sys/fs/cgrouptmpfs tmpfs ro,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/unified cgroup2cgroup2 rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/systemd cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/net_cls,net_prio cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/devices cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/rdma cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/perf_event cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/cpuset cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/blkiocgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/freezer cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/pids cgroup cgroup rw,nosuid,nodev,noexec, │ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup cgroup rw,nosuid,nodev,noexec, │ │ └─/sys/fs/cgroup/memory cgroup cgroup rw,nosuid,nodev,noexec, │ ├─/sys/fs/pstorepstore pstore rw,nosuid,nodev,noexec, │ ├─/sys/firmware/efi/efivars efivarfs efivarf rw,nosuid,nodev,noexec, │ ├─/sys/fs/bpf bpfbpf rw,nosuid,nodev,noexec, │ ├─/sys/kernel/debug debugfsdebugfs rw,relatime │ └─/sys/fs/fuse/connections fusectlfusectl rw,relatime ├─/proc proc proc rw,nosuid,nodev,noexec, │ └─/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=33,pgrp= ├─/devudev devtmpf rw,nosuid,relatime,size │ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev │ ├─/dev/mqueue mqueue mqueue rw,relatime │ ├─/dev/hugepageshugetlbfs hugetlb rw,relatime,pagesize=2M │ └─/dev/pts devpts devpts rw,relatime,gid=5,mode= │ └─/dev/ptsdevpts devpts rw,nosuid,noexec,relati ├─/runtmpfs tmpfs rw,nosuid,noexec,relati │ ├─/run/lock tmpfs tmpfs rw,nosuid,nodev,noexec, │ └─/run/user/1000tmpfs tmpfs rw,nosuid,nodev,relatim │ └─/run/user/1000/gvfs gvfsd-fuse fuse.gv rw,nosuid,nodev,relatim ├─/mnt/lfs/dev/sdb10 ext4rw,relatime │ ├─/mnt/lfs/dev udev devtmpf rw,nosuid,relatime,size │ │ └─/mnt/lfs/dev/ptsdevpts devpts rw,relatime,gid=5,mode= │ ├─/mnt/lfs/proc proc procrw,relatime │ ├─/mnt/lfs/sys sysfs sysfs rw,relatime │ └─/mnt/lfs/run tmpfs tmpfs rw,relatime └─/boot/efi /dev/sdb1 vfat rw,relatime,fmask=0077, root@debian-al:~# if [ -h $LFS/dev/shm ]; then mkdir -pv $LFS/$(readlink $LFS/dev/shm); fi root@debian-al:~# chroot "$LFS" /tools/bin/env -i HOME=/root TERM="$TERM"PS1='(lfs chroot) \u:\w\$ ' PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin /tools/bin/bash --login +h (lfs chroot) root:/# su nobody -s /bin/bash -c "PATH=$PATH make -k check" su: Cannot drop the controlling terminal (lfs chroot) root:/# exit logout root@debian-al:~# ls -l /dev/pts total 0 crw--w 1 al-lfs tty 136, 0 Apr 18 16:25 0 c- 1 root root 5, 2 Apr 18 15:25 ptmx -QUOTE > The
Re: [lfs-support] libpthread is truncated
On Sat, Apr 18, 2020 at 12:54:55AM -0400, Bud Rozwood wrote:
> Hi,
>
> I just recently got a message from ldconfig saying that a file "is
> truncated" after installing a package in the chroot environment (after
> chapter 6 in version 9.1):
>
> # ldconfig
> ldconfig: file /lib/libpthread-2.31.so.dbg is truncated
>
> I've found a similar thread (systemd and a different version):
>
> https://www.mail-archive.com/lfs-dev@lists.linuxfromscratch.org/msg03985.html
>
> This happened to me before on a recent build and I thought I was doing
> everything right.
>
> However, I do recall that the '.dbg' file was created here
>
> http://linuxfromscratch.org/lfs/view/stable/chapter06/strippingagain.html
>
> I don't quite understand what the message from ldconfig means and if it
> needs fixing somehow.
Just a note that I had the same thing on my most recent build -
noticed it while trying to work out why some new cmake package was
not found by inkscape-rc (and in the end I gave up on that - I had
my fill of cmake a month ago on the packages used by blender). I
don't think ldconfig actually fails because of this.
Since I almost never have any use for the dbg files, I just renamed
it - ISTR that I had to prefix the filename rather than add
{,-hidden} because the latter was still reported. Something to look
at one day.
ĸen
--
He could send for Ptraci, his favourite handmaiden. She was special.
Her singing always cheered him up. Life seemed so much brighter when
she stopped. -- Pyramids
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom
On 4/18/20 6:30 AM, Stephen Berman wrote: On Sat, 18 Apr 2020 03:08:46 -0400 Michael Shell wrote: On Wed, 15 Apr 2020 10:41:27 +0200 Stephen Berman wrote: Another thing to try - does the problem persist if the CDROM is physically disconnected from the system (e.g., its SATA cable disconnected and then the system powered up)? If the system just hangs at some other point, then that is good evidence that something other than the CDROM driver/SCSI system is to blame. Thanks for the feedback. I see if I can try your suggestions and see what happens. Another suggestion would be to build a problematic kernel with CONFIG_CDROM=n to see if the issue is still present. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom
On Sat, 18 Apr 2020 03:08:46 -0400 Michael Shell wrote: > On Wed, 15 Apr 2020 10:41:27 +0200 > Stephen Berman wrote: > >> But if I run another program before shutdown (the two cases I've tried >> are startx and emacs in the tty), then shutdown does not power off >> the machine. > > > This is a most perplexing problem! > > I found this: > > https://forums.developer.nvidia.com/t/system-seems-locked-while-rebooting-with-linux-5-2-1-and-nvidia-drivers-430-34-or-430-26/78262 > > which may, or may not, be related to your problem. However, it does > demonstrate that video driver bugs (in the kernel) can cause > such a problem. Thanks for the pointer. This computer doesn't have an Nvidia card and I believe it doesn't use any Nvidia driver (though the kernel config does have CONFIG_NET_VENDOR_NVIDIA=y, probably a default I didn't change). What may be related, though, is that the post in that forum says the problem happens in kernel 5.2.1 but not in 5.1.16. I have now tested with kernels 5.3.0, 5.2.0 and 5.1.0 from the mainline repository and the computer does not power off (after normal use) with 5.3.0 or 5.2.0 but does with 5.1.0. So I can use the latter two as bad and good commits for git bisect. > Now, clearly there will be many other processes running on your > system even after a cold start. Even a bash prompt is a running > process. > > Emacs might not be as clean a "console"" test as you might think - it > might trigger the starting of some video related kernel functions even > when running outside of X. > > Try something like > > more text_file.txt > > so that you get a more prompt in that tty. Can you shutdown > with something as simple as more running? Do you mean run `more' in one tty and while it's running do `shutdown -h now' in another tty? > If *any* running command, which was started by you, triggers the > problem, then perhaps it could be some type of permissions/user > issue related to a kernel bug. Namely, if your username starts > a process (perhaps anything other than a shell), then the kernel > seems to be unable to kill that process, and most strangely, all > this seems to be linked to the CDROM. > > Another angle is that emacs (and Xorg) "look" at the CDROM > and that is what triggers it. If the more test allows for > a clean shutdown, than what about commands that try to > access the cdrom: > > dd count=10 bs=1k if=/dev/cdrom of=/dev/null > > Does running that result in shutdown failures (even after > the the dd command finishes/fails)? > > What if your emacs process is then killed *before* you try to > shutdown, can you shutdown then? If not, my guess is that any > process that ever "looks" at the cdrom triggers the problem. I always do `shutdown -h now' from a tty after quitting all programs I've started, including Emacs, Firefox and X. > Another thing to try - does the problem persist if the CDROM is > physically disconnected from the system (e.g., its SATA cable > disconnected and then the system powered up)? If the system > just hangs at some other point, then that is good evidence that > something other than the CDROM driver/SCSI system is to blame. Thanks for the feedback. I see if I can try your suggestions and see what happens. Steve Berman -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom
On Wed, 15 Apr 2020 10:41:27 +0200 Stephen Berman wrote: > But if I run another program before shutdown (the two cases I've tried > are startx and emacs in the tty), then shutdown does not power off > the machine. This is a most perplexing problem! I found this: https://forums.developer.nvidia.com/t/system-seems-locked-while-rebooting-with-linux-5-2-1-and-nvidia-drivers-430-34-or-430-26/78262 which may, or may not, be related to your problem. However, it does demonstrate that video driver bugs (in the kernel) can cause such a problem. Now, clearly there will be many other processes running on your system even after a cold start. Even a bash prompt is a running process. Emacs might not be as clean a "console"" test as you might think - it might trigger the starting of some video related kernel functions even when running outside of X. Try something like more text_file.txt so that you get a more prompt in that tty. Can you shutdown with something as simple as more running? If *any* running command, which was started by you, triggers the problem, then perhaps it could be some type of permissions/user issue related to a kernel bug. Namely, if your username starts a process (perhaps anything other than a shell), then the kernel seems to be unable to kill that process, and most strangely, all this seems to be linked to the CDROM. Another angle is that emacs (and Xorg) "look" at the CDROM and that is what triggers it. If the more test allows for a clean shutdown, than what about commands that try to access the cdrom: dd count=10 bs=1k if=/dev/cdrom of=/dev/null Does running that result in shutdown failures (even after the the dd command finishes/fails)? What if your emacs process is then killed *before* you try to shutdown, can you shutdown then? If not, my guess is that any process that ever "looks" at the cdrom triggers the problem. Another thing to try - does the problem persist if the CDROM is physically disconnected from the system (e.g., its SATA cable disconnected and then the system powered up)? If the system just hangs at some other point, then that is good evidence that something other than the CDROM driver/SCSI system is to blame. Cheers, Mike -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
