Начальная загрузка Ubuntu 14.04 зависает в логотипе после обновления
Вчера, я сделал a update/dist-upgrade. Сегодня, я включил машину, и она зависала в загружающемся экране с логотипом и циклически повторяла точки - я ожидал в этом экране приблизительно в течение часа несколько раз без результатов. Если я прерываю upstart с ctrl-alt-del возобновляется/завершает начальная загрузка, но это помещает меня в tty консольный вход в систему. X действительно запускается, несколько секунд спустя, но диалоговое окно о графике, настраиваемой неправильно, сразу поднято. Обновление: Эти X вопросов были решены путем выполнения apt-get install nvidia-current. Проблема прерывания все еще стоит.
К сожалению, каждый вывод, который я нашел относительно того, почему это могло бы происходить, превратился в тупик. Вот мой boot.log (от /var/log) показ, где я прервал запуск. Вы видите, что это зависает так же, как это запускается, "позволяют остаться устройствами зашифрованного блока времени начальной загрузки" (это от cryptdisks), но удаление того сервиса не имеет никакого значения. Я попробовал в значительной степени все из этого отчета об ошибках Монетного двора, который описывает признаки, почти идентичные моему, напрасно. На данном этапе я абсолютно уверен это cryptdisks отвлекающий маневр, и что это - что-то еще полностью.
Я также нашел, что возобновление запуска от режима восстановления, кажется, загружает вещи в другом порядке. Upstart все еще зависает, но не после cryptdisks. Если я ctrl-alt-del, это приводит меня графическому менеджеру по входу в систему вместо tty, и я могу войти в систему успешно. Однако система все еще не полностью функциональна; Plug and Play USB, кажется, не работает, я не могу использовать свой второй монитор, и я должен вручную сделать start resolvconf получить доступ к Интернету. Вот boot.log от одних из тех стартапов.
Я должен добавить, что шифрую свой жесткий диск с LUKS, и подвешивание происходит после того, как я успешно введу пароль дешифрования. Вот мой fstab, в случае, если это имеет какое-либо отношение к вещам:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=9e7c1e90-f3e4-4075-b3b0-e3ccb6d933c7 /boot ext2 defaults 0 2
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
Что продолжается здесь?
2 ответа
первопричиной было огромное количество файлов в моем /tmp каталог.
я использовал /tmp каталог для хранения миллионов файлов ранее. Оказывается, что наличие, что много файлов там вызывают сервис, который убирает /tmp для взятия долгого, долгого времени (понятное дело). После перемещения файлов из /tmp, решена проблема. Это не имело никакого отношения к обновлению; это было просто совпадением.
В случае, если это помогает любому позже, вот процесс, я раньше понимал его. Я включил "Волшебный ключ SysRq" путем изменения etc/sysctl.d/10-magic-sysrq.conf. Затем я воспроизвел проблему путем перезагрузки; когда запуск завис, я поразил Высокий звук - SysRq - t . Это вывело следующее в буфере ядра, считайте использование dmesg:
[ 36.318527] SysRq : Show Blocked State
[ 36.318696] task PC stack pid father
[ 36.318719] find D ffff88041dd93480 0 839 788 0x00000000
[ 36.318721] ffff880405d07a48 0000000000000082 ffff880401136000 ffff880405d07fd8
[ 36.318723] 0000000000013480 0000000000013480 ffff880401136000 ffff88041dd93d18
[ 36.318725] ffff88041dfab460 0000000000000002 ffffffff811ef380 ffff880405d07ac0
Это выводит намного больше, чем это, но это - соответствующая часть. Это показывает, что заблокированная задача find. После этого это был просто вопрос хорошо осведомленного друга, знающего, что /tmp услуги по уборке были вероятным преступником.
Слова благодарности, Chaosed0, для возвращения с Вашим решением (т.е. огромное количество файлов в/tmp). [Я пытался отправить это как комментарий, но у меня нет достаточного количества точек репутации]
, я столкнулся с той же проблемой с сервером Ubuntu (14.04), и было очень трудно диагностировать, пока я не нашел Ваше сообщение.
, Когда я перезагрузил машину, это, будет казаться, станет заблокированным прямо, прежде чем это обычно показывало бы консоль входа в систему. Это могло быть разблокировано путем нажатия Ctrl + Высокий звук + Del , который заставит сообщение журнала быть распечатанным, что wait-for-state (rcplymouth-shutdown) был завершен. То сообщение журнала отправило мне вниз неправильный путь ввода по абсолютному адресу различных плимутских сценариев и затем попытки отключить Плимут полностью :-(
На самом деле, процесс начальной загрузки не был заведен в тупик, это просто ожидало очистки /tmp для завершения. Та машина имела десятки тысяч файлов под /tmp, таким образом, долго долго требовалось много времени, чтобы сделать очистку.
, Таким образом, фиксация для меня должна была загрузиться в восстановление, получить корневую оболочку и затем rm -rf /tmp/*. Приблизительно после одного часа rm завершенное задание. Затем я перезагрузил, и все обычно работало.
было бы замечательно, если сообщение журнала могло бы быть распечатано, когда очистка /tmp запускается.