Bonsoir,
Peut-être que ton problème est lié à ce bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922478&source=techstories.org
A faire confirmer car je ne suis pas un expert du kernel.
ppr
1 Like
Salut, lors d’une install party ce dimanche une personne est venue un problème similaire.
- ynh 3.3.3 dont les mise à jours venaient d’avoir été faites la veille et le boot était bien bloqué à
starting kernel. - on et reparti d’une image de sa brique en 2.7.14.5 dont on a fait la migration vers strech et le résultat fut le même.
Il y a donc de forte chance que le bug dont tu parles soit lié. En tout cas le problème semble reproductible puisqu’on l’à fait ce dimanche lors d’un simple mise à jours et lors d’une migration.
Dans notre cas on est resté sur la 2.7.14.5.
1 Like
C’est fort probable. Cependant, sur ma brique, il ne semble pas y avoir de noyau de backup numéro 4.9.0.7. Il n’y a que le 3.16.0.7. Je n’ai pas essayé la manœuvre avec ce noyau…
Si beaucoup de briques tombent en panne, il faudra peut-être prévenir les gens de ne pas faire la mise à jour avant que d’autres aient le même souci…
Avant de réinstaller une version plus ancienne, j’aimerais récupérer les emails… Et les alias emails aussi si possible. Quelqu’un sais comment faire ?
Les emails sont dans /var/mail
Pour les alias, c’est dans le ldap, malheureusement pour faire un export sans que le système tourne c’est pas simple je pense (en tout cas je sais pas faire).
1 Like
Bonsoir,
J’ai exactement le même problème sur ma brique suite à mise à jour de strech qui s’est fait correctement sur mon poste de buerau et sur mon portable mais qui a abouti à un blocage au boot sur ma brique avec message identique à la copie d’écran postée plus haut.
Comment faire pour relancer la brique avec l’ancien noyau ?
La carte SD est parfaitement lisible sur un PC.
Le répertoire /boot contient un certain nombre de fichiers qui semblent correspondre aux noyaux 4.9.0-8 et 3.16.0-6.
Il y a l’air d’y avoir un souci avec le 4.9.0-8 , comment faire pour relancer sur le 3.16.0-6
Merci d’avance pour vos lumières
OD
PS : Ne faites pas la mise a jour strech sur vos briques pour l’instant !!!
Salut,
Je suis sur stretch depuis un moment. J’ai lancé une volée de mises-à-jour système et ma brique ne redémarre plus. Même avec un écran branché je n’ai rien… Pourtant la SD (boot) et le disque en SATA (système et données) semblent OK. Au démarrage les LEDs RJ45 scintillent mais pas de bruit de lecture du disque.
Des idées?
Merci d’avance!
Je n’ai pas encore eu le temps de tester la méthode proposé sur le forum de Debian. Je le ferais probablement demain soir. Si tu souhaites tester avant, la procédure est :
- Monter la carte SD dans un ordinateur.
- Se rendre dans le répertoire
/bootde la carte SD. - Faire la commande suivante (je ne sais pas pourquoi il fait un dd, et pas simplement un cp)
dd if=boot.scr of=boot.script bs=72 skip=1 - Éditer le fichier boot.script pour remplacer la ligne
setenv fk_kvers '4.9.0-8-armmp'
par
setenv fk_kvers '3.16.0-6-armmp' - Terminer par la commande
mkimage -C none -A arm -T script -d boot.script boot.scr
Toutes ces commandes doivent être effectuées par un super utilisateur.
Avant de le faire, je ferais une sauvegarde de ma carte avec dd. Je vous tiendrais au courant.
3 Likes
Coucou !
Ce message tout d’abord pour dire “MERCI MERCI MERCI”.
Et deuxièmement pour faire un retour. J’utilise pas Yunohost mais j’utilise Debian Stretch (100% pur beurre) et j’ai eu le malheur de rebooter - et d’être bloqué comme vous tous avec ce “Starting kernel…”.
Après m’être acharné (sans y arriver) à changer de kernel par apt (en chrootant dedans) - si jamais quelqu’un essaye, il aura ça : https://paste.debian.net/1069217/
- Bref finalement sur IRC @Aleks m’a donné le lien vers cette discussion et “omondieu faut que j’essaye” - et ça marche. La seule différence c’est que je savais que j’avais pas de ‘3.16.0-6-armmp’ installé, donc j’ai simplement fait un “dpkg -l | grep linux-image” vu que j’avais la 4.9.0-7 de dispo. J’ai fait tout pareil. Je démarre dessus et. Montejoie ! Tout fonctionne.
Merci encore. J’avais vraiment les boules quant à tout réinstaller ^^’ (serveur web https, cerficats ssh, serveur mumble, serveur IRC, services TOR… J’en pleurais du sang d’avance de tout perdre - encore merci.)
NB : pas sûr du tout de l’utilité de “dd”. Je pense que ça marche sans problème avec un cp. J’ai cherché à faire un “diff” (qui marche pas soit dit en passant). Une fois que j’ai vu que ça a marché j’ai essayé de comprendre en faisant un “grep -Fxvf boot.scr boot.script” et la seule différence était un commentaire. - Seulement voilà, c’est pas possible. La différence devrait être aussi le changement de kernel. Et c’est là je me suis rendu compte que la commande qu’on fait modifie boot.scr indirectement… Du coup je peux pas dire ce que fait exactement ce dd, s’il coupe un truc ou non. é_è
2 Likes
J’ai testé la manip, toujours pas plus de signes de vie. Pour ma part j’avais 3.16.0-7-armmp. 3.16.0-6 n’était qu’un .bak
Donc j’ai écrit setenv fk_kvers '3.16.0-7-armmp'
L’un de vous a-t-il aussi le système sur un HDD en sata? Chez moi la carte SD est le répertoire /boot entier.
Je me demande si les écrans que j’ai utilisés sont compatibles VGA. Soit j’ai un problème d’affichage, soit ma brique est peut-être plus gravement atteinte que le problème de mis-à-jour…
J’ai essayé aussi de restaurer l’ancien noyau, et c’est un échec. J’ai le même résultat que @gauthier67 : écran noir au démarrage. Ce WE, j’essaierai de télécharger le noyau 4.9.0-7, et de l’utiliser… Je vous tiendrai au courant.
Hello, pour moi ça n’a pas fonctionné tel quel parce que le boot.script généré sur base du boot.scr existant ne fonctionnait pas avec un kernel 3.16.0-6-armmp (ou autre noyau 3.x).
En effet les fichiers dtb ne sont pas organisés de la même manière pour un noyau 4.x ou un noyau 3.x.
Exemple sur une 2.7 avec un kernel 3.16
# ls /boot/ -l
total 41048
-rw-r--r-- 1 root root 2342 jan 23 07:54 boot.scr
-rw-r--r-- 1 root root 2342 jan 23 07:42 boot.scr.bak
-rw-r--r-- 1 root root 153698 jui 15 2018 config-3.16.0-6-armmp
-rw-r--r-- 1 root root 153698 oct 4 18:11 config-3.16.0-7-armmp
lrwxrwxrwx 1 root root 18 jan 23 07:54 dtb -> dtb-3.16.0-7-armmp
-rw-r--r-- 1 root root 23031 jan 23 07:36 dtb-3.16.0-6-armmp
-rw-r--r-- 1 root root 23031 jan 23 07:36 dtb-3.16.0-6-armmp.bak
-rw-r--r-- 1 root root 23031 jan 23 07:54 dtb-3.16.0-7-armmp
-rw-r--r-- 1 root root 23031 jan 23 07:54 dtb-3.16.0-7-armmp.bak
-rw------- 1 root root 14774788 jan 23 07:35 initrd.img-3.16.0-6-armmp
-rw------- 1 root root 15611562 jan 23 07:54 initrd.img-3.16.0-7-armmp
-rw-r--r-- 1 root root 2414425 jui 15 2018 System.map-3.16.0-6-armmp
-rw-r--r-- 1 root root 2414245 oct 4 18:11 System.map-3.16.0-7-armmp
-rw-r--r-- 1 root root 3192328 jui 15 2018 vmlinuz-3.16.0-6-armmp
-rw-r--r-- 1 root root 3192072 oct 4 18:10 vmlinuz-3.16.0-7-armmp
Exemple sur une 3.4 avec un kernel 4.9
# ls /boot -l
total 47204
-rw-r--r-- 1 root root 2685 fév 26 21:25 boot.scr
-rw-r--r-- 1 root root 2685 fév 26 21:25 boot.scr.bak
-rw-r--r-- 1 root root 2613 fév 26 21:31 boot.script
-rw-r--r-- 1 root root 153698 fév 26 21:25 config-3.16.0-6-armmp
-rw-r--r-- 1 root root 189367 fév 26 21:25 config-4.9.0-8-armmp
lrwxrwxrwx 1 root root 48 fév 26 21:25 dtb -> dtbs/4.9.0-8-armmp/sun7i-a20-olinuxino-lime2.dtb
-rw-r--r-- 1 root root 23031 fév 26 21:25 dtb-3.16.0-4-armmp.bak
-rw-r--r-- 1 root root 23031 fév 26 21:25 dtb-3.16.0-6-armmp
-rw-r--r-- 1 root root 23031 fév 26 21:25 dtb-3.16.0-6-armmp.bak
lrwxrwxrwx 1 root root 48 fév 26 21:25 dtb-4.9.0-8-armmp -> dtbs/4.9.0-8-armmp/sun7i-a20-olinuxino-lime2.dtb
drwxr-xr-x 3 root root 4096 fév 26 21:25 dtbs
-rw------- 1 root root 15493865 fév 26 21:25 initrd.img-3.16.0-6-armmp
-rw------- 1 root root 20095196 fév 26 21:25 initrd.img-4.9.0-8-armmp
-rw-r--r-- 1 root root 2414425 fév 26 21:25 System.map-3.16.0-6-armmp
-rw-r--r-- 1 root root 2969829 fév 26 21:25 System.map-4.9.0-8-armmp
-rw-r--r-- 1 root root 3192328 fév 26 21:25 vmlinuz-3.16.0-6-armmp
-rw-r--r-- 1 root root 3716200 fév 26 21:25 vmlinuz-4.9.0-8-armmp
Et donc pour ma LIME2
Il est a noter que ma LIME2 en Yunohost 3.4 est issue d’une migration depuis Yunohost 2.x vers 3.x et je ne sais pas si une installation récente d’une Yunohost 3.x sur stretch contient encore les fichiers d’un noyau 3.16.x
J’ai utilisé un fichier boot.script.3.16.0-6 que vous pouvez trouver ici. Ce fichier a été récupéré avec la méthode dd expliquée plus haut et issue d’une microSD contenant une Yunohost 2.7.14 pour LIME2 que j’avais.
Pour ma LIME2 en Yunohost 3.4 qui bloque sur le starting kernel j’ai mis la carte MicroSD dans un PC GNU/Linux (pour pouvoir lire / écrire sur du ext4), ouvert un terminal, ouvert ma carte microSD, passé en root et fait un cd vers ma carteSD et réalisé les opérations suivantes:
# scp -r /boot /boot.bad
# cd /boot
# rm dtb
# ln -s dtb-3.16.0-6-armmp dtb
# cp chemin_vers_boot.script.3.16.0-6_téléchargé boot.script
# mkimage -C none -A arm -T script -d boot.script boot.scr
# cd ../..
# umount la_carte_sd
L’utilitaire mkimage est disponible via un apt install u-boot-tools.
Si un # ls -l /boot donne autre chose que du 3.16.0-6, il vous faudra en tenir compte et éditer le boot.script, corriger la ligne kvers='3.16.0-X-armmp' et faire un ln -s dtb-3.16.0-X-armmb dtb correspondant à votre version, tant que c’est pas une 4.x.
J’ai remis ma carte SD dans ma LIME2 et tadaaam:
# uname -a
Linux gnunation.be 3.16.0-6-armmp #1 SMP Debian 3.16.57-2 (2018-07-14) armv7l GNU/Linux
# yunohost --version
yunohost:
repo: stable
version: 3.4.2.4
yunohost-admin:
repo: stable
version: 3.4.2
moulinette:
repo: stable
version: 3.4.2
ssowat:
repo: stable
version: 3.4.2
Autre technique de barbare
Vous trouverez également ici deux archives contenant le /boot pour une Lime1 et une Lime2.
Vous pouvez les extraire pour remplacer le /boot sur les carte SD de vos briques bloquées, mais faites quand même une copie avant (soit de votre carte microSD, soit en renommant le /boot en /boot.bad par exemple).
2 Likes
Super, c’est reparti…
J’ai retrouvé tous mes petits dont mon Nextcloud.
Un grand merci “tierce”
1 Like
Bonjour,
je relance le post pour essayer de comprendre ce problème de noyau 4.9.0.8 qui ne démarre pas.
J’ai en effet relancé une mise à jour avec un apt upgrade après un apt update ,yunohost et ses dérivés sont passés de la 3.4.2.3 à la 3.4.2.4 mais le noyau 4.9.0.8 a ét également été réinstallé ce qui a bien évdement bloqué le redémarage.
J’ai donc refait la manip pour revenir avec un noyau 3.16 et tout fonctionne à nouveau.
Je n’en suis pas certain mais il me semble qu’avant cette dernière mise à jour ma brique tournait avec un noyau 4.9.0.7.
D’où provient le problème ? Serait-ce un bug de la version 4.9.0.8 qui pourrait être résolu dans l’avenir?
vais-je devoir redescendre en 3.16 à chaque mise à jour des autres paquets?
Merci d’avance pour vos lumières.
Bonjour,
Le bug a été introduit dans Debian avec la version 4.9.0-8 à cause d’un patch :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922478#72
Il y a des paquets mis à jour trouvables ici :
https://snapshot.debian.org/package/linux/4.9.144-3.1/
notamment
https://snapshot.debian.org/package/linux/4.9.144-3.1/#linux-image-4.9.0-8-armmp_4.9.144-3.1
Pour ma part, ayant une brique chiffrée, toutes les méthodes décrites dans le thread n’ont pas fonctionné. Ce que j’ai donc fait :
- installation fraiche avec l’image chiffrée sur une nouvelle SD via install-sd.sh
- une fois la microSD prête, j’ai copié son /boot dans le /boot de ma brique
PS : il est probable qu’une nouvelle mise à jour arrive dans les dépôts Debian sous peu, je suis étonné que ça ne soit pas encore le cas en fait …
2 Likes
J’ai une Lime 1 et je suppose que le problème d’organisation des fichiers dtb me concerne aussi. Un autre problème vient du fait que le dossier /boot est à la racine de ma carte SD et nom dans un dossier à proprement parler. La racine / étant sur mon HDD en SATA. du coup c’est le bordel.
Je vais faire une nouvelle installation sur ma carte SD puis de copier le boot sur la racine. Wait and see.
Bonjour,
J’ai fais une nouvelle mise à jour de ma brique hier soir avec notamment Yunohost 3.5 et Nextcloud 15.05 qui s’est passée sans accrocs, mais le problème de noyau persiste. J’ai du refaire la manip de tierce pour repasser en noyau 3.16 le noyau 4.9 bloque toujours le démarrage de la brique.
Il est aussi possible d’ajouter le dépôt proposed-updates pour installer le dernier kernel corrigé :
deb http://ftp.fr.debian.org/debian stretch-proposed-updates main contrib non-free
Ensuite, apt update, apt upgrade va ainsi proposer d’installer la version 4.9.144-3.1 du paquet linux-image-4.9.0-8-armmp.
3 Likes
J’avais le même soucis bloqué sur (kernel started et j’ai moi aussi procédé comme indique tierce et c’est reparti
Donc grand merci a toi tierce
Résolu avec la mise à jour Debian de ce matin et le noyau 4.9.0-9.
2 Likes