Brique ne démarre plus après migration

Support Brique Internet / Internet Cube
,
1

Bonsoir,
J’ai lancé une mise à jour suivie des migration 6, 7 et 8 sur ma brique (Lime2). Depuis elle ne démarre plus…
J’ai essayé de la débrancher et de la rebrancher, sans succès. J’ai donc branché un écran pour voir ce qu’il se dit, voici ce qui est affiché.

IMG_20190218_204758
IMG_20190218_204758.jpg2448×3264 3.59 MB

L’écran reste en suite fiché à ce message “Starting Kernel”.
Savez-vous ce que je peux faire pour réparer cela ?

Question subsidiaire : j’ai bêtement omis de faire une sauvegarde. Quels fichiers dois-je récupérer sur la carte SD pour sauver mes courriels ?

Merci :slight_smile:

2

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
3

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
4

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…

5

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 ?

6

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
7

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 !!!

8

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!

9

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 /boot de 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
10

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
11

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…

12

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.

13

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
14

Super, c’est reparti…
J’ai retrouvé tous mes petits dont mon Nextcloud.
Un grand merci “tierce”

1 Like
15

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.

16

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
17

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.

18

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.

19

Il est aussi possible d’ajouter le dépôt proposed-updates pour installer le dernier kernel corrigé :

deb Index of /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
20

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