[Kernel] Boot impossible, /lib vidé par erreur (résolu)

[faya]

Bonjour,

Voici la triste histoire d'un laptop "brické" par un chaud samedi matin.
N'ayant pas réalisé de mise à jour de mon pc depuis 8 mois pour cause de voyage, je me suis retrouvé ce matin avec le problème bien connu de :

Code : Tout sélectionner

glibc: /lib exists in filesystem

La résolution est connue et aisée, j'ai suivi sagement la méthode proposée ici :
https://wiki.archlinux.org/index.php/De ... iki:usrlib

Le fichier /lib/ld-linux.so.2 appartenant à lib32-glibc était en cause. Je l'ai donc sauvegardé sous /root/backup ainsi que le dossier /lib/modules et toutes les autres librairies. Ensuite j'ai malencontreusement vidé le dossier /lib et me suis retrouvé avec un système inutilisable (impossible d'ouvrir un terminal ni même de reboot !)

J'ai donc eu la mauvaise idée de faire un hard reboot en me disant que j'utiliserais ma live USB pour remettre toutes les librairies à leur place (ainsi que le dossier modules). Mais une fois la restauration du contenu de /lib, impossible d'aller plus loin que le GRUB. Le système ne trouve pas ma partition racine (/dev/sda5) et il n'existe même pas de /dev/sdX.

Je compris alors qu'en suivant la page ci-dessus j'avais déjà installé le nouveau noyau mais sans faire de "mkinitcpio -p linux" puisque je n'avais pas eu le temps de finir l'update de la glibc.
Je suppose donc que j'ai un noyau installé sans aucun de ses modules ... d'ou les partitions non trouvées ?

Y a-t-il un moyen (chroot depuis la live USB ?) de downgrader mon noyau pour revenir au précédent et réaliser un boot normal et finir l'update de la GlibC ? Ou je suis bon pour une réinstallation from scratch ?

J'espère avoir été clair et vous remercie d'avance pour votre aide

[benjarobin]

Tu as bien compris la situation dans laquelle tu es, (aucune chose de fausse de dite apparemment).
Par contre il est tout à fait possible de mettre à jour / installer de nouveau paquet depuis un chroot.
Encore faut-il arriver à faire fonctionner le chroot... Sinon tu as l'option -r de pacman

[FoolEcho]

Tu devrais pouvoir tout réparer depuis le livecd.
Sans chroot, en montant les partitions de ton Arch (/, /boot si séparé, etc.) et en utilisant directement pacman -r /mnt -S les_machins_à_réinstaller (en supposant un montage dans /mnt ; selon ce qui est cassé ou dans le doute, tu peux réinstaller le groupe base dans son ensemble).
Et chroot pour le mkinitpcio et autres opérations si besoin.

... grillé.

[faya]

Ok je testerai une réinstallation du noyau précédent avec -r, je vous remercie.
Par contre mon liveusb date un peu (deux ans) est-ce que pacman y arrivera ou je ferais mieux d'en télécharger un (livecd) plus récent ?
Je n'ai pas accès au PC là tout de suite donc je pose la question quand même histoire de gagner du temps ...

[FoolEcho]

Tu as intérêt avec le plus récent. Et autant (ré)installer le kernel le plus neuf (à moins que tu aies un problème avec le récent en plus ).

[benjarobin]

Attention j'ai oublié de préciser l'utilisation de l'option -r de pacman n'est pas miraculeuse, elle permet juste de faire des copies de fichier...
Bref tout paquet installé avec l'option -r et s'il contient un .install doit être réinstallé depuis le chroot !!!

En gros il est conseillé lorsque l'on utilise l'option -r d'utiliser aussi l'option --noscriptlet
Comme le .install n'est pas exécuté alors il est nécessaire de relancer l'installation du paquet via le chroot.

Donc l'option -r ne doit être utiliser que pour réparer ! Par exemple le chroot qui ne fonctionne plus.
Utiliser l'option -r car on n'a pas envie de taper 4-5 commandes pour le chroot n'est pas conseillé du tout

Sinon tu doit utiliser un liveCD plus récent, la structure de la base de donnée de pacman ayant changé entre temps

[faya]

Bonjour et merci à tous, j'ai pu résoudre le problème avec un
pacman -r
pour réinstaller la glibc, puis chroot pour exécuter mkinitcpio.

\o/