Après 1 an d’utilisation j’ai décidé de mettre à jour mon Rasperry PI4
J’ai donc fait: sudo apt-get -y update suivi de sudo apt-get -y dist-upgrade ensuite sudo reboot
Voici la version dans laquelle je suis: uname -a
Linux raspberrypi4 5.10.5-v7l+ #1391 SMP Thu Jan 7 17:51:37 GMT 2021 armv7l GNU/Linux
et le firmware: /opt/vc/bin/vcgencmd version
Jan 7 2021 18:27:29
Copyright (c) 2012 Broadcom
version fb345a0c2d5544957f4ba1a2b9e968970e3312c4 (clean) (release) (start)
J’utilise depuis toujours udev pour fixer le port USB de ma clef ConbeeII et de mon RfxCom
En temps normal en tapant la commande: GCFFlasher_internal -l
J’ai ceci:
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------±-------±--------±-----------±------
/dev/ttyUSB0 | 0x0403 | 0x6015 | DO4GUPND | ConBee
/dev/ttyACM0 | 0x1CF1 | 0x0030 | DE2197738 | ConBee II
/dev/ttyAMA0 | 0x0000 | 0x0000 | | RaspBee
Depuis la mise à jour, je n’ai plus que ceci:
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------±-------±--------±-----------±------
/dev/ttyAMA0 | 0x0000 | 0x0000 | | RaspBee
Il ne m’affiche plus ce que j’ai fixé avec udev
Quand je test dans Jeedom, ma clef ConbeeII et le RfxCom fonctionnent.
Je voudrais comprendre pourquoi et aussi me rassurer car rien ne me dit que si mon système reboot, j’aurai toujours mes 2 systèmes fonctionnels :-/
Merci pour votre aide
Edit:
GCFFlasher_internal -l ne donne rien mais si je le fait en root via sudo c’est bon
Avant je pouvais faire cette commande sans utiliser sudo.
Avez-vous une idée de la raison ???
Merci
Je pense que l’utilisateur qui lance la commande n’a peut être pas les droits de lecture sur les ports fixés par udev.
Mais là je m’avance en terrain sablonneux.
Attention, la mise à jour que vous avez installée (avec en prime le Kernel 5.10.5) comporte plusieurs problèmes (voir sur le forum avancé de la fondation Pi).
Il est actuellement préférable de ne pas le faire, quelques corrections sont déjà disponibles sur les dépôts Github, en attentes de confirmation de plusieurs utilisateurs.
Je ne sais pas s’il y a un rapport ou non avec votre situation, mais beaucoup d’utilisateurs (avancés) proposent de repartir sur l’image d’origine (Août 2020) et de faire la mise à jour avec une option pour ne pas mettre à jour le Kernel.
Aïe!
Et si on a mis le kernel 5.10.5, peut-on revenir sur un ancien qui est stable?
J’avais pris une image de mon système avant l’upgrade et quand je remets cette image, je constate que malgré tout je garde le nouveau kernel 5.10.5. J’imagine qu’il est sauvé dans une mémoire non volatile (eprom) du Raspberry!
Merci
Bon j’ai repris une ancienne image encore.
Quand je vérifie via uname -a, il me montre que je suis en kernel 5.10.5
En vérifiant le firmware je suis avec celui du 7 janvier 2021
J’ai fait: sudo apt-get -y update
et ensuite: sudo apt-get -y dist-upgrade
suivi d’un reboot
Je revérifie les version et là je suis étonnamment redescendu au kernel 5.4.83 (du 14 décembre)
et le firmware est passé à celui de ce jour du 8 janvier 2021
J’imagine donc qu’ils ont adapté leurs packages!
J’aimerais néanmoins savoir comment choisir (lorsque je fais des mises-à-jour via sudo apt-get -y update suivi de sudo apt-get -y dist-upgrade) pour ne pas mettre à jour le kernel?
Je viens de tester mais ça revient à la même chose que les commandes que j’utilise.
A aucun moment il ne me demande ce que je veux installer. Il liste les paquets et ensuite je ne peux dire que oui ou non à l’installation de tous les paquets en une fois. Je ne peux donc pas décider de ne pas mettre à jour le Kernel. :-/
Elle ne devait pas être si ancienne que cela l’image pour être en 5.10.5, il vient juste de sortir
Hors PI4 (que je n’ai pas) les RPi3B, RPi3B+ et RPi Zero W viennent de prendre 2 mise à jour de Kernel d’affilé (preuve d’un problème).
Et sur les versions 64 bits (toutes passées en Kernet 5.10.4 hier et 5.10.5 aujourd’hui), je rencontre des coquilles qu’il n’y avaient pas il y 2 jours (par, la commande cat /sys/class/thermal/thermal_zone0/temp)
- L’édition 32 bits (mise à jour aujourd’hui aussi), le Kernel est resté en 5.4.89 et n’a pas ce problème.
Pour le coup, je pense qu’il est prudent de garder à l’esprit que les éditions 64bits ne sont encore qu’en bêta.
Saisissez cette commande : uname -a
En 64 bits cela donne un retour qui ressemble à cela : Linux pios64 5.10.5-v8+ #1391 SMP PREEMPT Thu Jan 7 17:55:54 GMT 2021 aarch64 GNU/Linux
C’est le aarch64 qu’il faut regarder.
J’ai ceci avec uname -a:
Linux raspberrypi4 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux
Ce que je ne comprends pas c’est qu’avec mes commandes: sudo apt-get -y update suivi de sudo apt-get -y dist-upgrade je pensais qu’il n’installait que des « stable release »
Je ne comprend pas pourquoi vous utilisez dist-upgrade ?
- Cette commande permet (par exemple) de passer de la version 9 de Debian à la version 10 (sans rentrer dans les détails, cette commandes est fortement déconseillé, on le constate même sur ce forum, ceux qui l’on fait pour passer d’une version 8 à 9 ou de 9 à 10 ont TOUS des problèmes (car ce ne sont pas des experts (ce qui n’est pas une critique de ma part, je n’en suis pas un non plus sur cet OS)).
Pour une mise à jour « normale » (à faire mensuellement par exemple), il faut utiliser cette commande : sudo apt update && sudo apt upgrade -y
(apt remplace la commande apt-get maintenant)
Et sur un Raspberry Pi : apt upgrade installe aussi le dernier firmware et Kernel
=> mais tout cela en stable
Vous êtes bien avec des commandes qui passe en stable, mais, il y a une subtilité qui vous échappe :
- Le truc que nous avons tendance à oublier, c’est que l’édition 64 bits de Raspberry Pi OS n’est pas encore stable (c’est du bêta).
Pour installer un Kernel non stable, la commande est rpi-update (cette commande, suivit d’un ID, permet aussi de jongler avec les Kernel)
Et les mises à jours de ces 2 derniers jours, PROUVENT, pour ceux qui en doutait encore, que c’est du bêta (je parle de Raspberry Pi OS 64 bits) !
Donc, si vous avez suivit, vous exécutez bien des commandes de mise à jour stables, si et seulement si vous étiez en version stable : ce qui n’est pas votre cas.
Merci Fabrice, voilà des explications claires comme j’aime.
Effectivement je suis novice en Debian.
Voici un lien très compréhensible sur les différentes commandes:
Quand j’ai fait la config de mon RPI4 c’est un suivant des tutos. Je ne me souviens pas qu’en mettant Buster (10) j’ai eu le choix entre une version 32bits ou 64bits.
Je dois donc déduire que je suis en 64bits???
Il y a bien un moment ou la version 64bits deviendra stable j’imagine…
Vous être en 32 bits (retour de uname -a).
La version 64 bits est expressément nommée avec 64 dedans :
2020-08-20-raspios-buster-arm64-lite.zip
- c’est uniquement cette version qui est bêta.
Je suis visiblement partie en vrille quand j’ai lu 64 bits dans vos messages, croyant que vous y étiez (alors que non).
Je viens aussi de comprendre un autre truc. Raspbian est passé, entre 2 jours, du Kernel 5.10.4 puis 5.10.5 pour les 64 bits et pour les 32 bits, ils sont passé d’un Kernel 5.10.5 à un Kernel 5.4.89 (retour arrière).
Les 2 RPi en 32 bits sont bien en 5.4.89 et mes 2 RPi 64 bits, sont eux, restés en 5.10.5 (je pense que c’est normal pour du bêta).
Sur les RPi3B+, je ne recommande pas du tout le passage en 64 bits pour le moment. Les 2 RPi chez moi, qui y sont, plante de temps en temps (alors que cela n’était JAMAIS arrivé en 32 bits). Je pense refaire un retour en 32bits demain.
Mais attention, un Pi4 est certainement plus approprié pour rester en 64 bits (surtout si vous avec 4/8 Go de RAM).
)