Follow

Besoin d'un petit coup de main en : je fais une mise à jour des paquets sur un raspberry pi 4, il reste bloqué depuis très longtemps sur cette étape:

>Paramétrage de raspberrypi-kernel (1.20210104-1) ...
>Suppression de « détournement de /boot/kernel8.img en /usr/share/rpikernelhack/kernel8.img par rpikernelhack »

Htop me dit que y'a zéro calcul en cours (mais un load à 7, contre 1 avant).

Que faire ? 😅

Donc cela fait maintenant 3 jours que ça tourne, toujours à 100% d'un CPU, mais 100% de wait (et un load à 7 au lieu de 6). Manifestement le processus n'avance pas et ne modifie pas les fichiers en question…
J'imagine que ça touche la partition /boot ?

Comment faire pour diagnostiquer à quelle étape ça coince ?

À défaut de mieux, vu que ça n'a pas l'air de réussir (à écrire sur la carte ?) est-ce qu'il possible d'annuler la mise à jour et de revenir à la version précédente ?

Vu que c'est sur le noyau, et que j'ai très peur de ne pas pouvoir démarrer ensuite, je préfère y aller doucement…

Non mais c'est une blague cette mise à jour…

Suite aux discussions (voir sous le reste du fil), j'ai récupéré une carte SD neuve, réinstallé une ancienne sauvegarde, je lance la mise à jour… et ça reste à nouveau bloqué là :
>Paramétrage de raspberrypi-kernel (1.20210108-1) ...
>Suppression de « détournement de /boot/kernel.img en /usr/share/rpikernelhack/kernel.img par rpikernelhack »

(pas la même version que la dernière fois donc, elle est plus à jour)

Pourrait-il y avoir un rapport avec le fait que le système vient d'un raspberry pi 3, que j'ai mis à jour (sous Debian Buster) puis migré sur le raspberry pi 4 ?

Un problème de noyau qui se mettrait mal à jour ?

Je vais restaurer la sauvegarde, que puis-je faire pour diagnostiquer et corriger ce problème de mise à jour ?

Ou à défaut, comment empêcher la mise à jour du noyau (et à quel point ça peut tout casser ?)

Je progresse… enfin je crois 😅

Je regarde là : raspberrypi.stackexchange.com/
Et il semblerait que si on manque de place sur /boot, le noyau complet n'est pas installé, enfin en gros il manque un truc pour supporter le raspberry pi 4.
J'ai vu conseillé 500Mo, parfois 250Mo…

En l’occurrence ma partition fait 250Mo, et 50Mo d'utilisés au départ.
Et quand je fais la mise à jour… il vide /boot, et installe les nouveaux paquets… Et reste bloqué là:

>Paramétrage de raspberrypi-kernel (1.20210108-1) ...
>Suppression de « détournement de /boot/kernel.img en /usr/share/rpikernelhack/kernel.img par rpikernelhack »

Ceci explique donc pourquoi un redémarrage foire, mais pas pourquoi il reste bloqué alors que /boot a encore 245Mo de libre…

@Lapineige
À tout hasard, tu as `iotop` d'installé ? Une charge importante ça peut être à cause des accès "disque".

@pipoprods ah c'est juste, je regardais juste les I/O dans htop (zéro), mais en fait j'ai un wait à ~100% sur un cœur…
Je suppose que la carte SD rame, mais ça fait 2h…

@Lapineige
À ta place, si je n'étais pas pressé, je laisserais tourner la nuit et on verra.
Si j'étais pressé, je ferais un ^C, je relancerais la mise à jour et vu que tout serait cassé, je passerais la nuit à réparer 😂
Je suis bien content de pas être à ta place 😁

@pipoprods en l’occurrence j'ai déjà coupé la première fois, car… ma connexion a sauté.
Ça a l'air d'avoir repris sans problème… j'ai juste peur d'un potentiel redémarrage intempestif 😅
(ce coup-ci ça tourne dans un tmux)

@Lapineige
Oui, toujours utiliser tmux ou screen, sur les machines distantes. Ça m'a sauvé plus d'une fois.
Bonne chance 😉

@Lapineige le "load" affiche le nombre moyen de processus en attentes.
Ils peuvent attendre toutes sortes de ressources : CPU, mémoire, disque, lock...
Il faut donc trouver ce qui bloque.
La commande htop permet de voir la consommation CPU, iotop les accès aux disques. Pour les autres ressources ils faut creuser un peu plus.

@Lapineige Tu lances Htop, tu vas sur le process en cours et tu appuies sur s pour faire un strace.

La suite après l'arrivée des infos :)

@dada merci, je ne connaissais pas :)

J'ai juste un
"wait4(-1,"

@dada
strace dans htop... Le genre de chose qui te simplifie la vie quand tu les découvres... Tu viens de simplifier ma vie future 😀 (OK j'ai quelques jours de retard...)
@Lapineige

@Lapineige euh rpi 3 n'est pas compatible rpi 4
Pas le même proc, hardware différent.... Bref...

Et je me suis amusé à upgrade une debian sur un rpi 3 -> l upgrade est passée en bousillant tout (retrait de paquet car plus présent en arm buster, etc)
Reinstall de buster sur un rpi 3 : ok
(Chhuuut oui j ai une debian arm... Mais mes deux archlinuxarm sont un charme à côté de ça ;))

Par contre une SD d un rpi 3 b dans un rpi b+ : la ca marche (avec un petit apt-get update/upgrade)

@lucius jusque là le passage du raspberry pi 1 au 2 puis du 2 au 3 n'a jamais posé problème... Le noyau a toujours géré (mise à jour comprises).

La mise à jour vers buster de raspian sur le raspberry 3 (d'un yunohost en plus) n'a pas posé de problème, c'était transparent.

@Lapineige woot, chaud qd meme vu les changements au fil du temps...

Bah moi un simple upgrade + dist-upgrade a destroy l os...
Genre j avais mariadb qui tournait... Bah plus de paquet installé... Mais les fichiers présents (mais corrumpus... Gné)
==> je suis reparti d une fresh install et depuis ca va ;)

Du coup, pas sur que ton souci soit pas lié "juste" à l upgrade... :(

Have fun en tout cas

@Lapineige tant que l'entrée du bootloader n'est pas modifiée pour démarrer sur le nouveau noyau tu n'as pas de risque
(C'est normalement fait en dernier)

As-tu trouvé une solution/réponse ?
que l'appli n'est pas bloqué dans le kernel sur une opération. donc c'est plutot coté userspace qu'il faut regarder. (strace comme déjà dit ou carrément GDB si tu as les symbols du programme)
@Lapineige et donc celle là aussi:
https://man7.org/linux/man-pages/man2/waitpid.2.html
le problème se situe donc dans les child process de celui qui appelle cette fonction

@dfgweb ok merci. Tu sais comment on trouve les childprocess ?

@dfgweb ok merci. Et bien le seul processus en dessous, c'est "sync". Un strace ne renvoie rien.

@dfgweb j'ai 8 processus sync (d'origines différentes) qui bloquent 😅

@dfgweb
Ah en fait je m'étais trompé de processus. Le strace donne:
> strace : attach: ptrace(PTRACE_SEIZE, 13127): Opération non permise

Show newer

@dfgweb impossible à tuer, en cherchant (là unix.stackexchange.com/questio), il sont marqué en D, donc j'ai plus qu'à rebooter si je veux les couper…

@dfgweb en dernière chance, j'ai essayé de redémarrer…
Il reste bloqué par les X processus "sync" 🤨 😆

Show newer
@Lapineige si c'est le sync qui bloque, c'est que le systeme n'arrive pas à écrire sur le disque

@dfgweb ok, donc c'est bien ça… et c'est très embêtant :(

Tu sais si on peut identifier à quel endroit il essaye d'écrire ?
Parce que typiquement je peux créer un fichier.
Peut-être que c'est /boot, vu que c'est le noyau ?

@Lapineige check l'espace disque de toutes les partitions et fait le ménage si l'une est trop pleine

@dfgweb y'a que deux processus en cours (pour dpkg, un parent un enfant), pareil pour les deux.

@Lapineige

Un problème d'écriture sur la carte SD ?

Je suppose que tu as cherché un peu (je ne sais pas si c'est en rapport)… :
https://www.raspberrypi.org/forums/viewtopic.php?t=285915

@gerald ça me surprendrait vu qu'elle est quasi-neuve :(
(et que je viens de changer depuis une carte défectueuse)

@Lapineige
Oh tu sais, avec les cartes SD, ça peut être la loterie. Perso, je ferais jouer la garantie si elle est neuve.
@gerald

@Lapineige bah j'avais pas vu le context. à mon avis ta carte SD est morte!
Sign in to participate in the conversation
La Quadrature du Net - Mastodon - Media Fédéré

Mamot.fr est une serveur Mastodon francophone, géré par La Quadrature du Net.