Oui, il faut émuler l’architecture ARM si ton PC est en x86_amd64.
sudo apt install qemu-user-static // pour installer l'émulateur pour ARM
cp /usr/bin/qemu-arm-static /mnt/usr/bin/ // pour le déporter dans le chroot
1 Like
Donc j’ai suivi les étapes fournies dans le précédent lien en créant le répertoire system/ dans media/. Les différents répertoires systèmes ont été liés et montés dans ce répertoire. J’ai récupéré la logiciel pour émuler l’architecture ARM sur mon PC. J’ai déporté l’émulateur dans le chroot par : [quote=“otm33, post:21, topic:36632”]
cp /usr/bin/qemu-arm-static /media/system/usr/bin/
[/quote]
puis j’ai lancé la commande de chroot : chroot /media/system
Aucune erreur.
Le prompt est passé de ~# à /#.
J’ai donc besoin d’un noyau armbian.
Merci ;).
Sur les archives /mirrors/armbian/archive/lime2/archive j’ai récupéré le kernel Armbian_23.02.2_Lime2_bullseye_current_5.15.93.img.xz. Il faudra le copier sur la carte SSD avant de lier les répertoires et de chrooter.
Ce type de fichier image se décompresse avec la commande:
xz -d nomdu kernel.img.xz
Problème
J’ai une erreur quand j’essaye de réinstaller le nouveau kernel:
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet Armbian_23.0.2_Lime2_bullseye_current_5.15.93.img```Avec un apt install --reinstall ? Peu probable que ça vienne de là, mais as-tu lancé apt update?
Non, j’ai pas de réseau..
Ok. Inutile en effet si tu réinstalles depuis le fichier que tu as récupéré.
Si jamais tu as besoin du réseau, regarde si c’est un problème de connexion ou de DNS. Si pas de DNS, pas impossible que tu doives rajouter un nameserver dans /etc/resolv.conf ou son équivalent sur ta distrib ou reporter celui de ton pc hôte.
Hi Pidlas,
My French is not the best, so I get the gist of the thread but answering in my kind of French would not be helpful 
I used to run Yunohost with Armbian on Orange Pi. Nine out of ten times when I had “broken” uSD cards, it was actually the power supply (as, actually, Armbian or Sunxi warns about). Especially during boot power usage seemed to peak.
That is for Orange Pi, your board (Olimex?) surely is better behaved, but if you didn’t check it may be worth to try with another power supply.
Another option could be to use your ARM board, boot from a working SD card and put your problematic 32GB card in a USB reader and then chroot to there. It would also allow you to copy files from the ‘new’ install to the ‘broken’ install (it has the correct architecture)
Hi wbk and thanks for you support,
Indeed my server is an olimex A20 OlinuXino Lime2. As I had a spare SSD card I could restart my server with it. Thus, if the power supply was the problem it would not be running, wouldn’t it ? Unless, the power supply is messing with the kernel. Is that what you are assuming ?
I exactly did what you asked for. I inserted my “broken” SSD card in my PC, chrooted it, and I am in the process of installing a new kernel but I am stuck with 2 problems:
- when I try to reinstall a new kernel with
apt install --reinstall Armbian_23.02.2_Lime2_bullseye_current_5.15.93.img
I got an error message, saying
Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait E: Impossible de trouver le paquet Armbian_23.0.2_Lime2_bullseye_current_5.15.93.img
- I have no network access in my chrooted environment. I am trying to solve this issue in order to attempt an apt update
Where would you like me to look at to find the warnings about the power supply ?
Bonsoir @pidlas
J’ai retrouvé un RPI et, pour l’expérience, j’ai tenté la chose suivante:
- installation de armbian sur A (une carte SD) et sur B (un support USB) (ce ne sont pas des clones mais des supports imagés l’un après l’autre);
- vérification du bon démarrage de A puis de B sur le RPI.
- Dans un deuxième temps, j’ai effacé sur B tout le contenu de la partition RPICFG (le nom de la partition de boot sur RPI je crois). Evidemment, ça démarrait beaucoup moins bien ainsi… (sans que ce soit identique à ta panne).
- J’ai ensuite tout simplement monté A et B sur mon PC et ai copié-collé la partition de boot de A sur B.
- B a redémarré sans problème (pas mal de fichiers fsckXXXX.rec dans un premier temps mais rien de récurrent).
Même manoeuvre avec le dossier boot de la partition n°2 nommée “armbi-root”). Là aussi B a rebooté sans problème.
J’ai été étonné que ce soit aussi facile et il y aurait peut-être des surprises ensuite mais pour ce qui est de redémarrer, ça a redémarré.
Si ça peut t’aider.
1 Like
Bonjour à tous,
Je vais reprendre les différents éléments dans un billet récapitulatif et vous dire ce que j’ai trouvé qui pourrait aider d’autres ‘green beans’ comme moi, ;).
1 Like
Bonjour,
Alors première chose pour les détenteurs d’une carte ARM olimex, carte conseillée par YNH, le site armbian qui commence par une vidéo d’introduction en anglais qui présente les grandes pannes connues et comment y remédier:
https://docs.armbian.com/User-Guide_Troubleshooting/#writing-images-to-the-sd-card
Je sais le faire maintenant grâce au site référencé ci-dessus. La carte SSD doit être installée sur un PC et en ligne de commande, lancer la commande:
fsck /dev/mmcblkXpY -f
ou X est le nom du périphérique et Y la partition. Chez moi c’était mmcblk0p1. La vérification ne se fera pas si la carte SSD est montée.
Pour connaître le nom du périphérique, une fois votre carte SSD installée sur votre PC, lancer la commande:
blkid
La carte SSD, une fois insérée dans le PC, laisse apparaître au moment du démarrage du PC, dans le grub, le nom de la version du système. Ca peut être utile pour savoir qu’elle version réinstallée ou pour en réinstaller une précédente.
À ce propos j’ai confondu la version du système armbian et les versions des fichiers système, comme dtb, config, initrd.img, system-map et vmlinuz. Ma version installée de armbian est la 23.n.m alors que les versions des fichiers présents dans le répertoire /boot sont en 6.12.20.
Grâce à la doc. provenant du lien du site armbian j’ai également pu me rendre compte qu’il était possible de prendre la main sur une carte ARM avec un câble série / USB ou bien un câble mini-UB / USB connecté à votre PC ce qui est plus facile à mettre en oeuvre que de connecter un clavier, un écran, une souris. Ensuite il faut lancer une connexion SSH, avec putty par exemple. Tout est expliciter dans la doc. armbian dont le lien est donné plus haut.
Bonjour,
Il me reste toujours les deux mêmes problèmes:
- le réseau dans mon environnement chrooter ne fonctionne pas
- la commande pour réinstaller la version système armbian_23.n.m ne fonctionne pas non plus.
J’apprécierai votre aide sur ces 2 problèmes persistants. Je continue les recherches de mon côté.
Bonne fête des travailleurs qui sont les seul.e.s à créer de la richesse!!
Bonjour @pidlas
Armbian_23.0.2_Lime2_bullseye_current_5.15.93.imgest un fichier image complet me semble-t-il (pour flasher une clé), pas une image de kernel.
1 Like
Sorry for the silence!
In my case the power supply worked OK for running the Orange Pi, or for charging a phone. Only while booting there would be spikes in CPU and I/O load (I presume), resulting in peak power usage. When inserting a USB power meter in between, I could see the voltage would drop to 4,7V instead of just above 5V under normal usage.
My guess is that signal integrity got lost, leading to garbage data.
The annoying thing was that the boards ran at friends of my children. When I took the boards home to throubleshoot the problem and check the uSD card, there would be no problem.
It is a bit far fetched as a cause when in your case everything has been working normally. It could be that the power supply degraded or the USB cable got a bit of (internal) damage, so it’s worth checking these things if it doesn’t take too much time.
1 Like
Bonjour @otm33,
Je suis d’accord avec cela au vu de mes recherches. L’image de kernel serait donc l’une de celle présente dans le répertoire /boot. À votre avis, qu’elle est-elle ?
- dtd-6.12.20-current-sunxi
- config-6.12.20-current-sunxi
- system-map-6.12.20-current-sunxi
- initrd.img-6.12.20-current-sunxi
- vmlinuz-6.12.20-current-sunxi
Bonjour à tou.te.s,
J’ai pu corrigé l’erreur sur mon environnement chrooté qui m’empêchait d’accéder au réseau. Dans le répertoire /etc le fichier resolv.conf était corrompu et un fichier resolv existait avec les bons ‘nameserver’. Je l’ai donc renommé resolv.conf.
Bonjour @pidlas
Je crois que tout cela constitue le noyau. Il faut regarder ce qui est stocké dans les dépôts d’apt apt-cache search linux-image mais 
en testant armbian j’ai vu qu’il y avait un outil de gestion sudo armbian-config, accessible en chroot, avec possibilité de gérer les kernels.
1 Like
Oui, tout à fait. Je l’ai lancé mais il ne détecte aucun kernel alternatif dans mon répertoire /boot malheureusement. Je reconnais que j’ai dû sans doute y faire le ménage, un ménage un peu trop sévère car d’habitude je laisse toujours les deux derniers noyaux !!
Bonjout @otm33,
Le retour est une liste assez longue de fichiers linux-image-* et linux-headers-* mais rien qui ressemble aux fichiers présents dans /boot. Je m’interroge..
Je dirais “linux-image-current-sunxi64” puisque cela semble correspondre à ton OS
1 Like
apt-search search current-sunxi
donne un résultat plus probant.