A reinicialização trava 100% - possivelmente em mountall

UPDATE: Parece que mountall está suspenso dentro da rotina emit_event (), que ele chama após / é remontada para emitir um evento nesse sentido. Dentro de emit_event, ele chama ply_boot_client_flush (), então constrói a matriz env, chama upstart_emit_event () e, em seguida, dbus_pending_call_block (). E aí está. Então, alguma idéia de por que dbus_pending_call_block ficaria indefinidamente? Plymouth quebrado? dbus? subir na vida? Alguma sugestão para correções ou mais diagnósticos?

A reinicialização do meu Ubuntu 10.04 LTS, máquina AMD de 64 bits, trava 100%. A luz de acesso à unidade está apagada, mas as teclas alt-sysreq funcionam. O hardware é um laptop Lenovo W700ds. Agora, peço desculpas antecipadamente, porque sou muito limitado nas informações sobre o sistema que tenho disponível e no que posso fazer com ele (porque não inicializa). Eu posso inicializar a partir do CD 10.04 - usando-o como um disco de recuperação. Eu posso fsck, montar, ler e escrever nas minhas partições - elas estão bem. Eu já tentei reformatar meu swap com mkswap. Eu tenho 4 partições ext4 no meu sistema: sda1 é /, sda2 é / usr, sda3 é / home e uma quarta que eu uso para armazenamento de dados / sdb1 (é o disco inteiro, é montado no ponto de montagem / hdb que criei) . Há também / sda4 que é swap. No momento, estou escrevendo isso em um navegador que abri na 'sessão de resgate' do 10.

Eu gostaria muito de receber sugestões / comentários sobre o que eu poderia fazer para ajudar a diagnosticar o que está pendurado, por que e o que eu poderia fazer para corrigi-lo. Já fiz uma pesquisa na web, mas não encontrei nada novo nesse sentido (alguns relatos de erros de 1 a 1,5 anos com sintomas semelhantes, mas suas correções não funcionaram).

Instalei o 10.04 em um novo disco por volta de primeiro de julho e usei o aptitude para atualizar tudo. Desde então, venho instalando LOTSde pacotes (anexarei o log do dpkg abaixo). Com sda sendo 750GB (/ 20GB, / usr 80GB), eu tinha muito espaço para instalar pacotes que 'algum dia eu poderia usar'. Gostaria de saber se é um desses pacotes que instalei que estragou meu sistema? Eu instalei o kernel 2.6.32-32-generic e reiniciei, mas instalei muitos outros pacotes desde então. Eu reinicializo essas máquinas o mais raramente possível - preferindo hiberná-las ao ir de um lugar para outro. Ultimamente, notei algum comportamento estranho associado à des-hibernação: quando o sistema des-hiberna, ele exibe o protetor de tela do gnome com a senha necessária para desbloquear - bem, ele não reconhece a minha senha! Eu tive que alt-F1, fazer login como root e matar o protetor de tela. Então tudo ficaria bem, ou assim parecia. Além disso, na des-hibernação, eu frequentemente via por um breve momento piscando lixo colorido na tela. Isso iria embora, então eu não tentei encontrar a causa. Outro ponto possivelmente relevante é que eu precisava usar o "nomodeset" na instalação do 10.04 e, ao abrir o shell de resgate a partir desse mesmo CD, se eu usar apenas o nomodeset, ele ficará travado com um LED NumLock ou LED Caps Lock piscando ( falha?), mas se eu também usar "noapic nolapic acpi = off", ele aparecerá ok. Eu tentei essas opções com o meu sistema para ver se elas solucionam o problema de travamento de inicialização - elas não o fazem. se eu usar apenas o conjunto de nomes, ele eventualmente ficará travado com um LED NumLock piscando ou um LED Caps Lock (falha?), mas se eu também usar "noapic nolapic acpi = off", ele será exibido. Eu tentei essas opções com o meu sistema para ver se elas solucionam o problema de travamento de inicialização - elas não o fazem. se eu usar apenas o conjunto de nomes, ele eventualmente ficará travado com um LED NumLock piscando ou um LED Caps Lock (falha?), mas se eu também usar "noapic nolapic acpi = off", ele será exibido. Eu tentei essas opções com o meu sistema para ver se elas solucionam o problema de travamento de inicialização - elas não o fazem.

Esta é uma máquina que eu uso para o trabalho, bem como para tudo, quase mais, de modo a ficar-lo para iniciar novamente é um TOP prioridade. / home está intacto, o que é bom. Mas eu estou no meu juízo final tentando diagnosticar (muito menos consertar) essa causa da bota pendurada.

Inicializo o sistema e ele começa a executar o script de configuração mountall no /etc/init/mountall.conf. Eu vejo a saída do mountall executando o fsck - 4 linhas que dizem: fsck do util-linux-ng 2.17.2 (isso é um por partição ext4). Depois, existem mais 4 linhas do fsck informando ao usuário que as partições foram consideradas "limpas". E é isso - tudo simplesmente pára. O LED de atividade da unidade se apaga. Eu posso usar as teclas alt-sysreq, mas até agora elas não se mostraram úteis. Eu vi um relatório de bug em que um usuário usava o alt-sysreq-i para matar o processo e o colocava em um shell. Para mim, ele diz que matou os processos (udev e udev-bridge e plymouth, diz que está recuperando o udev, etc), mas não recebo nenhum shell.

Eu tenho tentado determinar o que exatamente está pendurado. Para esse fim, eu consertei o /etc/init/mountall.conf. Adicionei linhas de eco e a opção -v (detalhada) ao exec de mountall. Nenhuma linha de eco após o exec de mountall é mostrada; portanto, isso pode significar que mountall esteja travado. Ou, pode não estar exibindo a última saída - nesse caso, mountall pode ter saído e outra coisa pode estar paralisada. Observo que o alt-sysreq-i não diz que mountall está morto. Eu tentei restringir o que o sistema pode estar usando comentando sda3 (/ home), swap e sdb1 (/ hdb) do fstab, mas ele ainda trava.

Há muita coisa que posso fazer sozinho, mas sinto que estou passando por aqui. Gostaria, por exemplo, de obter o código-fonte para mountall, adicionar sinalizadores impressos, recompilar e colá-lo no meu sistema - para restringir A) se mountall estiver realmente suspenso e B) o que está pendurado. MAS, não consigo inicializar minha máquina em um shell a partir do qual compilar dentro - e o ambiente do disco de recuperação é apenas o número 2.6.32-28-genérico # 55 -, portanto, não corresponde ao meu sistema. Gostaria de remover ou reinstalar pacotes, mas, novamente, não consigo inicializar minha máquina e fazer isso.

(meu arquivo de log do dpkg tem vários MBs, então eu o anexarei na seguinte caixa de diálogo)

Obrigado Greg

Denwerko: Eu não fiz nada na minha máquina que deveria ter produzido esse resultado. Era bastante estável no Ubuntu 9.10 - nunca aconteceu nada assim. Todo o trabalho de mexer com a fonte, recompilando as coisas - tudo isso foi código do espaço do usuário. Eu não tenho mexido em nada com o sistema operacional. Também não instalei nenhum código de espaço no sistema operacional fora dos canais padrão (gerenciador de pacotes aptitude / synaptic, pacotes deb obtidos por essas ferramentas). Greg ontem

No entanto, eu obtive o código fonte para mountall 2.15.3 e o compilei no ambiente de recuperação, após 5 instalações (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) . Adicionei impressões de depuração no código por meio de chamadas nih_info () e criei os spawns que executam o bloqueio do fsck em vez do não-bloqueio. Estou trabalhando na teoria de que mountall está travando em algum lugar (ou nih, ou dbus ou plymouth ...). Parece que não recebo a saída no mesmo local no código a cada execução, mas parece parar algum tempo após a remontagem de / dev / sda1 para / - na rotina mount (). Greg ontem

Eu também tenho feito dpkg -r de pacotes via chroot, como você sugeriu, e isso parece funcionar (exceto por um script de desinstalação que queria fazer algo com / proc). Desinstalei o wine e os pacotes de compatibilidade de 32 bits necessários (lib32nss, ia32lib, lib32v4l, etc) e vários pacotes ibus que não estão instalados no ambiente de resgate (alguns pacotes ibus estão, e eu tinha cuidado de não removê-los) - removidos plasma-widget-kimpanel-backend-ibus, ibus-qt4, ibus-qt1. Nada disso afetou o problema, por isso removi mais pacotes que não preciso agora (widget wx e pacotes jdk, etc.)

UPDATE: Parece que mountall está pendurado dentro da rotina emit_event (), que chama depois / é remontada para emitir e evento para esse efeito. Dentro de emit_event, ele chama ply_boot_client_flush (), então constrói a matriz env, chama upstart_emit_event () e, em seguida, dbus_pending_call_block (). E aí está. Então, alguma idéia de por que dbus_pending_call_block ficaria indefinidamente? Plymouth quebrado? dbus? subir na vida? Alguma sugestão para correções ou mais diagnósticos?

SOLUÇÃO Então, parece que eu instalei o cloud-init e o cloud-utils, porque pensei que algum dia eu gostaria de brincar com ele. Will aciona os parafusos cloud-init com a configuração ureadahead e inicia quando o evento dbus 'montado /' acontece, o que causou o travamento do meu sistema assim que enviou a mensagem dbus, que ocorre após / ser remontada de ro para r / w. Desinstalei o cloud-init e o cloud-utils e tudo parece bem agora. Exceto que estou com sono e perdi 24 horas da minha vida: \