Le démarrage après l’échec de l’installation de 14.04 en raison de l’absence de / tmp
Nous avons une installation d’Ubuntu (anciennement 12.04) à l’échelle de l’institution, installée à partir du réseau et utilisant une configuration d’installateur personnalisée pour la sélection des packages nécessaires et la configuration de l’authentification LDAP. En dehors de cela, c'est un Ubuntu normal.
Nous essayons maintenant de configurer cette procédure d'installation pour 14.04. Nous pouvons installer avec notre configuration à partir du réseau, mais le premier démarrage échoue avec le message que /tmp n'est pas disponible. La machine ne répond à aucune pression sur une touche à ce moment (je ne peux donc pas ignorer ni effectuer de récupération manuelle). Le processus de démarrage est également extrêmement lent (plus d’une minute avant que le message à propos de/tmp s’affiche).
J'ai trouvé un travail qui aide. Après l'installation, je dois démarrer en mode de récupération une fois. Dans le menu de récupération, je dois sélectionner network (qui monte des partitions et configure le réseau), puis resume. Maintenant, le système démarre correctement et tout démarrage ultérieur (également sans mode de récupération) le permet également. Donc, aucune réparation manuelle n'est faite, juste un peu comment "spécial" démarrer une fois.
Si je saute l'étape network du menu de récupération et que je vais directement à resume, cela ne fonctionnera pas. Si je redémarre immédiatement après l'étape network (sans passer à resume), cela ne fonctionne pas non plus.
Je l'ai fait manuellement une fois et je suis entré dans un shell racine à partir du menu de récupération. Tout se présentait bien à ce moment-là (à la fois avant et après l'exécution des étapes network.).
J'ai différé /etc et /var avant et après l'exécution de l'étape network, et il n'y avait pas de grande différence (uniquement les baux DHCP et les journaux dans /var comme prévu).
Ma question est la suivante: que se passe-t-il lors de ce démarrage et qui diffère d'un démarrage normal? Je suppose qu’au premier démarrage, il reste quelques tâches d’installation à effectuer et que celles-ci ne fonctionnent pas avec un démarrage normal, mais que pourraient-elles être? Peut-être que l'exécution manuelle de l'étape network du menu de récupération modifie l'ordre de certaines choses et que cela résout le problème?
Puis-je résoudre ces problèmes à la fin de l'installation avant le premier démarrage (nous exécutons quand même un script à ce stade) pour que tout fonctionne correctement?
Comment puis-je résoudre ces problèmes et vous fournir plus d'informations pour vous aider? Quel fichier pourrait changer pendant le démarrage et pourrait être intéressant? Je peux reproduire à la fois le problème et la solution de contournement afin de pouvoir fournir autant d'informations que nécessaire.
Nos ajustements à l’échelle du site n’affectent que l’authentification LDAP et les répertoires de départ NFS, pas le processus de démarrage ni le partitionnement. Lors de l'installation, une partition racine (ext4) est créée et une partition de swap, pas d'autres partitions. Ceci est un démarrage hérité (pas d'UEFI).
Edit: Je l'ai débogué un peu plus loin. Après l'installation, je dois effectuer les étapes suivantes une fois pour:
- démarrer en mode de récupération et démarrer un shell racine
- lancer
mountall - lancer
ifup -a
Après cela, tout fonctionne bien. Les trois étapes prennent beaucoup plus de temps que prévu (environ une minute chacune). Une fois l'opération terminée, le démarrage ne prend que quelques secondes (la machine est équipée d'un SSD).
Après un examen minutieux des différences entre les répertoires /etc sur un système en fonctionnement et un système défaillant, j'ai trouvé la solution.
Le problème est une ligne manquante nss_initgroups_ignoreusers dans /etc/ldap.conf. Cette ligne répertorie tous les utilisateurs locaux et empêche le système d'accéder à l'annuaire LDAP lors de la recherche de ces utilisateurs. Cette ligne est créée automatiquement à chaque démarrage par /usr/sbin/nssldap-update-ignoreusers, mais avec ma méthode d'installation, elle était manquante lors du premier démarrage. Ainsi, lors de ce premier démarrage, le système essayait de rechercher les informations utilisateur à partir de LDAP avant que la connexion réseau ne soit établie. Bien sûr, cela a échoué.
J'ai maintenant ajouté un appel à /usr/sbin/nssldap-update-ignoreusers à notre script qui s'exécute entre l'installation et le premier démarrage, et maintenant tout fonctionne correctement.