Aller au contenu

Pas de MAJ de Kstars avec un RPI4 + Buster

rmor51

Par rmor51
dans Software

 Partager

Messages recommandés

rmor51

rmor51

Posté
Posté (modifié)

Bonjour,

 

jai une clé USB pour mon RPI4 avec Raspbian Buster. J'y ai installé Kstars and co. Mais lorsque je fais un update, Kstars qui est en V3.6.0, compilation du 26/08/2022,  reste comme tel. Alors que sur des clés avec Stellarmate, j'upgrade bien en 3.6.2.

J'ai suivi les instructions d"installation du site Indilib.org pour Raspberry PI. Que se passa ?

Modifié par rmor51
  • rmor51 changed the title to Pas de MAJ de Kstars avec un RPI4 + Buster
rmor51

rmor51

Posté
  • Auteur
Posté (modifié)

uname -a donne : Linux raspberrypi 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux.

Malgré le aarch64, Buster est en 32 bits.

Question, puis-je utiliser Bullseye pour fabriquer ma clé USB avec Kstars ?

Modifié par rmor51
keymlinux

keymlinux

Posté
Posté
Il y a 23 heures, rmor51 a dit :

Question, puis-je utiliser Bullseye pour fabriquer ma clé USB avec Kstars ?

Si tu es content de la distribution Buster que tu utilise actuellement, tu peux aussi reconstruire une image de boot avec une Buster 64bits, ou bien tenter l'installation d'une Bullseye 64 bits.

Personnellement je ne suis pas fan des distributions Debian, je préfère les Ubuntu (question de goût). J'ai récemment refait ma Nafabox avec une image Ubuntu 22.04 LTS

waogll

waogll

Posté
Posté
Le 15/12/2022 à 19:56, rmor51 a dit :

puis upgrade, classique.

 

Peut être utiliser apt full-upgrade ? 

 

Le 15/12/2022 à 21:14, rmor51 a dit :

puis-je utiliser Bullseye pour fabriquer ma clé USB avec Kstars ?

Sur le site de Indi il est toujours indiqué :

 

Stable Release

INDI Library is available for Raspbian Buster. 

rmor51

rmor51

Posté
  • Auteur
Posté

Sauf que Stellarmate est bâti sur Bullseye en 64 bits.

C'est vrai que Nafabox est une solution aussi.

L'intérêt de Raspbian est d'être plus léger que Ubuntu.

Il n'existe pas de version 64 bits de Buster, à ma connaissance. Quant à compiler, c'est hors de portée pour moi.

keymlinux

keymlinux

Posté
Posté
Il y a 2 heures, rmor51 a dit :

L'intérêt de Raspbian est d'être plus léger que Ubuntu

C'est vrai, mais sur un PI4 avec 4GB de ram ce n'est pas trop gênant (cela peut l'être avec un PI4 2GB)

 

Il y a 2 heures, rmor51 a dit :

Il n'existe pas de version 64 bits de Buster, à ma connaissance

Exact, il n'existe pas de Buster 64bits pour raspberry (mais il en existe des Buster 64bits pour PC, d'où le mélange de ma part...)

 

Bilan, tu va devoir te refaire une image de boot à partir d'une Bullseye 64bits.... 😉

 

rmor51

rmor51

Posté
  • Auteur
Posté

J'ai tenté. Il me manque juste la source pour kstars. J'ai regardé le source.list.d de stellarmate mais sans pouvoir résoudre le problème. 

keymlinux

keymlinux

Posté
Posté 
Le repository de Jasem pour Indi et Kstars (cela fonctionne pour les distrib Ubuntu, a voir pour Bullseye)
sudo add-apt-repository ppa:mutlaqja/ppa
sudo apt update
keymlinux

keymlinux

Posté
Posté

Mon message de 19h44 n'est pas vide, mais je conçois qu'il puisse apparaitre vide pour certains, je soupçonne une facétie informatique, liée à un copier coller depuis une page web, avec des effets de bord liés à la couleur de la police et du fond...

 

Ci dessous je tente de réécrire le contenu, y compris une capture du dit message, tel qu'il m'apparait.

   Le repository de Jasem pour Indi et Kstars (cela fonctionne pour les distrib Ubuntu, a voir pour Bullseye)

   sudo add-apt-repository ppa:mutlaqja/ppa 

   sudo apt update

 

1489460703_Capturedcran2022-12-1922_02_17.png.765bca723ad0e053c6baa3ace7a40cfb.png

 

Cordialement

 

rmor51

rmor51

Posté
  • Auteur
Posté

Merci. Le souci n'est pas Bullseyes, mais l'architecture ARM64. Possible recompilation des sources sur le RPI ?

rmor51

rmor51

Posté
  • Auteur
Posté

Je me suis remis à la Nafabox. Mais c'est pas le pied ! la v3.3.2 et la v3.4.0 ne veulent pas booter. Pour la première le fichier start.elf n'est pas la bonne version, pour la deuxième ça tourne en rond sans jamais démarrer !

keymlinux

keymlinux

Posté
Posté

Je n'utilise pas (ou plus) les images Nafabox toutes faites, je veux pouvoir choisir ce que j'installe, même si c'est plus de boulot.

Lorsque j'utilisait un PI3 pour le Nafabox j'utilisais des images toutes faites, ce n'est plus le cas.

Mes problèmes ont commencé lors du passage au PI4, avec des images toutes faites qui étaient incapables de booter de manière fiables sur un PI4 et encore moins de gérer le boot sur USB (disque SSD, pas clé USB...)

Donc lors du passage au PI4 je suis passé au mode je choisi ma distrib, je l'installe, et j'installe les scripts Nafabox par dessus pour le post install avec les softs "astro"

Il y quelques mois j'ai refait ma distribution Nafabox, j'avais un échec systématique pour upgrader de ubuntu 20.04 à 22.04 avec crash pendant l'upgrade et figé au boot... (et ce n'était pas un problème lié à une corruption de la carte SD vu que je boote sur un disque SSD USB)

 

Mon choix: je part d'une install Ubuntu 22.04 LTS, distrib "Mate" (le download c'est ici: https://ubuntu-mate.org/download/ ) . L'équipe Nafabox préconise une xubuntu (Ubuntu avec Xfce) mais je n'aime pas cette variante... (les goûts, les couleurs...)

 

La technique, pour au passage installer sur le disque USB:

 -  Je copie l'image Ubuntu Mate sur une 1ere carte SD  (appelons la carte A)

 -  Je copie l'image Ubuntu Mate sur une 2ere carte SD  (appelons la carte B)

 - Je boote le raspberry sur la carte A

  - Je met la carte B dans un lecteur de carte et le connecte en USB au PI

  - Je connecte mon disque SSD en USB au PI

  - sur le SSD, je cree des partition à la taille voulue avec "fdisk"

      o la partition de boot en FAT de 1GB  (label=system-boot)(sur les cartes SD elle fait souvent moins de 256MB mais cela commence à être petit

      o  la partition OS ext4 de 64GB (label=writable)

      o une partition de swap de 8GB (label=swap) (même avec n PI4 avec 4GB de ram, un peu e swap peut être pratique, et en SSD c'est rapide, ne pas faire swap sur une carte SD ou une clé USB au risque de les tuer...)

     o une partition data sur le reste du disque pour stocker les photos... (label=data)(avec un SSD de 1TB cela laisse de la place...)

 

note: je precise les LABELS car dans le /etc/fstab les partitions sont montées en fonction de leur label, pas en fonction du nom de périphérique, qui varie selon la techno, avec une carte sd  on a du /dev/mmcblk0 avec un disque  usb on aura du /dev/sda, etc..., et si en plus on utilise une clé usb et un disque USB, leur noms de périphérique va dépendre de l'ordre de connection (/dev/sda pour le premier, /dev/sdb pour le second)

Mon /etc/fstab ressemble à cela 

LABEL=writable        /            ext4    defaults    0    0
LABEL=system-boot    /boot/firmware        vfat    defaults    0    1
LABEL=data        /media/nafabox/data    auto    defaults    0    0
LABEL=swap        none            swap    defaults    0    0

 

suite des opérations:

- pour la partition FAT, le monte la source, 1ere partition de la carte B,  et la destination, 1ere partition du disque USB, dans des répertoires tempo je copie de l'un vers l'autre (commande cpio pour préserver les attribute set dates de motifs des fichiers), et je démonte les deux, cela est pratique pour au passage passer d'une petite partition de 256M à une nouvelle de 1G

- Avec la commande "dd" je clone la partition EXT4 de l'OS  de la carte B (celle dans le lecteur de carte en USB, donc avec les partitions qui ne sont pas l'OS en cours de fonctionnement) vers le disque USB (on ne clone pas le contenu de la carte A car copier un filesystem monté en cours de modification ce n'est pas fiable, d'où l'utilisation de 2 cartes SD...). On pourrait aussi faire avec du cpio, mais c'est plus efficace avec le "dd", et puis contrairement à une partition fat, une partition ext4 on peut changer sa taille (via resize2fs)

- Je redimensionne le contenu du filesystem cloné avec resize2fs  pour l' étendre à la taille de la partition de 64GB

- ensuite j'enlève les 2 cartes SD, je ne garde que le disque USB et je reboote --> le PI4 boote sur le disque SSD, c'est plus rapide

 

Ensuite je poursuis l'install Nafabox standard, à savoir clone git des scripts, lancement des scripts pour installer les outils astro...

 

En espérant avoir été clair...

 

EDIT: pour ton problème d'image Nafabox toute faite qui ne boot pas (celle de la 3.4.0), vérifie le contenu du fichier cmdline.txt de la partition fat: si il y a quelque chose du style "root=/dev/mmcblk0p2" alors cela explique le pourquoi cela ne boot pas

La plupart des personnes bootent leur raspberry sur une carte SD, donc avec la partition fat qui sera /dev/mmcblk0p1 et la partition root linux qui sera /dev/mmcblk0p2.

Si tu clone cette image sur une clé USB, le raspberry saura trouver la 1ere partition pour charger le kernel Linux (fichier vmlinux ou vmlinuz) et lire les fichier config.txt et cmdline.txt, ici on a encore pas de linux qui tourne et on se fout des noms de périphérique linux, mais une fois que le kernel linux var démarrer, si on lui explique via le cmdline.txt qu'il doit monter /dev/mmcblk0p2 et bien il ne trouvera pas cette partition, car sur une clé USB cette partition se nomera /dev/sda2 et pas /dev/mmcblkp2

Si on utilise des labels de partitions, comme pour le /etc/fstab on peut aussi les utiliser dans le cmdline.txt, et on écrira:  root=LABEL=writable

 

 

 

rmor51

rmor51

Posté
  • Auteur
Posté

C'est bien compliqué. Même si tu graves d'abord une sdcard, il existe clonecopy pour copier celle-ci sur une clé USB et ou un ssd. Il suffit ensuite d'étendre si nécessaire la partition et rajouter un swap.

 

keymlinux

keymlinux

Posté
Posté
il y a 10 minutes, rmor51 a dit :

Même si tu graves d'abord une sdcard, il existe clonecopy pour copier celle-ci sur une clé USB et ou un ssd

Oui, mais je doute que clonecopy aille modifier le contenu du fichier cmdline.txt et du fichier /etc/fstab de la partition linux pour changer le nom des périphérique qui y seraient codés en dur. Si par contre le créateur de l'image SD a utilisé des LABELS ou des UUIDS pour identifier des partitions alors là oui, le clonage sera transparent.

Vérifie que l'image nafabox 3.4.0 de ta clé USB, si dans le cmdline.txt il est codé en dur root=/dev/mmcblk0p2, remplace par /dev/sda2 (qui est valable pour une clé usb) et cela devrait booter (restera à corriger le contenu du /etc/fstab)

 

EDIT: Et oui, c'est complexe, mais il existe des scripts tout fait qui s'occupent de toute la mécanique, y compris rendre indépendants des noms de périphériques ...

voir par exemple  ici: https://www.framboise314.fr/dupliquez-la-carte-sd-de-votre-raspberry-pi-avec-rpi-clone/

 

rmor51

rmor51

Posté
  • Auteur
Posté (modifié)

Ubuntu 22.04 pour RPI 64 bits est quand même  moins réactif que Bullseye.

La version 64 bits ARM de Kstars est à l'adresse https://ppa.stellarmate.com

Je n'ai pas réussi à obtenir la clé. Mais on peut récupérer les archives de kstars-bleeding, gsc et indi-full, pour installation manuelle.

Modifié par rmor51
keymlinux

keymlinux

Posté
Posté

Bonjour,

 

Le passage 32bits à 64 bits trouve souvent sa justification dans la taille de la memoire qui peut être adressée, donc cela se justifie pour 4GB de memoire ou plus.

Pour les RPI avec moins de memoire cela peut effectivement se discuter, car notamment la memoire consommée sera plus grande en 64bits (impact négatif), mais cela peut aussi se justifier sur une recherche de performance pour certains traitements spécifiques (impact positif d'utiliser des instructions et des registres memoire 64 bits qui permettent d'effectuer une operation sur 2 fois plus de données pour le même nombre de cycle d'horloge du cpu)

voir ici des résultats de bancs sur rpi4 en 32 et 64 bits https://www.phoronix.com/review/raspberrypi-32bit-64bit

 

Et comme le dit @rmor51pour Kstars le support 32bits c'est fini pour les versions après 3.6.0, et comme le sens de l'histoire c'est d'avoir des ordi avec de plus en plus de memoire, donc avec une nécessité de passer au 64 bits, certains developpeurs  supprimeront le support de leurs applis en 32bits. A noter qu'avec un OS 64bits on peut généralement quand même lancer des applications 32bits (mais ce n'est plus vrai sur MacOs après la version 10.14 Mojave où le support 32bits a été supprimé)

 

 

  • 3 semaines plus tard...
dragonlost

dragonlost

Posté
Posté

Hello. Je passe par là ! effectivement Kstart/Indi à arrêter le support pour les distribution 32bit. Le support est aussi arrêter au niveau de la compilation du coup pour l'instant ca compile mais au bout d'un moment la compilation vas sauté donc je vous invite à passer à une distribution 64bit. Au niveau de la nafabox j'essaye temps bien que mal d'avancé sur les script mais c'est assez compliqué de trouver la motivation et de prendre le temps pour ca.

 

bientôt l'arrivé de l'architecture RISC-V !

 

Avez la pénurie je suis content de ne pas avoir limiter le développement au Raspberry.

 Partager
Aller sur la liste des sujets

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.