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

8

UPDATE: Parece que o mountall está dentro da rotina emit_event (), que chama depois de / é remontado para emitir um evento para esse efeito. Dentro de emit_event, ele chama ply_boot_client_flush (), então constrói o array env, chama upstart_emit_event (), depois dbus_pending_call_block (). E aí está trancado. Então, alguma idéia de porque o dbus_pending_call_block seria pendurado indefinidamente? Plymouth quebrado? dbus? arrogante Alguma sugestão para correções ou diagnósticos adicionais?

Reinicialização do meu Ubuntu 10.04 LTS, a máquina AMD de 64 bits trava 100%. A luz de acesso da unidade está apagada, mas as teclas alt-sysreq funcionam. O hardware é um laptop Lenovo W700ds. Agora, peço desculpas antecipadamente, porque estou muito limitado nas informações sobre o sistema que tenho disponível e no que posso fazer com ele (porque ele não inicializa). Eu posso arrancar a partir do CD 10.04 - usando-o como um disco de recuperação. Eu posso fsck, montar e ler & amp; escreva para minhas partições - elas estão bem. Eu já tentei reformatar meu swap com o 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 (é todo o disco, monta no ponto de montagem / hdb que eu criei) . Há também / sda4, que é swap. No momento, estou escrevendo isso de um navegador que abri na 'sessão de resgate' do CD de instalação da 10.04 LTS.

Gostaria de GREATLY agradecer 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 ao longo destas linhas (alguns relatórios de bugs de 1 a 1,5 anos com sintomas semelhantes, mas suas correções não funcionaram).

Eu instalei o 10.04 em um novo disco em torno do primeiro dia de julho, depois usei o aptitude para atualizar tudo. Desde então, tenho instalado LOTS de pacotes (vou anexar o log do dpkg abaixo). Com sda sendo 750GB (/ 20GB, / usr 80GB) eu tive muito espaço para instalar pacotes que eu 'um dia poderei usar'. Gostaria de saber se um desses pacotes que instalei atrapalhou o meu sistema? Eu instalei o kernel 2.6.32-32-genérico e reiniciei, mas instalei muitos mais pacotes desde então. Eu reinicio esta máquina o mais raramente possível - preferindo hibernar enquanto estiver indo de um lugar para outro. Ultimamente, porém, notei um comportamento estranho associado à deshibernação: quando o sistema iria deshibernar, ele trazia a proteção de tela do gnome com a senha necessária para desbloquear - bem, ela não reconheceria minha senha! Eu tive que alt-F1, logar como root e matar o protetor de tela. Então tudo ficaria bem, ou assim parecia. Além disso, após a desibinização, eu via freqüentemente por um curto período de tempo, piscando o lixo colorido na tela. Ele iria embora, então eu não tentei encontrar a causa. Outro ponto possivelmente relevante é que eu precisei usar o "nomodeset" na instalação do 10.04, e ao trazer o shell de resgate desse mesmo CD, se eu usar apenas o nomodeset ele eventualmente irá travar com um LED NumLock ou Caps Lock LED piscando ( crash?), mas se eu também usar "noapic nolapic acpi = off", então ele aparece ok. Eu tentei essas opções com o meu sistema para ver se eles curam o problema de travamento de inicialização - eles não o fazem.

Esta é uma máquina que eu uso para o trabalho, bem como para quase todo o resto, então fazer com que ela inicialize novamente é uma prioridade TOP . / home está intacto, o que é bom. Mas estou no meu ponto final tentando diagnosticar (muito menos consertar) essa causa do boot pendurado.

Eu inicializo o sistema e ele começa a executar o script mountall config em /etc/init/mountall.conf. Eu vejo a saída do mountall executando fsck - 4 linhas que dizem: fsck do util-linux-ng 2.17.2 (é um por partição ext4). Depois, há 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 chaves alt-sysreq, mas elas ainda não provaram ser úteis. Eu vi um relatório de bug onde um usuário usava o alt-sysreq-i para matar o processo e ele o colocava em um shell. Para mim, ele diz que matou processos (udev e udev-bridge e plymouth, diz seu respawning udev, etc), mas eu não recebo nenhum shell.

Eu tenho tentado determinar o que exatamente está pendurado. Para este fim, eu mexi com o /etc/init/mountall.conf. Eu adicionei linhas de eco e adicionei a opção -v (verbose) ao exec de mountall. Nenhuma linha de eco depois que o exec de mountall é mostrado, então isso pode significar que mountall está travando. Ou pode não estar exibindo a última saída - nesse caso, o mountall pode ter saído e outra coisa pode estar pendente. Eu notei que alt-sysreq-i não diz que mountall é morto. Eu tentei restringir o que o sistema pode estar pendurado comentando sda3 (/ home), swap e sdb1 (/ hdb) de fstab, mas ainda trava.

Há muito o que eu posso fazer, mas sinto que estou em cima da minha cabeça aqui.Eu gostaria de, por exemplo, pegar o código-fonte para mountall, adicionar flags impressos, recompilar e colocar no meu sistema - para diminuir A) se o mountall estiver pendurado, e B) o que está pendurado. MAS, eu não consigo inicializar a minha máquina para um shell a partir do qual compilar dentro - e o ambiente de disco de resgate é apenas 2.6.32-28-genérico # 55 - por isso não iria coincidir com o meu sistema. Gostaria de remover ou reinstalar os 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 vou anexá-lo em uma caixa de diálogo a seguir)

Obrigado Greg

    
por Greg 09.07.2011 / 08:41

1 resposta

1

Denwerko: Eu não fiz nada para a minha máquina que deveria ter produzido este resultado. Foi bastante estável no Ubuntu 9.10 - nunca aconteceu nada assim. Todos os mexer com a fonte, recompilar as coisas - tudo foi código do espaço do usuário. Eu não tenho mexido em tudo com o sistema operacional. Também não instalei nenhum código de espaço do SO fora dos canais padrão (aptitude / synaptic package manager, pacotes deb obtidos através dessas ferramentas). Greg ontem

No entanto, eu obtive o código fonte para mountall 2.15.3 e consegui compilar no ambiente de recuperação, após 5 instalações (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth -dev). Eu adicionei depuração de impressões no código através de chamadas nih_info (), e eu fiz os spawns que executam o fsck bloqueando em vez de não bloquear. Estou trabalhando na teoria de que o mountall está falhando em algum lugar (ou nih, ou dbus ou plymouth ...). Eu não pareço obter saída para o mesmo lugar no código de cada execução, mas parece parar algum tempo após a remontagem de / dev / sda1 para / - na rotina mounted (). Greg ontem

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

ATUALIZAÇÃO: Parece que o mountall está pendurado dentro da rotina emit_event (), que ele chama depois de / é remontado para emitir e evento para esse efeito. Dentro de emit_event, ele chama ply_boot_client_flush (), então constrói o array env, chama upstart_emit_event (), depois dbus_pending_call_block (). E aí está trancado. Então, alguma idéia de porque o dbus_pending_call_block seria pendurado indefinidamente? Plymouth quebrado? dbus? arrogante Alguma sugestão para correções ou diagnósticos adicionais?

SOLUÇÃO Então, parece que eu instalei o cloud-init e o cloud-utils porque acho que algum dia eu gostaria de brincar com ele. Will, apaga os parafusos cloud-init com a configuração ureadahead, e lança quando o evento dbus 'montado /' acontece, o que fez com que o meu sistema travasse assim que enviava aquela mensagem dbus, que acontece depois de / remontada de ro para r / w. Eu desinstalei o cloud-init e o cloud-utils e tudo parece bem agora. Exceto, estou com sono e perdi 24 horas da minha vida: \

    
por Greg 11.07.2011 / 12:17