Tu n’as pas la même version que moi !!
C’est normal, lui est en 32 bits et toi en 64 bits
1 « J'aime »
J’ai juste fait apt upgrade, pas rpi-update
Bonjour,
La réponse à la question initiale du topic n’est surement pas simple à donner, faut-il encore attendre pour passer a Buster en 64 Bits (Pi3b+ssd msata x850V3.0), ou passer en 32 et attendre que la 64 soit bien stable ?
Bonne fin de WE
Bonjour,
Au vu des retours vaut mieux attendre.
J’ai fais la dernière mise à jour de l’os vendredi soir donc on verra bien. Mais depuis le 9 novembre j’ai eus aucun plantage mais sans les dernières mise à jour.
Comme promis, voilà la description de mon cas :
Suite au passage de Jeedom en 4.1 et la nécessité de tourner sous debian 10, j’ai décidé de passer sous debian 10 (mon jeedom tournait depuis 2 ans sous D9 sans aucun soucis). Edit : Mon RPi est un Pi3 Model B Rev 1.2.
Je suis passé par l’image officiel prebuildée avec jeedom intégré, tournant sous D10 version 64bits.
L’installation (debian + restauration sauvegarde jeedom) s’est passé sans aucun problème (hormis le problème de retour température de la commande « cat /sys/class/thermal/thermal_zone0/temp » plus fonctionnelle, voir fil dédié ici).
Suite à l’installation, j’ai fait un « apt-get update » + « apt-get upgrade ». Mon kernel était alors le suivant : Linux jeedom 5.10.5-v8+ #1392 SMP PREEMPT Sat Jan 9 18:56:30 GMT 2021 aarch64 GNU/Linux. Ca c’était le jeudi 14/01. Depuis cela tourne sans aucun problème.
Ce soir (le dimanche 17/01 à 19h30), je viens de nouveau de faire un apt-get update+upgrade et reboot. J’ai bien eu une (petite) mise à jour qui est passée, mais la version de mon kernel n’a pas bougé.
Affaire à suivre donc…
Merci du retour. Sur pi3 ou 4?
Bonne remarque, sur RPI3. J’édite mon post
1 « J'aime »
Attention quand vous parlez de debian10, c’est une distribution linux et ce n’est pas raspiOs même si il est basé sur debian10.
Je confirme qu’à cet instant, sur un 2ème pi qui a été upgradé de manière classique on en est là:
Linux piChambre 5.4.83-v7+ #1379 SMP Mon Dec 14 13:08:57 GMT 2020 armv7l GNU/Linux
Si vous venez d’installer une image officielle ou avez fait un rpi-update, vous serez plus loin dans les versions.
Perso je préfère ne pas forcer les versions kernel pas encore prévues dans le processus normal.
Bonjour,
Petit retour au bout de 7 jours après la mise à jour de buster 64bits
Linux jeedom 5.10.5-v8+ #1392 SMP PREEMPT Sat Jan 9 18:56:30 GMT 2021 aarch64 GNU/Linux
Pour l’instant aucun plantage, c’est stable ! je continue à croiser les doigts.
voici ma charge sur 15min, le pic est la mise à jour faite vendredi dernier.
la charge sur 1min
je vois pas trop de différence.
Mais tu as pas le même système sur les 3 ?
C’est du au mise à jour .
Ils sont tous en 64 Bits !
Version Linux 10 (buster) 5.10.x (suivant le PI) -V8+ #139x (suivant le PI)
Tu es en 64bits depuis quand ? As tu eus des plantages ?
Non pas de plantage ! Avec les versions que j’ai . Comme je disais à @Fabrice doit dépendre des versions installées. Le gros problème se pose lors de la restauration (après installation de Jeedom en cde Linux directe) , il faut être très patient lors du lancement « démon » des plugins (surtout Broadlink et aussi avec celui du Twinkly ) j’ai désactivés les plugins en attendant que tout les autres soient Ok , puis j’ai relancé un par un ceux là .
Depuis tout est Ok, je suis en train de tester Ventilo (Raspi-Ventila-PI4-MK2) sur les PI4 et PI3B+.
Pour ma part j’ai une installation automatique de jeedom (sans ligne de commande comme dans la doc).
Pour la restauration j’ai dû lancer l’installation de certain plugin qui s’étaient pas fait tout seul.
Ca fait plus de 2 mois que c’est stable.
J’ai essayé cette version en 64 bits avec l’image de Jeedom intégrée (la version fonctionnelle) , mais comme cela n’était pas facile de réinstallé autre chose dessus (pour test) j’ai mis une image de l’Os et puis lancé l’installation de Jeedom depuis l’OS .
1 « J'aime »
Tu tournes sur une SD ?
J’ai modifié le plugin « Monitoring » pour avoir les infos de température du CPU et quelque bug (SSH) et valeur « swap » [ d’ailleurs j’ai désactivé le « Swap » sur les SSD ]
oui sur une sd car j’avais des soucis avec le cable de mon msata (enfin je suppose, car depuis que je suis en sd plus aucun plantage et j’etais en 32bits).
Donc tant que ca fonctionne sur sd je laisse comme ça. Mon msata est en attente avec un nouveau cable comme ca si la sd vient a lacher je bascule dessus.
J’ai un onduleur donc on verra bien.
Pourquoi désactiver le swap ?
Appel au disque (carte pour toi) trop fréquent, alors que ‹ rarement › on en a besoin suivant mémoire , lors des fichiers d’échange . A tester de toute façon, voir l’utilisation du tien de Swap .