Я использовал этот ящик 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
Бег 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 до и после монтирования devpts вручную:
>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
Когда я получал «Сервер отказался выделить 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
Файловая система / dev / pts обычно монтируется initrd (он же initramfs) в Ubuntu.
Initramfs - это небольшая файловая система, которая загружается в память при загрузке ядра и настраивает систему для переключения на настоящую корневую файловую систему после настройки основных параметров и загрузки любых драйверов ядра, необходимых для монтирования настоящего корневого каталога.
Вы можете найти его в / boot с именем initrd.img- *, где последняя часть соответствует версии ядра.
Это архив cpio, сжатый в формате xz.
Вы можете заглянуть внутрь сценария "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.