3

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

Alex Martian
  • 1,035
  • 1
    Does this answer your question? Which of proc, sys etc. should be bind-mounted (or not) when chrooting into a "replacement" distribution? – muru Dec 09 '22 at 03: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). – Alex Martian Dec 09 '22 at 03: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. – muru Dec 09 '22 at 03: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. – Alex Martian Dec 09 '22 at 05:28
  • same actions done with LM 21 ISO resulted in "sudo: unable to allocate pty: No such device" – Alex Martian Dec 09 '22 at 05:36
  • 1
    What's the output of sudo -l in the chroot where sudo echo a worked? – muru Dec 09 '22 at 06:38
  • @muru, seems you have good idea where to look, on LM21 "use_pty, pwfeedback", on where worked (20.2) only "pwfeedback". However I've tried sudo --stdin and IIRC got same result as just sudo. Why? – Alex Martian Dec 09 '22 at 11:40

1 Answers1

-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
user2480415
  • 11
  • 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. – terdon Dec 21 '22 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. – user2480415 Jan 19 '23 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"). – terdon Jan 20 '23 at 09:32