Перезагрузка зависает на 100% - возможно в mountall

ОБНОВЛЕНИЕ: Кажется, что mountall висит внутри подпрограммы emit_event (), которую он вызывает после / перемонтируется для создания события с таким эффектом. Внутри emit_event он вызывает ply_boot_client_flush (), затем создает массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там это висит. Итак, есть идеи, почему dbus_pending_call_block зависает бесконечно? Сломанный плимут? DBus? выскочка? Есть предложения по исправлению или дальнейшей диагностике?

Перезагрузка моей Ubuntu 10.04 LTS, 64-битная машина AMD зависает на 100%. Индикатор доступа к диску не горит, но клавиши alt-sysreq работают. Аппаратное обеспечение - ноутбук Lenovo W700ds. Теперь я заранее извиняюсь, потому что я очень ограничен в информации о системе, которую я имею в наличии, и в том, что я могу с ней сделать (потому что она не загружается). Я могу загрузиться с 10.04 CD - используя его как аварийный диск. Я могу fsck, монтировать, читать и писать в мои разделы - они в порядке. Я уже пытался переформатировать своп с помощью mkswap. У меня есть 4 раздела ext4 в моей системе: sda1 - это /, sda2 - это / usr, sda3 - это / home, и 4-й, который я использую для хранения данных / sdb1 (это весь диск, монтируется в точке монтирования / hdb, которую я создал) , Также есть / sda4, который является swap. Прямо сейчас я пишу это из браузера, который я открыл в «спасательной сессии» из 10.

Я был бы очень признателен за предложения / комментарии о том, что я могу сделать, чтобы помочь диагностировать, что висит, почему и что я мог сделать, чтобы это исправить. Я уже выполнил веб-поиск, но ничего нового не нашел (некоторые сообщения об ошибках 1-1,5 лет с похожими симптомами, но их исправления не работали).

Я установил 10.04 на новый диск первого июля, а затем использовал aptitude, чтобы обновить все. С тех пор я установил многопакетов (я прикреплю журнал dpkg ниже). С sda 750GB (/ 20GB, / usr 80GB) у меня было много места для установки пакетов, которые я «когда-нибудь смогу использовать». Интересно, один из этих пакетов, который я установил, испортил мою систему? Я установил ядро ​​2.6.32-32-generic и перезагрузился, но с тех пор установил гораздо больше пакетов. Я перезагружаю эти машины настолько редко, насколько это возможно - предпочитая переводить их в спящий режим при перемещении с места на место. Однако в последнее время я заметил странное поведение, связанное с де-гибернацией: когда система выйдет из режима гибернации, она вызовет экранную заставку gnome с паролем, необходимым для разблокировки - ну, он не узнает мой пароль! Мне пришлось alt-F1, войти в систему как root, и убить заставку. Тогда все будет хорошо, или так казалось. Также, после спячки я часто видел на экране мигающий разноцветный мусор. Это ушло бы, поэтому я не пытался найти причину. Другим, возможно, важным моментом является то, что мне нужно было использовать «nomodeset» при установке 10.04, и при вызове аварийной оболочки с того же компакт-диска, если я использую только nomodeset, он будет зависать с мигающим светодиодом NumLock или Caps Lock ( сбой?), но если я также использую «noapic nolapic acpi = off», то все в порядке. Я попробовал эти варианты с моей системой, чтобы увидеть, излечивают ли они проблему зависания при загрузке - они этого не делают. если я использую только nomodeset, он в конечном итоге будет зависать с мигающим светодиодом NumLock или Caps Lock (сбой?), но если я также использую «noapic nolapic acpi = off», то все в порядке. Я попробовал эти варианты с моей системой, чтобы увидеть, излечивают ли они проблему зависания при загрузке - они этого не делают. если я использую только nomodeset, он в конечном итоге будет зависать с мигающим светодиодом NumLock или Caps Lock (сбой?), но если я также использую «noapic nolapic acpi = off», то все в порядке. Я попробовал эти варианты с моей системой, чтобы увидеть, излечивают ли они проблему зависания при загрузке - они этого не делают.

Это машина, которую я использую как для работы, так и почти для всего остального, поэтому ее повторная загрузка является главным приоритетом. / дом не поврежден, что хорошо. Но я почти сошел с ума, пытаясь диагностировать (а тем более исправить) причину зависания ботинка.

Я загружаю систему, и она запускает скрипт конфигурации mountall в /etc/init/mountall.conf. Я вижу вывод от mountall, выполняющего fsck - 4 строки, в которых говорится: fsck из util-linux-ng 2.17.2 (по одному на раздел ext4). Затем от fsck есть еще 4 строки, информирующие пользователя о том, что разделы признаны «чистыми». И это все - все просто останавливается. Индикатор активности диска гаснет. Я могу использовать ключи alt-sysreq, но они пока не доказали свою полезность. Я видел сообщение об ошибке, в котором один пользователь использовал alt-sysreq-i для уничтожения процесса, и он бросил его в оболочку. Для меня это говорит, что он убил процессы (udev и udev-bridge и plymouth, говорит, что он вызывает udev и т. Д.), Но я не получаю никакой оболочки.

Я пытался определить, что именно висит. Для этого я возился с /etc/init/mountall.conf. Я добавил строки эха, и я добавил опцию -v (подробный) в exec mountall. Никакие линии эха после exec mountall не показаны, так что это может означать, что mountall зависает. Или, возможно, он не отображает последний из выходных данных - в этом случае mountall мог завершиться, и что-то еще может зависать. Я отмечаю, что alt-sysreq-i не говорит, что mountall убит. Я попытался сузить то, что система может зависать, закомментировав sda3 (/ home), swap и sdb1 (/ hdb) из fstab, но все равно зависает.

Есть много, что я могу сделать сам, но чувствую, что я здесь над головой. Я хотел бы, например, получить исходный код для mountall, добавить напечатанные флаги, перекомпилировать и вставить его в мою систему - чтобы сузить A), если mountall на самом деле висит, и B) на чем он висит. НО, я не могу загрузить свою машину в оболочку, из которой можно скомпилировать - а среда на спасательном диске - только 2.6.32-28-generic # 55 - поэтому она не будет соответствовать моей системе. Я хотел бы удалить или переустановить пакеты, но, опять же, я не могу загрузить свою машину и сделать это.

(мой файл журнала dpkg занимает несколько МБ, поэтому я прикреплю его в следующем диалоговом окне)

Спасибо Грег

Денверко: Я ничего не сделал с моей машиной, которая должна была дать такой результат. Это было довольно стабильно под Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с исходным кодом, перекомпилировать вещи - все это был пользовательский код. Я вообще не возился с ОС. Я также не установил никакого кода OS-space вне стандартных каналов (менеджер пакетов aptitude / synaptic, пакеты deb, полученные с помощью этих инструментов). Грег вчера

Однако я получил исходный код для mountall 2.15.3 и получил его для компиляции в среде восстановления после 5 установок (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) , Я добавил отладочные отпечатки в код с помощью вызовов nih_info (), и я создал порождающие программы, которые выполняют блокировку fsck вместо неблокирования. Я работаю над теорией, что mountall где-то падает (или nih, или dbus, или plymouth ...). Кажется, я не получаю вывод в одно и то же место в коде при каждом запуске, но кажется, что он останавливается через некоторое время после перемонтирования / dev / sda1 в / - в функции mount (). Грег вчера

Я также делал dpkg -r пакетов через chroot, как вы предложили, и это, кажется, работает (за исключением одного сценария deinstall, который хотел что-то сделать с / proc). Я удалил wine, и необходимые ему 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в среде аварийного восстановления (некоторые пакеты ibus есть, и я старался не удалять их) -removed плазма-виджет-kimpanel-backend-ibus, ibus-qt4, ibus-qt1. Ничто из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне больше не нужны (пакеты wx widget, jdk и т. Д.) - без эффекта

ОБНОВЛЕНИЕ: Кажется, что mountall висит внутри подпрограммы emit_event (), которую он вызывает после / перемонтируется для генерации и события с этой целью. Внутри emit_event он вызывает ply_boot_client_flush (), затем создает массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там это висит. Итак, есть идеи, почему dbus_pending_call_block зависает бесконечно? Сломанный плимут? DBus? выскочка? Есть предложения по исправлению или дальнейшей диагностике?

РЕШЕНИЕ Итак, похоже, я установил cloud-init и cloud-utils, потому что я думал, что когда-нибудь захочу поиграть с ними. Will, откручивает винты cloud-init с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», которое привело к зависанию моей системы, как только она отправила это сообщение dbus, которое происходит после того, как / будет перемонтировано из ro в г / мас. Я деинсталлировал cloud-init и cloud-utils, и теперь все выглядит нормально. За исключением того, что я сонный и потерял 24 часа моей жизни: \