Le redémarrage se bloque à 100% - peut-être dans mountall

MISE À JOUR: Il semble que mountall soit suspendu à l'intérieur de la routine emit_event (), qu'il appelle après / est remonté pour émettre un événement à cet effet. Dans emit_event, il appelle ply_boot_client_flush (), puis construit le tableau env, appelle upstart_emit_event (), puis dbus_pending_call_block (). Et là, ça se bloque. Donc, des idées pourquoi dbus_pending_call_block se bloquerait indéfiniment? Plymouth cassé? dbus? parvenu? Des suggestions de correctifs ou de diagnostics supplémentaires?

Le redémarrage de ma machine Ubuntu 10.04 LTS, 64 bits AMD se bloque à 100%. Le voyant d'accès au lecteur est éteint, mais les touches alt-sysreq fonctionnent. Le matériel est un ordinateur portable Lenovo W700ds. Maintenant, je m'excuse à l'avance, car je suis très limité dans les informations sur le système dont je dispose et dans ce que je peux en faire (car il ne démarre pas). Je peux démarrer à partir du CD 10.04 - en l'utilisant comme un disque de secours. Je peux fsck, monter et lire et écrire sur mes partitions - elles sont très bien. J'ai déjà essayé de reformater mon swap avec mkswap. J'ai 4 partitions ext4 sur mon système: sda1 est /, sda2 est / usr, sda3 est / home, et une quatrième que j'utilise pour le stockage de données / sdb1 (est le disque entier, se monte au point de montage / hdb que j'ai créé) . Il y a aussi / sda4 qui est swap. En ce moment, j'écris ceci à partir d'un navigateur que j'ai ouvert dans la «session de sauvetage» du 10.

J'apprécierais grandement les suggestions / commentaires sur ce que je pourrais faire pour aider à diagnostiquer ce qui pend, pourquoi et ce que je pourrais faire pour le réparer. J'ai déjà fait une recherche sur le Web, mais je n'ai rien trouvé de nouveau dans ce sens (certains rapports de bogues de 1-1,5 ans avec des symptômes similaires, mais leurs correctifs n'ont pas fonctionné).

J'ai installé 10.04 sur un nouveau disque vers le 1er juillet, puis utilisé aptitude pour tout mettre à jour. Depuis lors, j'installe LOTSdes packages (je vais joindre le journal dpkg ci-dessous). Avec sda étant de 750 Go (/ 20 Go, / usr 80 Go), j'avais beaucoup d'espace pour installer des packages que je «pourrais un jour utiliser». Je me demande si c'est l'un de ces packages que j'ai installé qui a foiré mon système? J'ai installé le noyau 2.6.32-32-generic et redémarré, mais j'ai installé de nombreux autres packages depuis. Je redémarre ces machines aussi rarement que possible - préférant l'hiberner en allant d'un endroit à l'autre. Dernièrement cependant, j'ai remarqué un comportement étrange associé à la déshibernation: lorsque le système déshibernait, il affiche l'économiseur d'écran gnome avec le mot de passe nécessaire pour déverrouiller - eh bien, il ne reconnaîtrait pas mon mot de passe! J'ai dû alt-F1, me connecter en tant que root et tuer l'économiseur d'écran. Alors tout irait bien, du moins il semblait. Aussi, lors de la déshibernation, je voyais fréquemment pendant un court instant des déchets colorés à l'écran. Cela disparaîtrait, donc je n'ai pas essayé de trouver la cause. Un autre point peut-être pertinent est que j'avais besoin d'utiliser "nomodeset" dans l'installation de 10.04, et lorsque je lance le shell de secours à partir de ce même CD, si j'utilise uniquement nomodeset, il finira par se bloquer avec une LED NumLock clignotante ou une LED de verrouillage des majuscules ( crash?), mais si j'utilise aussi "noapic nolapic acpi = off" alors ça revient ok. J'ai essayé ces options avec mon système pour voir si elles résolvent le problème de blocage de démarrage - elles ne le font pas. si j'utilise uniquement le nomodeset, il finira par se bloquer avec une LED NumLock clignotante ou une LED de verrouillage des majuscules (crash?), mais si j'utilise également "noapic nolapic acpi = off", cela se passera bien. J'ai essayé ces options avec mon système pour voir si elles résolvent le problème de blocage de démarrage - elles ne le font pas. si j'utilise uniquement le nomodeset, il finira par se bloquer avec une LED NumLock clignotante ou une LED de verrouillage des majuscules (crash?), mais si j'utilise également "noapic nolapic acpi = off", cela se passera bien. J'ai essayé ces options avec mon système pour voir si elles résolvent le problème de blocage de démarrage - elles ne le font pas.

C'est une machine que j'utilise pour le travail, ainsi que pour presque tout le reste, ce qui en rend à rebooter est un TOP priorité. / home est intact, ce qui est bien. Mais je suis sur le point de tenter de diagnostiquer (et encore moins de corriger) cette cause du démarrage bloqué.

Je démarre le système et il commence à exécuter le script de configuration mountall dans /etc/init/mountall.conf. Je vois la sortie de mountall exécutant fsck - 4 lignes qui disent: fsck de util-linux-ng 2.17.2 (c'est un par partition ext4). Ensuite, il y a 4 autres lignes de fsck informant l'utilisateur que les partitions ont été jugées "propres". Et c'est tout - tout s'arrête. Le voyant d'activité du lecteur s'éteint. Je peux utiliser les touches alt-sysreq, mais elles n'ont jusqu'à présent pas été utiles. J'ai vu un rapport de bogue où un utilisateur a utilisé alt-sysreq-i pour tuer le processus et il l'a laissé tomber dans un shell. Pour moi, il dit qu'il a tué des processus (udev et udev-bridge et plymouth, dit son réapparition udev, etc.), mais je ne reçois aucun shell.

J'ai essayé de déterminer ce qui pend exactement. À cette fin, j'ai bricolé avec /etc/init/mountall.conf. J'ai ajouté des lignes d'écho et j'ai ajouté l'option -v (verbose) à l'exec de mountall. Aucune ligne d'écho après l'exécution de mountall n'est affichée, cela peut donc signifier que mountall est suspendu. Ou, il peut ne pas afficher la dernière sortie - dans ce cas, mountall peut être sorti et quelque chose d'autre peut être suspendu. Je note que alt-sysreq-i ne dit pas que mountall est tué. J'ai essayé de préciser ce que le système pourrait accrocher en commentant sda3 (/ home), swap et sdb1 (/ hdb) de fstab, mais il se bloque toujours.

Il y a beaucoup que je peux faire moi-même, mais j'ai l'impression d'être au-dessus de ma tête ici. Je voudrais, par exemple, obtenir le code source de mountall, ajouter des drapeaux imprimés, recompiler et le coller sur mon système - pour affiner A) si mountall se bloque réellement, et B) à quoi se bloque-t-il. MAIS, je ne peux pas démarrer ma machine sur un shell à partir duquel compiler - et l'environnement du disque de secours n'est que 2.6.32-28-générique # 55 - donc il ne correspondrait pas à mon système. Je voudrais supprimer ou réinstaller des packages, mais encore une fois, je ne peux pas démarrer ma machine et faire cela.

(mon fichier journal dpkg fait plusieurs Mo, je le joindrai donc dans une boîte de dialogue suivante)

Merci, Greg

Denwerko: Je n'ai rien fait à ma machine qui aurait dû produire ce résultat. Il était assez stable sous Ubuntu 9.10 - il ne s'est jamais rien passé de tel. Tout le bricolage avec la source, la recompilation des choses - tout cela a été du code d'espace utilisateur. Je n'ai pas du tout bricolé avec l'OS. Je n'ai pas non plus installé de code d'espace OS en dehors des canaux standard (gestionnaire de paquets aptitude / synaptic, paquets deb obtenus grâce à ces outils). Greg hier

Cependant, j'ai obtenu le code source de mountall 2.15.3 et l'ai compilé dans l'environnement de secours, après 5 installations (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) . J'ai ajouté des impressions de débogage dans le code via des appels nih_info (), et j'ai créé les spawns qui exécutent le blocage fsck au lieu du non-blocage. Je travaille sur la théorie que mountall plante quelque part (ou nih, ou dbus ou plymouth ...). Je ne semble pas obtenir la sortie au même endroit dans le code à chaque exécution, mais cela semble s'arrêter quelque temps après le remontage de / dev / sda1 vers / - dans la routine mount (). Greg hier

J'ai également fait dpkg -r de paquets via chroot comme vous l'avez suggéré, et cela semble fonctionner (sauf pour un script de désinstallation qui voulait faire quelque chose avec / proc). J'ai désinstallé wine et les packages de compatibilité 32 bits dont il avait besoin (lib32nss, ia32lib, lib32v4l, etc.) et plusieurs packages ibus qui ne sont pas installés dans l'environnement de secours (certains packages ibus le sont, et j'ai pris soin de ne pas les supprimer). plasma-widget-kimpanel-backend-ibus, ibus-qt4, ibus-qt1. Rien de tout cela n'a affecté le problème, j'ai donc supprimé plus de packages dont je n'ai pas besoin maintenant (widgets wx et packages jdk, etc.) -aucun effet

MISE À JOUR: Il semble que mountall soit suspendu à l'intérieur de la routine emit_event (), qu'il appelle après / est remonté pour émettre et événement à cet effet. Dans emit_event, il appelle ply_boot_client_flush (), puis construit le tableau env, appelle upstart_emit_event (), puis dbus_pending_call_block (). Et là, ça se bloque. Donc, des idées pourquoi dbus_pending_call_block se bloquerait indéfiniment? Plymouth cassé? dbus? parvenu? Des suggestions de correctifs ou de diagnostics supplémentaires?

SOLUTION Donc, il semble que j'aie installé cloud-init et cloud-utils parce que je pensais qu'un jour je pourrais vouloir jouer avec. Will, tourne des vis d'initialisation cloud avec la configuration ureadahead et se lance lorsque l'événement dbus `` monté / '' se produit, ce qui a entraîné le blocage de mon système dès qu'il a envoyé ce message dbus, qui se produit après que / est remonté de ro vers r / w. J'ai désinstallé cloud-init et cloud-utils et tout semble ok maintenant. Sauf que j'ai sommeil et j'ai perdu 24 heures de ma vie: \