Forum

Bonjour,

La dernière mise à jour effectuée hier 20 mars 2015 entraîne chez moi l'impossibilité de me connecter en utilisateur ainsi qu'en root, ce qui se résume à une utilisation de la Cauldron impossible.

Alors méfiance!!!

Plus précisément, le fstab est complètement nettoyé.
Vous pouvez effectuer la mise à jour mais être vigilant. A la fin de la mise à jour, il est proposé d'examiner le fstab.rpmnew : il faut choisir "Supprimer le rpmnew".

aucun pb ici ... j'ai bien eu un msg , j'ai cliqué sur un bouton ( il n'y avait qu'un bouton ) ...
Mon fstab est ok !

Mise à jour en ligne de commande, et pas de soucis majeurs.

le fichier a été créé en tant que .rpmnew

Le problème vient probablement de la mise à jour du paquet setup, que tu as probablement faite avec MageiaUpdate et pour laquelle tu as choisis « Utiliser le fichier .rpmnew ». Tu as donc remplacé tes fichiers /etc/fstab et /etc/shadow par les versions génériques contenues dans le paquet setup.

Il n'est pas forcément nécessaire de cliquer sur « Supprimer le .rpmnew », vous pouvez aussi choisir de n'effectuer aucune action.

En tout cas ça confirme que ce bug est critique : https://bugs.mageia.org/show_bug.cgi?id=14266

Ah ! Le malin ! Qui croyait utile d'ajouter une précision à l'alerte de Vladimir (c'est moi dont je parle bien sûr).

J'ai donc refusé le rpmnew de fstab. Mais, j'ai accepté celui de /etc/shadow...

Et bien mal m'en a pris, cet aprem, impossible de me logguer ! Les mots de passe sont refusés, le mien, celui de root. Bref, mon PC est inaccessible ! Certes, c'est la Cauldron mais quand même, bonjour la modif !

C'est d'ailleurs donc que je poste.

Bon, est-ce que (pendant que je cherche et dans la crainte de ne pas trouver) quelqu'un connaît une procédure différente de la réinstall complète ?...

Édité par magnux77 Le 21/03/2015 à 17h19

Salut,


1 -démarrer en mode rescue à partir d'un support d'installation
ou démarrer sur un live média
2 - monter la partitions / sur /tmp
3 -passer en mode console
4- mount -B /sys /mnt/sys
5 - mount -B /proc /mnt/proc
6 - mount -B /dev /mnt/dev
7 - chroot /mnt
8 - passwd

là tu essaye de changer les mots de passe de tes utilisateurs.
Si ça ne marche pas, tu peux essayer de recréer un fichier shadow, sans les mots de passe, et tu recommence.
Tiens nous au courant si ça marche.

Librement,

Et si on a fait préalablement une copie de sécurité de fstab et shadow ? Et oui, à condition d'y avoir pensé avant la catastrophe !

Edit :
Du coup et en prévention de la future migration, je viens de faire ces deux copies de sécurité sur Mageia 4 (pour la future Mageia 5 ou autre problème hypothétique) afin de pouvoir restaurer ces originaux avec un LiveCD ou en chrootant.

Édité par teutates Le 21/03/2015 à 17h46

A priori quand on utilise le .rpmnew, il fait une copie de l'ancienne version en .rpmsave (à vérifier).

Comme de bien entendu, pas moyen de remettre la main sur le DVD Beta3. Impossible de downloader M5B3 avec l'autre PC qui se vautre pour la 3ème fois parce que le file system est plein comme un œuf : la loi de l'emmerdement maximum.



Alors en attendant que se fasse le download, j'ai cherché sur ternet pour comprendre que le /etc/shadow c'était grosso modo le /etc/passwd encrypté et pour passer le temps j'ai démarré mon PC dépasswordé sur une clé USB avec SystemRescueCD, j'ai monté /dev/sda1 sur /mnt pour aller voir. Et quelle ne fut pas ma surprise de découvrir un /etc/shadow expurgé de root, systemd et mon user entre autres mais surtout de découvrir un /etc/shadow- qui contenait la version antérieure où j'ai retrouvé root et mon user. Un petit mv suivi d'un reboot et mes mots de passe retrouvés autorisent la connexion. Tout est bien qui finit bien.



@dtux : Un salut plus qu'appuyé mon vieux !



Elle est bien bonne celle-là. Je ne sais pas si le bug est critique mais la solution, elle, est franchement critiquable. Et critiquée cf ton lien.

On fait ce qu'on peut...

Je viens de faire une mise à jour, en console avec un "urpmi --auto-select" sur un autre ordinateur.

Je n'ai pas eu la question au sujet des fichiers posant problème.

La mise à jour s'est donc bien déroulée et la machine a redémarré sans problème.

Y aurait-il eu un correctif entre temps?

Non, c'est le comportement normal d'urpmi. Il ne propose pas de choisir entre l'ancien fichier et le .rpmnew, il indique simplement que ce dernier a été créé.



En revanche MageiaUpdate / rpmdrake ont cette fonctionnalité (critiquée) qui permet de choisir le .rpmnew (ou le .rpmsave pour les fichiers de config pour lequel par défaut le nouveau fichier doit remplacer l'ancien) ou de laisser les choses telles quelles. Normalement il existe une liste de fichiers tels que /etc/fstab ou /etc/shadow pour lesquels MageiaUpdate ne devrait pas poser de question (TOUJOURS garder le fichier original), mais pour une raison non encore établie ça ne marche pas comme avant.

On sait, on sait. Et c'est sur la Cauldron. Et ça ne sortira pas d'ici

C'est juste que, même une Cauldron en service réel, j'ai confiance par habitude et que, pour une fois, je me suis fait peur.

Édité par magnux77 Le 22/03/2015 à 07h50

Héhé, ce n'est pas la première fois que ce genre d'incident arrive. Je me rappelle des début de KDE4 .... Ce n'était pas triste non plus. Mageia est prudent en disant que la cauldron ne doit pas être utilisé en production... A bon entendeur salut.