Сбой клиента XRDP на экране загрузки для Jetson Nano
Я пытаюсь получить доступ к своему Jetson nano с клиента XRDP (mac). Я установил XRDP на jetson, используя следующее:
sudo apt-get install xrdp
Кажется, это работает, поскольку когда я набираю
systemctl status xrdp
, я получаю следующий результат:
● xrdp.service - xrdp daemon
Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: ena
Active: active (running) since Thu 2020-04-16 10:08:07 EDT; 7min ago
Docs: man:xrdp(8)
man:xrdp.ini(5)
Process: 5046 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SU
Process: 4996 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, sta
Main PID: 5160 (xrdp)
Tasks: 1 (limit: 4174)
CGroup: /system.slice/xrdp.service
└─5160 /usr/sbin/xrdp
Однако после попытки подключения с клиента я вижу загрузку NVIDIA экран на секунду, а затем клиент вылетает. Как я могу предотвратить это?
Примечание: я использую Ubuntu 18.04 LTS, образ, предоставленный NVIDIA
3 ответа
У меня была точно такая же проблема с Jetson Nano, и решение не очевидное, но очень простое - оно будет делать это, если вы вошли в консоль Jetson при попытке RDP. Выход из системы / перезагрузка, а затем подключение через RDP исправляет это.
Только что проверено при новой установке:
- Образ SD-карты, вставьте в Jetson и загрузитесь
- Запустите через первую настройку Ubuntu
- После перезагрузки запустите
apt-get install -y xrdp - Перезагрузить / выйти из системы
- Подключиться через RDP
У меня была такая же проблема. Журнал (/etc/log/xrdp.log) на jetson показал проблемы с доступом к /etc/xrdp/cert.pem (который ссылается на /etc/ssl /частное/..).
xrdp принимает пользователей только из группы ssl-cert. Добавьте пользователя в группу.
sudo adduser myUserName ssl-cert
Однако обратите внимание, что сеанс rdp открывает новый сеанс «X11» (не такой, как в Windows, где он «берет» рабочий стол), который может быть немного сложно настроить (выбор X11rdp по умолчанию для сеанса twm — настроенный в /etc/xrdp/xrdp.ini)
Проблема возникла при обновлении с libdrm-amdgpu1_2.4.97-1ubuntu1~18.04.1_arm64 до libdrm-amdgpu1_2.4.99-1ubuntu1~18.04.1_arm64.
К сожалению, это все еще сохраняется с libdrm-amdgpu1_2.4.101-2~18.04.1_arm64. Не уверен на 100% для libdrm-amdgpu1_2.4.102-1ubuntu1_arm64, так как это также требует игнорировать зависимость от более новой libc6.
Но если вы используете libdrm2=2.4.101-2~18.04.1 и вручную устанавливаете только libdrm-amdgpu1=2.4.97-1ubuntu1~18.04.1 он все еще работает.
Я не мог выяснить, почему именно это происходит. Особенно интересно, потому что у nano определенно нет графического процессора AMD... . И моя надежда на то, что она будет решена через год, тоже угасает. И это не постоянный обходной путь из-за скоро невыполнимых зависимостей. Возможно, кто-то сможет копнуть глубже с этой информацией.