Besoin d'un petit coup de main en #adminsys : 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 ? 😅
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)
Je progresse… enfin je crois 😅
Je regarde là : https://raspberrypi.stackexchange.com/a/106884
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…
Apparemment y'a bien besoin d'une partition /boot plus large… https://seven1m.sdf.org/tutorials/upgrade_raspberry_pi_3_to_4_with_same_sd_card.html
@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 enlarge your /boot!
@duponin https://mamot.fr/@Lapineige/105584702720751256, pas encore réussi à le mettre en place, ni trop eu le temps
@dfgweb c'est vide 😅
@dfgweb qu'est-ce que ça m'apprend du coup ?
@dfgweb strace ne donne que : "wait4(-1," :(
@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 vide
@dfgweb le kill ne fonctionne pas 😅
@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
@dfgweb oui
@dfgweb impossible à tuer, en cherchant (là https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work), 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" 🤨 😆
@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 ?
@dfgweb je ne comprends rien à cette page 😅
@dfgweb y'a que deux processus en cours (pour dpkg, un parent un enfant), pareil pour les deux.
@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
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 ?