4

Added:

After reading suggested as duplicate Which of proc, sys etc. should be bind-mounted (or not) when chrooting into a "replacement" distribution? :

How I know:

  • it is customary to invoke mounts of sysfs, proc, dev, dev/pts before chroot,
  • I guess using bind in mount -o bind /dev dev/ one gives assess to same devices as the system has from where chroot is run.

However it does not explain why I got the error is a setup that from what I see does not differ in relevant parts to setup where the error was not in output. Please somebody help to learn more how Linux works under the hood. TIA

Original:

I've been doing scripting using chroot for Linux Mint 20.2. On 20.2 I've been chrooting into mounted ISO distro of 20.2, sudo worked as expected.

Recently I've tried to chroot from 20.2 to ISO distro 21 and when running sudo mount -t proc proc /proc after chroot got

sudo: unable to allocate pty: No such device

I've compared contents of /dev and /dev/pts when chrooted in 20.2 and 21 with ls -a, contents matched, also /dev/pts was empty.

I understand when chrooted command runs as root as user is root, however I do scripting partly to learn Linux under the hood and want to understand the reason for the error. Web search got links to similar error when connecting to servers, I could not see there info explaining behavior of my setup.

uname -a outputs same "5.4.0-74-generic" for both 20.2 and 21; replacing sudo with sudo --stdin still resulted in "sudo: unable to allocate pty: No such device", I recall there was a time when adding --stdin got rid of some error (don't recall exactly what the error was), I've read related What's the purpose of using `sudo -S` explicitly?

sudo stops to output "sudo: unable to allocate pty: No such device" after mount -t devpts devpts /dev/pts, however output becomes

*** closefrom failed to close a file descriptor ***: terminated Aborted

After also running mount -t proc proc /proc sudo works as expected, but mount /proc w/out /dev/pts still results in previous "unable to allocate pty", so I'm puzzled (as stated above contents of /dev/pts match and empty in both working and non-working cases).

What else can I check and try? TIA

Improve this question
7
  • 1
    Does this answer your question? Which of proc, sys etc. should be bind-mounted (or not) when chrooting into a "replacement" distribution? Commented Dec 9, 2022 at 3:06
  • @muru, thanks, it is relevant, I learned couple of things from it and updated the question. However it does not explain under-the hood much and I still want to understand why in one case sudo worked and not the other (both cases started with no mentioned in the answer mounts). Commented Dec 9, 2022 at 3:48
  • 1
    Can you reproduce that sudo worked in a chroot without these mounts at all? I don't think it has ever worked that way for me. Commented Dec 9, 2022 at 3:57
  • @muru, clear reperformance: booted from Linux Mint 20.2. Cinnamon 64 bit downloaded ISO (via Ventoy replacing quiet splash with toram with legacy boot to be exact, then (optional? - later noted it was mounted after boot already) re-plugged USB to get access to ISO file from system, double-click on ISO file, mounted to say path1. Start terminal Ctrl-Alt-t. 2) mkdir ~/lm ; mount $path1/casper/filesystem.squashfs ~/lm 3) chroot ~/lm /bin/bash 4) sudo echo a output "a" Please let me know if this reperformance is acceptable to you. Commented Dec 9, 2022 at 5:28
  • 1
    What's the output of sudo -l in the chroot where sudo echo a worked? Commented Dec 9, 2022 at 6:38

1 Answer 1

Reset to default
-1

I resolved the sudo:

unable to allocate pty: No such device

By getting a root session before running chroot so:

sudo su -

then

chroot /mnt
Improve this answer
3
  • 1
    This isn't really answering the question of why exactly the OP is getting the error. They have already figured out how to resolve it. Also, sudo su - is not the way to get a root shell. Either run su - alone if your system has a root password or run sudo -i if it doesn't. But sudo su is pointless. Commented Dec 21, 2022 at 11:22
  • @terdon The OP's question is "What else can I check and try? TIA" not "why exactly the OP is getting the error". sudo su - gives you a "super user" session and invokes the "super user" profile, as opposed to a sudo su which carries over your user profile into the "super user" session - so not pointless at all. Commented Jan 19, 2023 at 21:25
  • Yes, that's exactly what sudo -i does. See Is there ever a good reason to run sudo su?. I mean, it's not wrong or anything, it's just inelegant and strange to use two commands when one would do. And the question is "why does this happen" (see the top section, the "Added"). Commented Jan 20, 2023 at 9:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.