Не мог загрузиться на рабочий стол, после установки Ubuntu 19.10.1 на Raspberry Pi 4 и установке kubuntu-рабочего-стола
После установки Ubuntu 19.10.1 64-разрядное изображение сервера для Raspberry Pi 4, установка kubuntu-рабочего-стола и перезагрузка, загружаются зависания системы во время. Кажется, нет никакого способа добраться до настольного GUI. (Отметьте: я попробовал каждый доступный рабочий стол, хотя Kubuntu является моим предпочтительным. Результатами является то же для всех них.) Шаги для репродуцирования проблемы следуют.
Материалы
- Модель B Raspberry Pi 4B 4GB с 64-разрядным четырехъядерным ЦП ARMv8 на 1.5 ГГц (ПОРШЕНЬ на 4 ГБ)
- SD-карта на 32 ГБ
- Внешний SSD на 500 ГБ
- файл изображения ubuntu-19.10.1-preinstalled-server-arm64-raspi3.img, загруженный с https://ubuntu.com/download/raspberry-pi.
Шаги для репродуцирования
- Файл образа загрузки и запись к использованию SD-карты установка травления Balena (формат FAT32).
- Также запишите файл изображения к внешнему использованию SSD установка травления Balena (формат EXT4).
- Присоедините/вставьте оба устройства хранения к Raspberry Pi 4.
- Начальная загрузка Raspberry Pi 4. После изменяющегося пароля пользователя человечности загрузитесь, успешно выполняется без проблем. На самом деле, в этой точке, я могу SSH в RPi и делаю в значительной степени что-либо, что я хочу сделать от терминала PuTTY. Только, когда я пытаюсь добавить GUI, все это начинает отказывать.
- Установите рабочий стол Kubuntu с
sudo apt install kubuntu-desktop. Ни о каких ошибках не сообщают во время установки. (Отметьте: Выполненный эти те же шаги для рабочего стола человечности, xubuntu-рабочего-стола и многих других рабочих столов. Все имели те же результаты.) Перезагруженный Raspberry Pi с
sudo reboot. Перезагрузка произошла, пока она не зависла в [28,5791341] облако-init [1547]: облако-init v. 19.2-36. … В этой точке система заморозилась (Извините за не наличие сплошной линии в точке, которую заморозило. Это находится, очевидно, на другой машине с большим количеством строковых букв и чисел, таким образом копирование и вставление вне рассмотрения. Это действительно сообщает что законченное облако-init и корректное время для него окончание.cloud-initпроцесс начинается сразу после поспешного приложенияlxd.activateсервис запускается успешно.
В этой точке зависания системы с курсором на строке, описанной в Объекте 6 выше. Я попытался нажатие [Enter], введя Ctrl+C и все остальное, о чем я мог думать; ничто не переместит курсор или перезапустит процесс.
Из интересного примечания в этой точке я могу SSH (с PuTTY) в Raspberry Pi, успешно и могу ввести и выполнить все виды терминальных команд без проблем. Таким образом довольно ясно что некоторый процесс (облако-init?) подвешивается, не система.
Кроме того, от машины с записью SSH я могу сделать a sudo reboot, несколько раз, и это успешно пройдет процесс перезагрузки, пока это не поразит ту же точку, где это зависло прежде, в которой точке, это зависнет снова, точно так же, как прежде.
Обратите внимание, что я использую внешний SSD для операционной системы. Используя эту методологию, система использует SD-карту на 32 Гбита для загрузчика, затем переключается автоматически на SSD на 500 Гбит на sdb для операций. Ubuntu сделала отличную работу по тому, чтобы заставлять это произойти автоматически. Это раньше было ужасным испытанием для настраивания его и работа. Любой, кто попытался бы выполнить систему от SD-карты, должен быть безрассудной душой, которая берет восхищение в том, чтобы быть избитым путем попытки сделать так, тем более, что SSD добрались, чтобы быть очень дешевыми. (Даже с этим, люди Raspberry Pi мешали, будучи придирчивыми, о которых контроллерах внешнего диска RPi распознает и примет. К счастью, люди как James Chambers дали нам списки тех, которые действительно работают. В десятилетиях работы с внешними дисками у меня никогда не было проблем ни с каким внешним диском до RPi 4B. И у нас все еще должна быть SD-карта для загрузчика вместо того, чтобы загрузиться непосредственно к SSD — что-то, что RPi 3 сделал вполне приятно. Разговор об одном небольшом шаге для RPi, один огромный, гигантский прыжок назад! Но я отступаю.) я использовал эту функциональность прежде. Просто требуемый, чтобы сообщить, что это действительно работает.
Кроме того, извините о неэффективном использовании тегов. Правила StackOverflow относительно тегов препятствуют тому, чтобы я использовал что-то как 19.10.1 вместо 19.10, различие, которое является критически импортом в этой проблеме. Так же для множества других тегов.
3 ответа
Я рад видеть, что кто-то еще испытал ТОЧНО ту же проблему, которую я имею! И вот обходное решение, которое я нашел - не решение, но это получает работу Kubuntu. Когда Вы переходите к сути дела, где зависания системы, можно переключиться на другой TTY. Я полагаю, что система запускается в TTY1, который, как предполагается, является тем, используемым для графического интерфейса. Можно переключиться на TTY2 путем нажатия CTL+ALT+F2, и необходимо получить приглашение ко входу в систему. Вход в систему как Ubuntu, и когда Вы получаете подсказку, выполняет "startx". Это поднимет рабочий стол Kubuntu, и Вы уже зарегистрированы в него. И я должен сделать этот каждый раз, когда я загружаю систему. Я думаю, что это должно быть ошибкой в процедуре установки Kubuntu, но я должен все же найти путь вокруг этого. Уверенный было бы хорошо, если бы кто-то зафиксировал его. Должен быть файл где-нибудь, что Вы могли вставить команду "startx" и иметь выполненный при начальной загрузке, но я не знаю достаточно о Ubuntu, чтобы сделать это.
Спасибо за информацию. Я подумал, может быть, мне нужно настроить запуск в графическом режиме, поэтому из упомянутого выше TTY2 я выдал:
$sudo systemctl set-default graphical
Затем я перезагрузился и снова застрял на том же месте. Поэтому я пошел по ручному пути:
$sudo systemctl set-default multi-user
Затем я вхожу в систему и запускаю команду startx.
У меня была такая же проблема. Я просто удалил cloud-init, и kubuntu загрузился нормально.
sudo apt remove cloud-init