ACTUALIZACIÓN: Parece que Mountall está colgando dentro de la rutina emit_event (), que llama después / se vuelve a montar para emitir un evento a tal efecto. Dentro de emit_event, llama a ply_boot_client_flush (), luego construye la matriz env, llama a upstart_emit_event (), luego dbus_pending_call_block (). Y ahí cuelga. Entonces, ¿alguna idea de por qué dbus_pending_call_block se colgaría indefinidamente? Plymouth roto? dbus? ¿advenedizo? ¿Alguna sugerencia para soluciones o diagnósticos adicionales?
Reinicio de mi Ubuntu 10.04 LTS, la máquina AMD de 64 bits se bloquea al 100%. La luz de acceso a la unidad está apagada, pero las teclas alt-sysreq funcionan. El hardware es un portátil Lenovo W700ds. Ahora, me disculpo de antemano, porque estoy muy limitado en la información sobre el sistema que tengo disponible y en lo que puedo hacer con él (porque no arrancará). Puedo arrancar desde el CD 10.04, usándolo como un disco de rescate. Puedo fsck, montar y leer y escribir en mis particiones, están bien. Ya intenté formatear mi intercambio con mkswap. Tengo 4 particiones ext4 en mi sistema: sda1 es /, sda2 es / usr, sda3 es / home, y una cuarta que uso para almacenamiento de datos / sdb1 (es el disco completo, se monta en el punto de montaje / hdb que creé) . También hay / sda4 que es swap. En este momento estoy escribiendo esto desde un navegador que abrí en la 'sesión de rescate' desde el 10.
Me GRANDEMENTE apreciar sugerencias / comentarios sobre lo que podría hacer para ayudar a diagnosticar lo que está colgando, por qué y qué podía hacer para solucionarlo. Ya hice una búsqueda web, pero no encontré nada nuevo en este sentido (algunos informes de errores de 1-1.5 años con síntomas similares, pero sus soluciones no funcionaron).
Instalé 10.04 en un nuevo disco alrededor del primero de julio, luego usé aptitude para actualizar todo. Desde entonces he estado instalando MUCHOSde paquetes (adjuntaré el registro dpkg a continuación). Con sda siendo 750GB (/ 20GB, / usr 80GB) tuve mucho espacio para instalar paquetes que 'algún día podría usar'. Me pregunto si es uno de estos paquetes que instalé que ha estropeado mi sistema. Instalé el kernel 2.6.32-32-generic y reinicié, pero desde entonces he instalado muchos más paquetes. Reinicio estas máquinas tan raramente como sea posible, prefiriendo hibernar mientras voy de un lugar a otro. Últimamente, sin embargo, noté un comportamiento extraño asociado con la deshibernación: cuando el sistema se deshiberna, aparece el protector de pantalla gnome con la contraseña necesaria para desbloquear, ¡bueno, no reconocería mi contraseña! Tuve que alt-F1, iniciar sesión como root y eliminar el protector de pantalla. Entonces todo estaría bien, o eso parecía. También, tras la hibernación, con frecuencia veía un breve parpadeo de basura colorida en la pantalla. Se iría, así que no intenté encontrar la causa. Otro punto posiblemente relevante es que necesitaba usar "nomodeset" en la instalación de 10.04, y al abrir el shell de rescate de ese mismo CD, si uso solo nomodeset, eventualmente se colgará con un LED NumLock parpadeante o un LED de bloqueo de mayúsculas ( crash?), pero si también uso "noapic nolapic acpi = off", entonces sale bien. He probado estas opciones con mi sistema para ver si resuelven el problema de bloqueo de arranque, no lo hacen. si uso solo nomodeset, eventualmente se colgará con un LED NumLock parpadeante o un LED de bloqueo de mayúsculas (¿bloqueo?), pero si también uso "noapic nolapic acpi = off", entonces aparece bien. He probado estas opciones con mi sistema para ver si resuelven el problema de bloqueo de arranque, no lo hacen. si uso solo nomodeset, eventualmente se colgará con un LED NumLock parpadeante o un LED de bloqueo de mayúsculas (¿bloqueo?), pero si también uso "noapic nolapic acpi = off", entonces aparece bien. He probado estas opciones con mi sistema para ver si resuelven el problema de bloqueo de arranque, no lo hacen.
Se trata de una máquina que utilizo para el trabajo, así como para casi todo lo demás, por lo que cada vez que se inicie de nuevo es una TOP prioridad. / home está intacto, lo cual es bueno. Pero estoy a punto de tratar de diagnosticar (y mucho menos arreglar) esta causa del arranque bloqueado.
Arranco el sistema y comienza a ejecutar el script de configuración de mountall en /etc/init/mountall.conf. Veo el resultado del montaje ejecutando fsck: 4 líneas que dicen: fsck de util-linux-ng 2.17.2 (eso es uno por partición ext4). Luego hay 4 líneas más de fsck que informan al usuario que se encontró que las particiones estaban "limpias". Y eso es todo, todo se detiene. El LED de actividad de la unidad se apaga. Puedo usar las teclas alt-sysreq, pero hasta ahora no han resultado útiles. Vi un informe de error en el que un usuario usaba alt-sysreq-i para matar el proceso y lo dejó caer en un shell. Para mí, dice que ha matado procesos (udev y udev-bridge y plymouth, dice que está reapareciendo udev, etc.), pero no obtengo ningún shell.
He estado tratando de determinar qué es exactamente lo que cuelga. Con este fin, he jugado con /etc/init/mountall.conf. He agregado líneas de eco, y he agregado la opción -v (detallada) al ejecutivo de mountall. No se muestran líneas de eco después del ejecutivo de Mountall, por lo que esto puede significar que Mountall está colgando. O bien, es posible que no muestre el último resultado, en cuyo caso puede que haya salido el montaje y que haya algo más colgado. Noto que alt-sysreq-i no dice que mauntall es asesinado. He tratado de reducir lo que el sistema podría estar colgando comentando sda3 (/ home), swap y sdb1 (/ hdb) desde fstab, pero aún se bloquea.
Hay muchas cosas que puedo hacer por mí mismo, pero siento que estoy muy loco aquí. Me gustaría, por ejemplo, obtener el código fuente para el montaje, agregar banderas impresas, volver a compilar y pegarlo en mi sistema, para reducir A) si el montaje realmente está colgando, y B) de qué está colgando. PERO, no puedo iniciar mi máquina en un shell desde el cual compilar, y el entorno del disco de rescate es solo 2.6.32-28-genérico # 55, por lo que no coincidiría con mi sistema. Me gustaría eliminar o reinstalar paquetes, pero nuevamente, no puedo iniciar mi máquina y hacer esto.
(mi archivo de registro dpkg tiene varios MB, por lo que lo adjuntaré en el siguiente cuadro de diálogo)
Gracias greg
fuente
Respuestas:
Denwerko: No he hecho nada a mi máquina que debería haber producido este resultado. Era bastante estable en Ubuntu 9.10: nunca sucedió algo así. Todos los retoques con la fuente, recompilando cosas: todo ha sido código de espacio de usuario. No he estado jugando con el sistema operativo. Tampoco he instalado ningún código de espacio OS fuera de los canales estándar (administrador de paquetes aptitude / synaptic, paquetes deb obtenidos a través de esas herramientas). Greg ayer
Sin embargo, obtuve el código fuente para montar 2.15.3 y lo compilé en el entorno de rescate, después de 5 instalaciones (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) . Agregué impresiones de depuración en el código a través de llamadas nih_info (), e hice los engendros que ejecutan el bloqueo fsck en lugar de no bloqueo. Estoy trabajando en la teoría de que Mountall está fallando en algún lugar (o nih, o dbus o plymouth ...). Parece que no obtengo resultados en el mismo lugar en el código cada ejecución, pero parece que se detiene en algún momento después del remontado de / dev / sda1 a / - en la rutina montada (). Greg ayer
También he estado haciendo dpkg -r de paquetes a través de chroot como sugirió, y parece funcionar (excepto por un script de desinstalación que quería hacer algo con / proc). Desinstalé wine y los paquetes de compatibilidad de 32 bits que necesitaba (lib32nss, ia32lib, lib32v4l, etc.) y varios paquetes ibus que no están instalados en el entorno de rescate (algunos paquetes ibus sí, y tuve cuidado de no eliminarlos). plasma-widget-kimpanel-backend-ibus, ibus-qt4, ibus-qt1. Nada de esto afectó el problema, así que eliminé más paquetes que no necesito ahora (wx widget y paquetes jdk, etc.) sin efecto
ACTUALIZACIÓN: Parece que Mountall está colgando dentro de la rutina emit_event (), a la que llama después / se vuelve a montar para emitir y evento a tal efecto. Dentro de emit_event, llama a ply_boot_client_flush (), luego construye la matriz env, llama a upstart_emit_event (), luego dbus_pending_call_block (). Y ahí cuelga. Entonces, ¿alguna idea de por qué dbus_pending_call_block se colgaría indefinidamente? Plymouth roto? dbus? ¿advenedizo? ¿Alguna sugerencia para soluciones o diagnósticos adicionales?
SOLUCIÓN Entonces, parece que instalé cloud-init y cloud-utils porque pensé que algún día querría jugar con él. Will, produce tornillos de inicio de nube con la configuración de ureadahead, y se inicia cuando ocurre el evento dbus 'montado /', lo que hace que mi sistema se bloquee tan pronto como envió ese mensaje dbus, que sucede después / se vuelve a montar de ro a r / w. Desinstalé cloud-init y cloud-utils y todo parece estar bien ahora. Excepto que tengo sueño y he perdido 24 horas de mi vida: \
fuente