[Upstream regression / visibility] crun >= 1.29 can break host PTYs when starting a rootful Distrobox

Please, before opening a bug:

• I have read the documentation.
• I searched existing open issues.
• I searched existing closed/resolved issues.

Describe the bug

This report is a cross-reference for visibility only. The underlying regression is being tracked by crun:

https://github.com/containers/crun/issues/2197

Starting a rootful Distrobox container through Podman with crun 1.29 or newer can result in the container's anonymous /dev/pts volume appearing over the host's real /dev/pts mount.

Once this happens, /dev/pts/ptmx is no longer visible on the host and new pseudoterminals cannot be allocated. This affects sudo, terminal emulators and other applications that require PTYs.

The upstream report confirms:

• crun 1.28 works.
• crun 1.29 is affected.
• crun 1.29.1 is affected.
• current crun main is affected.

I reproduced this with Distrobox v1.8.2.5. I have not runtime-tested Distrobox v2 because reproducing the issue disrupts PTY allocation across the host and requires recovery.

To Reproduce

Warning: It can prevent new terminals and sudo sessions from working on the host.

1. Use Podman with crun 1.29 or 1.29.1.

2. Create a rootful, initful Distrobox:

   bash复制

   distrobox create \
     --root \
     --name crun-devpts-repro \
     --image docker.io/library/debian:stable \
     --init

3. Confirm the host initially has a normal devpts mount:

   bash复制

   findmnt -rn -o TARGET,SOURCE,FSTYPE /dev/pts

   Expected initial output:

   复制

   /dev/pts devpts devpts

4. Start or enter the rootful container:

   bash复制

   distrobox enter --root crun-devpts-repro

   Starting it directly through Podman can produce the same result:

   bash复制

   sudo podman start crun-devpts-repro

5. Inspect the host:

   bash复制

   findmnt -rn -o TARGET,SOURCE,FSTYPE /dev/pts
   stat -f -c '%T' /dev/pts
   ls -l /dev/pts/ptmx
   python3 -c 'import os,pty; a,b=pty.openpty(); print(os.ttyname(b))'

6. The anonymous Podman volume appears over the host /dev/pts. The filesystem reports btrfs rather than devpts, /dev/pts/ptmx is missing, and openpty() fails.

Expected behavior

The container's /dev/pts mount should remain isolated from the host mount namespace.

Logs

Distrobox/entry failure:

sudo: unable to allocate pty: No such device
Error: could not start entrypoint.
sudo: unable to allocate pty: No such device

Host mount state after starting the container:

/dev/pts devpts devpts
/dev/pts /dev/sdd1[/@containers/storage/volumes/<volume-id>/_data] btrfs

Host PTY checks:

$ stat -f -c '%T' /dev/pts
btrfs

$ ls -l /dev/pts/ptmx
ls: cannot access '/dev/pts/ptmx': No such file or directory

$ python3 -c 'import os,pty; a,b=pty.openpty(); print(os.ttyname(b))'
OSError: out of pty devices

The kernel was not actually out of PTYs:

$ paste -d/ /proc/sys/kernel/pty/nr /proc/sys/kernel/pty/max
4/4096

Desktop (please complete the following information):

• Container manager: Podman
• Podman version: 6.1.0-1
• OCI runtime: crun 1.29.1-1
• Distrobox version tested: 1.8.2.5-1
• Distrobox v2: source inspected, not runtime-tested
• Host distribution: Arch Linux
• Kernel: 6.18.44-1-lts
• Installation method: Arch Linux packages via pacman
• Container type: rootful and initful

Additional context

The affected container was created before the crun 1.29 update and did not previously cause this host-wide failure.

The upstream crun report contains version comparisons and tracks the underlying regression:

https://github.com/containers/crun/issues/2197

This Distrobox issue is intended only as a visibility and cross-reference item. No Distrobox-side change or workaround is being requested.

This report was created by AI and cross checked by me, apologize if there is any issue with the wording, thanks!