View previous topic :: View next topic |
Author |
Message |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Tue Jul 09, 2024 4:38 pm Post subject: Failed to open PTY: No Such Device |
|
|
After using chroot....
sudo mount /dev/sda2 /media/mount2
sudo mount --rbind /dev /media/mount2/dev
sudo mount --bind /proc /media/mount2/proc
sudo mount --bind /sys /media/mount2/sys ;
sudo mount --bind /run /media/mount2/run
sudo chroot /media/mount2
and after unmounting the target volume subsequent launching of terminal fails with the following message:
Failed to open PTY: No Such Device
Is there a way to program/bash script to test for PTY and regenerate/recreate PTY device; alternatively to manually recreate PTY from terminal, or is the only recourse to reboot? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
sublogic Apprentice
![Apprentice Apprentice](/images/ranks/rank_rect_2.gif)
![](images/avatars/92700334162390783722aa.png)
Joined: 21 Mar 2022 Posts: 259 Location: Pennsylvania, USA
|
Posted: Tue Jul 09, 2024 10:45 pm Post subject: |
|
|
So the problem occurs after you exit the chroot ?
What does mount | grep pts say ?
Is there a /dev/pts directory at this point ? Is there a /dev/pts/ptmx in it ?
If not, maybe (not tested) Code: | # mount -t devpts devpts /dev/pts |
|
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Wed Jul 10, 2024 4:31 pm Post subject: Failed to open PTY: No such device |
|
|
The issue occurs after the chroot volume target is unmounted, but not immediately upon cloing the terminal window.
Launching a terminal session:
There was an error creating the child process for this terminal
Failed to open PTY: No such device
There is a /dev/pts directory with no contents.
Can not run 'mount | grep pts' due to terminal error message when launching terminal.
Error message with blinking cursor.
Can not run 'mount -t devpts devpts /dev/pts' due to error message when launching terminal.
Blinking cursor, terminal window not responive to keyboard input. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
grknight Retired Dev
![Retired Dev Retired Dev](/images/ranks/rank-retired.gif)
Joined: 20 Feb 2015 Posts: 1819
|
Posted: Wed Jul 10, 2024 4:42 pm Post subject: |
|
|
contactopublico wrote: | The issue occurs after the chroot volume target is unmounted, but not immediately upon cloing the terminal window. | Please detail how this is accomplished on your end. This is the process causing issues. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
kimchi_sg Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
Joined: 26 Nov 2004 Posts: 3029
|
Posted: Wed Jul 10, 2024 4:46 pm Post subject: Re: Failed to open PTY: No Such Device |
|
|
contactopublico wrote: | After using chroot....
sudo mount /dev/sda2 /media/mount2
sudo mount --rbind /dev /media/mount2/dev
sudo mount --bind /proc /media/mount2/proc
sudo mount --bind /sys /media/mount2/sys ;
sudo mount --bind /run /media/mount2/run
sudo chroot /media/mount2 |
What is the context, during fresh system install? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Wed Jul 10, 2024 5:18 pm Post subject: |
|
|
The situation occurs with multiple chroot sessrions accessing target volumes.
Whan unmount a target choot volume, previously a message would appear in terminal window indicating 'out of PTY' (before using rbind).
Neverless when the chroot terminals are closed, and as long as I do not umount one of the target volumes the issue does not appear, and I can open and use additroinal terminal windows.
However, as soon as I unmount just one of the target volumes the terminal error appears and terminal no longer accepts nor executes keyboad commands, only a blinking cursor with an errror message as previously indicated.
I noticed on a fresh reboot that there were only three items in /dev/pts, characher devices and ptmx.
Is the solution to generate additional character devices for each terminal chroot session?
Thank yoiu for your replies. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22292
|
Posted: Wed Jul 10, 2024 5:52 pm Post subject: |
|
|
This sounds to me like you are somehow unmounting the host's /dev/pts when you try to unmount the chroot's /dev/pts. If so, then the solution is not to unmount the host's /dev/pts. Please show us exactly how you produce this scenario. Also show the output of findmnt -o+PROPAGATION immediately before you unmount the chroot's bind mounts. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Fri Jul 12, 2024 5:30 pm Post subject: |
|
|
Chroot is initiated from terminal, Chroot target volumes are mounted to designated mount poinrts.
Hu, Administrator from prior commenrt>>This sounds to me like you are somehow unmounting the host's /dev/pts when you try to unmount the chroot's /dev/pts. If so, then the solution is not to unmount the host's /dev/pts.
Exactly, the host /dev/pts is automatically unmounting when chroot /dev/pts volume is unmounted. Why is the host /dev/pts not retained?
Can the host /dev/pts be regenerated from terminal?
findmnt -o+PROPAGATION
TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/ /dev/sda3
│ ext2 rw,relatime shared
├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime shared
│ ├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegat shared
│ ├─/sys/firmware/efi/efivars
│ │ efivarfs
│ │ efivarfs rw,nosuid,nodev,noexec,relatime shared
│ ├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime shared
│ ├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime shared
│ └─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime shared
├─/proc proc proc rw,nosuid,nodev,noexec,relatime shared
│ └─/proc/sys/fs/binfmt_misc systemd-1
│ autofs rw,relatime,fd=33,pgrp=1,timeout=0,minpro shared
├─/dev udev devtmpfs rw,nosuid,relatime,size=6055360k,nr_inode shared
│ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620, shared
│ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev shared
│ ├─/dev/hugepages hugetlbfs
│ │ hugetlbfs rw,nosuid,nodev,relatime,pagesize=2M shared
│ └─/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime shared
├─/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1214 shared
│ ├─/run/credentials/systemd-journald.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/user/1000 tmpfs tmpfs rw,nosuid,nodev,relatime,size=1214100k,nr shared
│ ├─/run/credentials/systemd-tmpfiles-setup-dev-early.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-sysctl.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-udev-load-credentials.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-tmpfiles-setup-dev.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-tmpfiles-setup.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-resolved.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-networkd.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-vconsole-setup.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ └─/run/credentials/getty@tty1.service
│ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
├─/tmp tmpfs tmpfs rw,nosuid,nodev,size=6070516k,nr_inodes=1 shared
├─/media/mount4 /dev/sda4
│ │ ext2 rw,relatime shared
│ ├─/media/loop4/dev udev devtmpfs rw,nosuid,relatime,size=6055360k,nr_inode shared
│ │ ├─/media/loop4/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620, shared
│ │ ├─/media/loop4/dev/shm tmpfs tmpfs rw,nosuid,nodev shared
│ │ ├─/media/loop4/dev/hugepages
│ │ │ hugetlbfs
│ │ │ hugetlbfs rw,nosuid,nodev,relatime,pagesize=2M shared
│ │ └─/media/loop4/dev/mqueue
│ │ mqueue mqueue rw,nosuid,nodev,noexec,relatime shared
│ ├─/media/loop4/proc proc proc rw,nosuid,nodev,noexec,relatime shared
│ ├─/media/loop4/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime shared
│ └─/media/loop4/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1214 shared
├─/media/mount5 /dev/sda5
│ │ ext2 rw,relatime shared
│ ├─/media/loop5/dev udev devtmpfs rw,nosuid,relatime,size=6055360k,nr_inode shared
│ ├─/media/loop5/proc proc proc rw,nosuid,nodev,noexec,relatime shared
│ ├─/media/loop5/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime shared
│ └─/media/loop5/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1214 shared
└─/media/archive /dev/sda2
fuseblk rw,nosuid,nodev,relatime,user_id=0,group_ shared |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
pingtoo Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/gallery/Star Wars/movie_star_wars_storm_trooper.gif)
Joined: 10 Sep 2021 Posts: 1078 Location: Richmond Hill, Canada
|
Posted: Fri Jul 12, 2024 6:27 pm Post subject: |
|
|
contactopublico,
contactopublico wrote: | The issue occurs after the chroot volume target is unmounted, but not immediately upon cloing the terminal window. |
Actually this is common mistake when doing chroot, especially in scripted fashion
Did you after exist chroot, did umount /dev for example to match the mount /dev prior to chroot? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22292
|
Posted: Fri Jul 12, 2024 6:37 pm Post subject: |
|
|
contactopublico wrote: | Chroot is initiated from terminal, Chroot target volumes are mounted to designated mount poinrts. | None of those are commands we can use to reproduce your problem. I wrote above: "Please show us exactly how you produce this scenario." You described in general terms what you did to create the mounts. You have not shown how you end any of this. This makes it difficult for us to help you. I ask again: show us exactly how you produce this scenario. Per Guidelines item #4, you should show commands that we could run to get the same problem here.
contactopublico wrote: | Exactly, the host /dev/pts is automatically unmounting when chroot /dev/pts volume is unmounted. Why is the host /dev/pts not retained? | It would be easier to answer that if we knew the commands you were running. However, from the findmnt output you provided, I can make a guess. Something - probably systemd, since it is known to cause this problem - has made many of your mounts shared (overriding the kernel default of private), in the shared subtree sense. This causes mounts to propagate forward and backward. As described in Documentation/filesystems/sharedsubtree.rst, mounts in one bind are propagated to the other, as are unmounts, so unmounting in the chroot also unmounts outside it. contactopublico wrote: | Can the host /dev/pts be regenerated from terminal? | Yes. Mount devpts on it again. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Sun Jul 14, 2024 6:18 pm Post subject: chroot loss of PTY |
|
|
Hu, Administrator wrote:
"Please show us exactly how you produce this scenario."
In response to detailing exactly how chroot is invoked, you would not be able to exactly reproduce the sequence on your system unless you designate the same mount points, and utilized a volume at sda4 into which a chroot could be executed.
Chroot for a selected volume is invoked via alias from terminal within the host environment, executing a bash script to effect the designaged commands, using designated mount points.
Such a script would typically contain these types of commands:
sudo mount /dev/sda4 /media/mount4 ;
sudo mount --rbind /dev /media/mount4/dev ;
sudo mount --bind /proc /media/mount4/proc ;
sudo mount --bind /sys /media/mount4/sys ;
sudo mount --bind /run /media/mount4/run
sudo chroot /media/mount4
You would be able to replicate those commans line by line at the command prompt, the same as done by bash script, if you created the mount point and had a volume to chroot into at sda4.
After complettion of the desired tasks in chroot the terminal window is closed and the volume unmounted in file manager.
Until a chrooted volume is unmounted the host system /dev/pts remains, but once a chroot volume is unmounted the host /dev/pts terminates and it is no longer possible to utilize terminal, unless rebooted, as previously explained.
/dev/pts can not be regenerated from a non-runctioning terminal.
What I am seeking, is a method of unmounting a chroot volume and preserving the host /dev/pts/ and PTY for the host terminal.
It is not enough to suggest to not umount chroot volumes as the chroot session should not continue indefinately, nor would it be acceptable to reboot a server after every chroot session.
Therefore, in light of your previous post:
Something - probably systemd, since it is known to cause this problem - has made many of your mounts shared (overriding the kernel default of private), in the shared subtree sense. This causes mounts to propagate forward and backward. As described in Documentation/filesystems/sharedsubtree.rst, mounts in one bind are propagated to the other, as are unmounts, so unmounting in the chroot also unmounts outside it.
Consequently, is this a systemd bug that should to be reported to the maintainer? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Sun Jul 14, 2024 6:29 pm Post subject: |
|
|
Pingtoo wrote:
Actually this is common mistake when doing chroot, especially in scripted fashion
Did you after exist chroot, did umount /dev for example to match the mount /dev prior to chroot?
I am not certain what specific steps you refer to in your post.
If you are referencing a specific sequence of steps to unmount the chroot volume (including /dev) that will preserve the host /dev/pts and PTY for the host system terminal, please specify exactly what syntax and order of commands to utilize from the host terminal.
Thank you. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
pingtoo Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/gallery/Star Wars/movie_star_wars_storm_trooper.gif)
Joined: 10 Sep 2021 Posts: 1078 Location: Richmond Hill, Canada
|
Posted: Sun Jul 14, 2024 7:25 pm Post subject: |
|
|
contactopublico,
I am refer to after you exist chroot, did you execute some umount commands? and could one of them be umount /dev?
I recently just finish a chroot script, did the umount, but not realize I was outside of chroot, so the execution unmounted the outer stuff. luck me I was doing inside a container, so no harms done. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Mon Jul 15, 2024 4:08 pm Post subject: Pty |
|
|
Pingtoo wrote:
I am refer to after you exist chroot, did you execute some umount commands? and could one of them be umount /dev?
Once done with chroot operations, I typically close the terminal window, and this does not unmount host /dev/pts.
Once the chroot volume is umounted via clicking in file manager, /dev/pts is umounted on the host system.
I am not using a command line to unmount chroot volumes because after the first umount PTY is lost and terminal no longer functions.
Is this a systemd bug that should be reported to the maintainer? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
grknight Retired Dev
![Retired Dev Retired Dev](/images/ranks/rank-retired.gif)
Joined: 20 Feb 2015 Posts: 1819
|
Posted: Mon Jul 15, 2024 4:24 pm Post subject: |
|
|
contactopublico wrote: | Is this a systemd bug that should be reported to the maintainer? |
Particularly with systemd, it is critical to mark all --bind mounts with an additional mount --make-slave <target> and all --rbind mounts as mount --make-rslave <target> when creating a chroot such that the sources of the targets are not unmounted when the target is. This is evidenced by the "shared" mount in the earlier output.
The mount man page suggests it may be possible to do mount --bind --make-slave <source> <target> or mount --rbind --make-rslave <source> <target> as well but I am unable to test this.
Edit: This isn't limited to systemd as any mount can manually be set into a mount namespace by an admin or script. systemd seems to opt into this automatically and OpenRC does not by default (at least for /dev, /proc, and /sys). See man mount_namespaces for the boring details. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Mon Jul 15, 2024 5:34 pm Post subject: Pty |
|
|
Thank you grnight for your reply.
Planning to test the "--make-slave" parameter to verify if this resolves the issue. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
pingtoo Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/gallery/Star Wars/movie_star_wars_storm_trooper.gif)
Joined: 10 Sep 2021 Posts: 1078 Location: Richmond Hill, Canada
|
Posted: Mon Jul 15, 2024 6:00 pm Post subject: Re: Pty |
|
|
contactopublico wrote: | Pingtoo wrote:
I am refer to after you exist chroot, did you execute some umount commands? and could one of them be umount /dev?
Once done with chroot operations, I typically close the terminal window, and this does not unmount host /dev/pts.
Once the chroot volume is umounted via clicking in file manager, /dev/pts is umounted on the host system.
I am not using a command line to unmount chroot volumes because after the first umount PTY is lost and terminal no longer functions.
Is this a systemd bug that should be reported to the maintainer? |
I was thinking the chroot act usually were manual operation, one do manually mount necessary support pseudo file systems and when exiting chroot, another manual operations that will undo all the prior manual mount operation.
I guess in your case you were depend on systemd (or gui tool) that do the unmount operations.
So the unmount operation did by the systemd (or gui tool) were "recursive", as in it will travail down the directory tree from the topper layer (for your case it is the /dev/sda4 or /dev/sda2) find each mountpoint and perform umount on the mountpoint. and in the case of /dev it got an umount command and since it is "shared" between its outer layer (out side chroot) and the inner layer (inside chroot) therefor the umount got past up both layer therefor inside and outside got unmount together.
So it is not a "bug". It is by design.
And the solution is like other suggested, use make-slave to isolate the changes into only the inside mount. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22292
|
Posted: Mon Jul 15, 2024 6:21 pm Post subject: Re: chroot loss of PTY |
|
|
contactopublico wrote: | "Please show us exactly how you produce this scenario." | I suggest using the forum's quote tags, rather than copying other poster's text and wrapping it in double quotes. contactopublico wrote: | In response to detailing exactly how chroot is invoked, you would not be able to exactly reproduce the sequence on your system unless you designate the same mount points, and utilized a volume at sda4 into which a chroot could be executed. | Yes, I know. I can deal with minor adjustments there. However: contactopublico wrote: | After complettion of the desired tasks in chroot the terminal window is closed and the volume unmounted in file manager. | What file manager? How is it unmounted in the file manager? If not otherwise specified by the poster, I assume an unmount is done using the umount command line tool. It sounds like that is not what you are doing. contactopublico wrote: | /dev/pts can not be regenerated from a non-runctioning terminal. | Why not? What happens when you try? I just tried it here, and it seems to work fine. I can start a new shell without a functioning /dev/pts. I can mount a replacement devpts on it. contactopublico wrote: | Consequently, is this a systemd bug that should to be reported to the maintainer? | I happen to disagree with systemd default-enabling subtree sharing when the kernel default is default-private, but it is a known behavior of systemd, and I doubt you will get anyone to change that default now. The default of enabling it has been in place for years.
grknight explained this in greater detail. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
contactopublico n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 22 Dec 2023 Posts: 31
|
Posted: Tue Jul 16, 2024 4:30 pm Post subject: Pty |
|
|
For the benefit of any future readers inquiring regarding this issue, and In order to address any remaining questions that have not previously been answered with sufficient granularity:
After closing the chroot terminal, unmouning of the chroot volume is done via caja file manager by simply clicking the umount icon visible next to the chroot volume in the left pane of he file manager.
Previously, after the chroot unmount any newly launched mate-terminal session would display a red message band in the mate-terminal window indicating...
Code: | Failed to open PTY: No Such Device |
...and displaying a blinking cursor, and would not accept input via keyboard.
It now appears after testing that the
parameter prevents the recursive unmounting of /dev/pts in the host system after chroot volumes are unmounted, resulting in terminal functionality being retained in the host system.
Thank you to all who have replied with assistance in resolving this issue. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
grknight Retired Dev
![Retired Dev Retired Dev](/images/ranks/rank-retired.gif)
Joined: 20 Feb 2015 Posts: 1819
|
Posted: Tue Jul 16, 2024 6:16 pm Post subject: |
|
|
Hu wrote: | I happen to disagree with systemd default-enabling subtree sharing when the kernel default is default-private, but it is a known behavior of systemd, and I doubt you will get anyone to change that default now. The default of enabling it has been in place for years. |
FWIW, Debian had a bug on this in 2014 and the systemd developers have already defended their stance with the primary reason being to promote containers. I agree that it is unlikely to ever change. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|