«Сервер отказался выделить pty» - как смонтировать устройства автоматически?
Я использовал этот ящик ubuntu 16.04, размещенный в vSphere, каждый рабочий день в течение последних полугода. Подключаюсь к нему из винды с помощью putty / kitty. Сегодня меня встретило сообщение, подобное тому, что было в этот вопрос .
Я не уверен, чем это было вызвано. Вот сообщение:
Authenticating with public key "imported-openssh-key"
Server refused to allocate pty
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
0 packages can be updated.
0 updates are security updates.
Я сохранил форматирование в том виде, в каком оно было распечатано.
Этот ответ решает проблему, но затем мне нужно вводить команду при каждой перезагрузке:
mount devpts /dev/pts -t devpts
Добавление строки fstab как показанная по ссылке , также приведенная в одном из исходных ответов на вопрос, похоже, ничего не меняет.
Честно говоря, я понятия не имею, почему мне не нужно было монтировать это устройство до сих пор, а затем оно внезапно перестало работать, и мне понадобилось это крепление.
Каков правильный способ исправить эту проблему для меня, чтобы Мне не нужно монтировать это вручную после каждой перезагрузки? С удовольствием предоставлю журналы или другую диагностику, которую вы можете запросить.
Обновление
Итак, сначала я решил проблему, перестроив коробку, но теперь это случилось снова, и это начало происходить и с другими машинами, которыми я управляю.
Чтобы следовать ответ Филипе .
Запуск gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts дает
mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true
Running gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts / init-bottom / udev | grep move дает
# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev
Запуск с "отладкой" переключатель дает этот вывод .
Что еще я могу сделать, чтобы найти основную причину проблемы?
Регенерация с помощью sudo update-initramfs -c -k $ (uname -r) не произвел никаких видимых изменений после перезагрузки.
Это то, что я вижу в mtab до и после монтирования устройств вручную:
>sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
>sudo mount devpts /dev/pts -t devpts
>sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
Файловая система / dev / pts обычно монтируется с помощью initrd (также известного как initramfs) в Ubuntu.
initramfs - это небольшая файловая система, которая загружается в память, когда ядро загружается и устанавливает система для переключения на реальную корневую файловую систему после настройки основ и загрузки любых драйверов ядра, необходимых для монтирования настоящего корневого каталога.
Вы можете найти его в / boot с именем initrd.img- *, где последняя часть соответствует версия ядра.
Это сжатый с помощью xz архив cpio.
Вы можете заглянуть внутрь сценария "init", который запускается впервые при монтировании, используя следующую команду.«Grep» в конце этого файла смотрит на строку, которая монтирует devpts:
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts
mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true
Этот devpts фактически монтируется в корне initramfs, поэтому позже есть еще один шаг, который перемещает его в настоящий корень перед переключением на него. Вы можете посмотреть его здесь:
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move
# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev
Если вы хотите извлечь все содержимое initrd, вы можете использовать:
# First go to an empty directory
$ mkdir -p /tmp/extract_initrd
$ cd /tmp/extract_initrd
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -id
А затем исследовать это дерево ...
Если кажется, что что-то не так с вашим initramfs, вы можете попытаться сгенерировать его заново с помощью команды update-initramfs , например так:
$ sudo update-initramfs -c -k $(uname -r)
Остерегайтесь любых ошибок в выводе этой команды, они могут дать вам подсказку о том, что может быть идет не так ...
Другая возможность - включить ведение журнала отладки в initrd. Для этого добавьте «отладку» в командную строку ядра и перезагрузитесь. Затем после загрузки системы просмотрите файл /run/initramfs/initramfs.debug, который будет содержать сообщения, напечатанные сценариями initrd. См. здесь для получения дополнительной информации об отладке initramfs.
Когда я получал «Сервер отказался выделить pty», это была гораздо более простая проблема: мой SSH-сервер имел параметр «PermitTTY», установленный на «нет». (В последних версиях OpenSSH эта строка обычно закомментирована, потому что по умолчанию задано «да». Пока она не установлена вручную на «нет», все будет в порядке.)
Используйте свой любимый редактор, чтобы дважды - проверьте свой файл sshd_config.
sudo nano /etc/ssh/sshd_config
Убедитесь, что строка «PermitTTY» отсутствует, закомментирована или вручную установлена на «да», затем перезапустите сервер SSH.
sudo service sshd restart
Это может быть все, что вам нужно.
У меня была аналогичная проблема на https://serverfault.com/a/934030/33095
Разрешения были другими, чем ожидалось,но смог исправить это, используя:
sudo mount -o remount /dev/pts
sudo grep devpts /proc/mounts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0