Màj RPI4 , GCFFlasher_internal -l , clef ConbeeII et commande udev

C’était une image de ce matin (j’ai dis ancienne pour faire la distinction :slight_smile: )

j’avais donc le Kernel 5.10.5 et je suis repassé sur le 5.4.83
Comment savoir si mon Debian Buster est en 32 bits ou 64bits ?
Merci de ton aide

Ca, cela ne se change pas comme cela.

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.

  1. 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

  2. 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…

Bonjour,

armv7l c’est 32 bits
plus de détails ici : [Présentation] akenad - #10 par akenad

akenad :slight_smile:

Oui, il n’y a pas la référence en 64 bits dans le retour de uname -a

Raspberry c’est raté sur le coup, plusieurs allez retour. Le pi4 doit être de préférence utilisé en 64 bits.

Tiens @akenad : toi aussi tu as le problème pour lire la température ? Avec vgcmd c’est ok

Quand j’ai installé mon RPI4B j’ai utilisé un fichier nommé: 2019-09-26-raspbian-buster-lite.img
Je ne sais donc pas si c’est du 64bits ou du 32 :-/

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).

J’ai bien un RPI4B avec 2Go de RAM
En faisant uname -a
J’ai ceci:
Linux raspberrypi4 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux

Je précise que j’ai fait sudo apt update suivi de sudo apt upgrade -y encore ce matin

Il ne faut pas le faire tous les jours hein :wink:

Comme Akenad la vue et vous l’a dit, vous êtes en version 32 BITS. La version 64 bits n’existe que depuis Aout il me semble, cela ne correspondait pas avoir les informations que vous nous aviez indiqué.

Donc, vous êtes sur la branche stable 32bits.

Merci beaucoup pour votre aide en tout cas, j’ai appris pas mal de chose en 2 jours :slight_smile:

A qu’elle fréquence faut-il faire l’update et upgrade? Je ne l’avais plus fait depuis 1an

Je me cite :wink:

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)

1 « J'aime »

Bonjour,
Dans le log « cron_execution » de Jeedom j’ai ceci:
Capture d’écran 2021-01-19 à 11.47.35

En ssh je vois la clef Conbee2 en /dev/ttyACM0 et le RfxCom en /dev/ttyUSB0 (le Type: ConBee est erroné mais pas grave) à condition que j’utilise sudo devant la commande GCFFlasher_internal -l

apietrons_—pi_raspberrypi4___—ssh_pi_192_168_1_201—_171×25

Dois-je m’inquiéter de ce log ou bien est-ce simplement dû au fait qu’il faille sudo pour voir l’état des ports USB?

Merci

Selon tes screen shots tu as deux clefs : une Conbee et une Conbee2

Je pense que tu n’as pas inclus ton user dans le group dialout

 sudo gpasswd -a $USER dialout

Édit: c’est le user des processe qui accèdent aux ports USB qui doit être dans ce groupe

Ok ça me parait logique.
Mon user est pi selon toi?
Comment faire pour lister les users qui se trouve dans le group dialout ?
Merci

dans /etc/group tu as le fichier texte qui comprend tous les groupes comme défini ci dessous

/etc/group file is a text file that defines the groups on the system. There is one entry per line, with the following format:
group_name:password:GID:user_list

The fields are as follows:

   group_name  the name of the group.

   password    the (encrypted) group password.  If this field is empty, no password is needed.

   GID         the numeric group ID.

   user_list   a list of the usernames that are members of this group, separated by commas.

Pour savoir qui tu es c’est simple

whoami

dans /etc
J’ai fait la commande sudo gpasswd -a $USER dialout
Mais ça n’a rien changé, j’ai bien ceci: dialout:x:20:pi,www-data,root voir ci-dessous:

Don cil y a une autre source de génération de ce log étrange s’il en est.

Au passage comment gères tu deux clefs Conbee sur la même machine (deux plug ins différents ?) ?

une est la Conbee2 mais l’autre c’est le boîtier RfxCom pour le 433MHz mais bizzarement c’est nommé par erreur Conbee