Перезагрузка висит на 100% - возможно, в mountall
: кажется mountall висит внутри рутинную emit_event(), которые он вызывает после / вновь испускать событие на этот счет. Внутри emit_event, он призывает ply_boot_client_flush(), затем создает массив ОКР, звонки upstart_emit_event(), то dbus_pending_call_block(). И она там висит. Поэтому любые идеи, почему dbus_pending_call_block будет висеть бесконечно? Сломанный Плимут? ДГУ? выскочка? Какие-либо предложения для исправления или дальнейшей диагностики?
Перезагрузка моей убунту 10.04 ЛТС, 64-битный драм машина зависает 100%. Доступа к этому диску не горит, но клавиши Alt-sysreq ключи работают. Оборудование ноутбук Lenovo W700ds. Так вот, я заранее извиняюсь, потому что я очень ограничен в информации о системе у меня имеется, и в то, что я могу с этим сделать (потому что он не загрузится). Я могу загрузиться с диска 10.04 - используя ее как спасательный диск. Я могу для fsck, Mount и читать и писать, чтобы мои разделы - они прекрасны. Я уже пробовал переформатировать мой своп с команды mkswap. У меня 4 ext4 разделов на моей системе: sda1-это /, sda2-это /usr, sda3 в качестве это /Home, А 4-й, который я использую для хранения данных /sdb1 (это весь диск, монтируется в каталог /пдл, который я создал). Существует также /sda4 в которых своп. Сейчас я пишу это из браузера, я открыл в спасательных сессии от 10.04 ЛТС установочный диск.
буду весьма признателен за предложения/замечания о том, что я мог сделать, чтобы помочь диагностировать, что висит, почему, и что я могу сделать, чтобы это исправить. Я сделал уже скучно, но не нашел ничего нового по этим направлениям (около 1-1.5-летняя сообщения об ошибках с похожими симптомами, но их исправление не работает).
я установил 10.04 на Новый Диск вокруг первого июля, а затем использовать способности довести все до даты. С тех пор я установка сильно пакетов (я добавлю в dpkg лог ниже). С ПДД будучи 750ГБ (/ 20 ГБ /80ГБ ЕГР) у меня было много места, чтобы установить пакеты, которые я мог бы использовать'. Интересно, если один из этих пакетов я установил, что испортил мне систему? Я установил ядро 2.6.32-32-generic и перезагружается, но установили много пакетов с. Я перезагрузки как можно реже, машины, предпочитая зимовать он, идя с места на место. Хотя в последнее время, я заметил некоторые странности в поведении, связанные с де-спящий режим: при загрузке системы будет де-спящий режим он приносит гном заставки с паролем, нужно разблокировать - ну, он не признает мой пароль! У меня на Alt-F1 и войдите в систему как root, и убить заставки. Тогда все будет хорошо, или так казалось. Также, по де-гибернации я часто вижу на короткое время мигают разноцветные артефакты на экране. Он будет уходить, так что я не пытался найти причину. Еще один, возможно, важный момент заключается в том, что мне нужно использовать "nomodeset" в установке 10.04, а после запуска оболочки восстановления с того же компакт-диска, если я использую только nomodeset это в конечном итоге будет висеть с мигающим состояние индикатора numlock или Caps замок светодиод (авария?), но если я использую "надо nolapic ACPI в=", тогда дело доходит до ок. Я пробовал эти варианты с моей системой, чтобы увидеть, если они вылечить проблему загрузки висят - они не.
это машина, которую я использую для работы, а также почти все остальное, так что он снова загрузки является главным приоритетом. /дома целы, это хорошо. Но я в моем конце остроумия, пытаясь диагностировать (тем более решить) эту причину висел ботинок.
я загрузил систему, и она начинает работать в mountall скрипт конфиг в /etc/инит/mountall.конф. Я вижу выход из mountall запустить fsck - 4 линии, которые говорят: для fsck из util-Linux на НГ 2.17.2 (это по одному на каждый раздел в ext4). Затем есть еще 4 строчки из блока информирования пользователя о том, что разделы оказались "чистыми". И что это - все просто остановится. Активность диска не погаснет. Я могу использовать сочетание клавиш Alt-sysreq ключи, но они до сих пор не доказали свою полезность. Я увидел сообщение об ошибке, где один пользователь хоткей Alt-sysreq-я убить процесс, и он бросил его в раковину. Для меня это говорит, что он убил процессы (в udev и udev-Bridge и Плимут, говорит о возрождении в udev и т. д.), но я не получаю никакой оболочки.
я пытаюсь определить, что именно висит. С этой целью, я возился с /etc/инит/mountall.конф. Я добавил линии Эхо, и я добавил опцию-V (подробный) для запуска mountall. Нет линии Эхо после запуска mountall показаны, так что это может означать mountall висит. Или, может быть, это не отображение последнего вывода - в этом случае mountall, возможно, вышел и что-то еще может висеть. Замечу, что Alt-sysreq-я не говорю mountall убит. Я пытался сузить то, что система может быть висящие на закомментировав sda3 в качестве (/дома), своп и sdb1 (/hdb), в с файл fstab, но он до сих пор висит.
я многое могу сделать сам, но чувствую, что я в над моей головой здесь. Я хотел бы, чтобы, например, получить исходный код для mountall, добавить печатные флаги, перекомпилировать и придерживаться его в моей системе - сузить) если mountall на самом деле висит, и Б) что это висит на. Но, я не могу загрузить мою машину в оболочке, из которой для компиляции В - И в среду восстановления диска только 2.6.32-28-generic и #55 - так это не соответствует моей системе. Я хочу удалить или переустановить пакеты, но опять же, я не могу загрузить мою машину и сделать это.
(мой лог-файл dpkg-это несколько мегабайт, поэтому я буду прикреплять в следующем диалоговом окне)
Спасибо, Грэг
9 ответов
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -no effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \
Денверко: Я ничего не сделал для своей машины, которая должна была дать этот результат. Это было довольно стабильно в Ubuntu 9.10 - никогда не было ничего подобного. Все возиться с источником, перекомпилировать вещи - все это код пользовательского пространства. Я вообще не возился с ОС. Я также не установил какой-либо код OS-space вне стандартных каналов (aptitude / synaptic package manager, пакеты 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, как вы предполагали, и, похоже, работает (за исключением одного сценария деинсталляции, который хотел что-то сделать с / proc). Я деинсталлировал вино и 32-битные пакеты совместимости (lib32nss, ia32lib, lib32v4l и т. Д.) И несколько пакетов ibus, которые не установлены в спасательной среде (некоторые пакеты ibus, и я старался не удалять их) - удалены плазма-виджет-кимпанель-бэкэнд-ibus, ibus-qt4, ibus-qt1. Ничего из этого не повлияло на проблему, поэтому я удалил больше пакетов, которые мне не нужны сейчас (wx widget & amp; jdk packages и т. Д.) -No effect
UPDATE: Кажется, что mountall висит внутри подпрограммы emit_event (), который он вызывает после / перемонтируется для испускания и события для этого эффекта. Внутри emit_event он вызывает ply_boot_client_flush (), затем конструирует массив env, вызывает upstart_emit_event (), затем dbus_pending_call_block (). И там он висит. Итак, любые идеи, почему dbus_pending_call_block зависают бесконечно? Сломанный плимут? DBus? выскочка? Любые предложения по исправлениям или дальнейшая диагностика?
РЕШЕНИЕ Итак, похоже, что я установил облачные и облачные утилиты, потому что, хотя я когда-нибудь захочу поиграть с ним. Will, получается винты с облачным экраном с конфигурацией ureadahead и запускается, когда происходит событие dbus «смонтировано /», из-за чего моя система зависает, как только она отправляет это сообщение dbus, которое происходит после / переустанавливается с ro на г / мас. Я удалил cloud-init и cloud-utils, и теперь все выглядит нормально. Кроме того, я сон и потерял 24 часа своей жизни: \