Erreurs fréquentes

Problèmes connus lors de la construction des images pour Ubuntu Touch

Certains problèmes connus que vous pouvez rencontrer lors de la construction des images de démarrage et du système sont décrits dans le guide du portage d’Halium.

Problèmes connus avec le démarrage initial

Voici quelques-uns des problèmes connus que vous pourriez rencontrer lors du processus de démarrage initial.

SSH se suspend lors de la tentative de connexion

La connexion SSH peut se suspendre indéfiniment au moment de la tentative de connexion. Les efforts pour arrêter la connexion avec Contrôle C peuvent ou non vous renvoyer une invite de commande. Si vous exécutez ssh -vvvv phablet@10.15.19.82, vous obtenez seulement la sortie suivante avant que le programme ne s’arrête:

debug1: Connecting to 10.15.19.82 [10.15.19.82] port 22.
debug1: Connection established.
[...]
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH[...]

Cela semble être une erreur fréquente sur les appareils arm64 avec le noyau 3.10 lorsque rsyslogd est activé. Si vous avez cette erreur, ajoutez votre voix à ubports/ubuntu-touch#560 puis tentez le palliatif suivant :

  1. Redémarrez votre appareil en mode récupération (recovery) et connectez-vous-y avec adb shell

  2. Lancez la commande suivante pour désactiver rsyslogd:

    mkdir /a
    mount /data/rootfs.img /a
    echo manual |tee /a/etc/init/rsyslog.override
    umount /a
    sync
    

Vous pouvez maintenant redémarrer l’appareil. Vous devriez être capable de le connecter en SSH dès son retour en ligne.

L’appareil redémarre après une minute

L’appareil peut redémarrer proprement après environ une minute de disponibilité. Si vous êtes connecté(e) lorsque le redémarrage se produit, vous verrez le message suivant:

Broadcast message from root@ubuntu-phablet
    (unknown) at 16:00 ...

The system is going down for reboot NOW!

Ceci se produit car lightdm, le gestionnaire d’affichage d’Ubuntu Touch, plante à plusieurs reprises. Le processus de surveillance du système voit cela et redémarre l’appareil.

Pour régler le problème, connectez-vous avant que le redémarrage ne survienne et lancez la commande suivante:

sudo stop lightdm

Problèmes connus lors de la mise en place d’Unity 8

Vous trouverez ci-dessous quelques éléments à vérifier si vous avez du mal à mettre en place Unity 8.

Rien n’apparait à l’écran

Si rien ne s’affiche à l’écran même après l’ajout de règles udev à votre portage, il est probable que vous ayez un problème avec le plantage d’applications graphiques. Cela peut provenir du plantage des serveurs de Mir.

Les plantages des serveurs de Mir peuvent provenir de nombreux problèmes différents lors du portage. Pour trouver une solution, vous pouvez essayer la chose suivante :

Est-ce que le conteneur d’Android est en cours de fonctionnement ?

Si le conteneur d’Android n’est pas en cours de fonctionnement, de nombreuses parties d’Ubuntu Touch ne fonctionneront pas. Exécutez cette commande pour vérifier le statut des conteneurs:

sudo lxc-info -n android

Si vous obtenez une sortie similaire à la suivante, le conteneur d’Android est en cours de fonctionnement et vous pouvez passer à l’étape suivante des investigations:

Name:           android
State:          RUNNING
PID:            1194
IP:             10.15.19.82

Si vous n’obtenez pas State: RUNNING, c’est que le conteneur est arrêté. Vous pouvez exécuter la commande sudo start lxc-android-config pour essayer de le démarrer. Si le conteneur ne démarre pas après cela, vous pouvez exécuter la commande sudo lxc-start -n android -F pour obtenir un rapport plus détaillé sur la cause de cet échec.

Est-ce que toutes les partitions d’Android sont montées ?

Si des partitions utilisées pour les lecteurs Android ne sont pas montées, le conteneur peut démarrer mais ne pas fonctionner correctement.

Pour vérifier les partitions montées d’Android, exécutez ls /android. Les dossiers suivants devraient au moins se trouver à l’intérieur:

data
system
firmware
persist

Si l’un d’entre eux est manquant, exécutez la commande dmesg pour obtenir le journal du noyau. Le montage de partitions d’Android démarrera après la ligne suivante:

initrd: checking fstab [...] for additional mount points

Essayez de diagnostiquer et de réparer toutes les erreurs de montage que vous trouverez dans le journal pour les partitions listées ci-dessus.

Note

Certains appareils disposent d’une partition ``vendor``qui contient des bibliothèques et des exécutables propriétaires nécessaires au fonctionnement d’Android. Si votre appareil contient cette partition, assurez-vous qu’elle soit montée en plus de toutes les autres listées ci-dessus.

Obtenir plus de journaux de Mir

Si le conteneur d’Android tourne et que toutes ses partitions semblent montées, vous devrez obtenir quelques journaux supplémentaires avant de solliciter l’aide de la communauté.

Tout d’abord, arrêtez le gestionnaire d’affichage si cela n’est pas déjà fait:

sudo stop lightdm

Si le Wi-Fi fonctionne (Voir la documentation d’Halium sur le Wi-Fi), installez d’abord le paquet libc6-dbg:

sudo apt update
sudo apt install libc6-dbg

Exécutez ensuite les commandes suivantes pour obtenir tous les journaux nécessaires:

sudo unity-system-compositor --debug-without-dm &> ~/usc.log
sudo gdb -ex 'set confirm off' -ex 'run' -ex 'bt full' -ex quit --args unity-system-compositor --debug-without-dm &> ~/usc-gdb.log
sudo /system/bin/logcat -d &> ~/usc-logcat.log

Utilisez scp ou un programme similaire pour copier les fichiers usc.log, usc-gdb.log et usc-logcat.log à partir du dossier personnel « phablet » vers votre ordinateur. Postez ensuite le contenu de ces fichiers dans paste.ubuntu.com, Pastebin, GitHub Gists ou un service similaire de manière à ce que les personnes qui vous aident puissent les voir facilement.

Les programmes se suspendent avant de planter

Les processus se mettent parfois en suspend pendant un long moment avant de s’interrompre ou de renvoyer une erreur de segmentation. La raison de la suspension vient d’Apport, qui tente de collecter des informations à propos du plantage avant d’autoriser le programme à s’arrêter.

Si vous n’avez pas besoin des informations d’Apport et préférez que le programme plante plus rapidement lors des investigations, exécutez la commande suivante:

sudo stop apport
sudo stop whoopsie

Activer /var/log/syslog

Normalement, l’écriture dans les journaux du système est désactivée. Pendant le portage, il peut être utile d’activer ceci

sudo touch /var/log/syslog
sudo chown syslog:syslog /var/log/syslog
sudo initctl stop rsyslog
sudo initctl start rsyslog

Désormais, rsyslogd va écrire dans le fichier et vous pourrez l’utiliser comme d’habitude. Par exemple less /var/log/syslog ou tail -f /var/log/syslog.

Problèmes connus lors de la configuration de l’appareil

Plantage des applications au démarrage

Vérifiez si la vibration du clavier fonctionne. Si ce n’est pas le cas, c’est une bonne indication que vous n’avez pas correctement appliqué les correctifs Apparmor au noyau.

Référez-vous à la section Appliquer les correctifs Apparmor au noyau.

Cette section est un travail en cours