Vous n'êtes pas identifié(e).
La commande : “dpkg --print-architecture && dpkg --print-foreign-architectures”
Me retourne --> arm64 ; armhf; i386
Donc l'architecture principale est arm64 (ARM 64 bits), et les architectures additionnelles sont armhf (ARM 32 bits) et i386 (x86 32 bits). Je serais curieux de savoir ce qu'une architecture x86 vient faire sur une machine ARM.
homeeasy: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26,
Donc il s'agit d'un exécutable pour l'architecture armhf alors que le système a une architecture arm64. Apparemment ldd ne reconnaît que les exécutables de sa propre architecture.
Si un exécutable armhf peut tourner avec un noyau arm64 (comme les exécutables i386 avec un noyau amd64), il a besoin de toutes les bibliothèques armhf.
La bibliothèque manquante serait installée par le paquet libc6:armhf
Il faut aussi installer toutes les autres dont il dépend : libcrypt1:armhf, libstdc++6:armhf...
J'ai pris le temps de photographier mon install. J'ai ensuite baculé comme tu me l'as dit avec Ctrl+Alt+F4
Déjà, le processus va beaucoup plus loin que lors du lancement du système live.
Dans la dernière photo, on voit que la cause de l'erreur est que le module "loop" n'a pas été trouvé dans le répertoire des modules du noyau. Ce module est nécessaire pour monter le fichier squashfs qui contient le système à installer. Il est installé par le paquet loop-modules-6.1.0-18-amd64-di dans cette version.
Je viens de tester l'installation en mode texte avec l'image ISO debian-live-12.5.0-amd64-lxde.iso dans une machine virtuelle avec 1 Go de mémoire.
Première différence, dans mon test l'installateur n'est pas en mode "low memory" comme dans tes images. Est-toi qui l'as forcé dans ce mode ? Sinon, je serais curieux de voir quelle quantité de mémoire l'installateur voit pour se mettre dans ce mode : Alt+F2 pour aller dans une console avec shell, puis exécuter la commande "free". Pas de photo stp, ce ne sont que quelques nombres à recopier à la main.
Seconde différence, dans mon test le paquet loop-modules-6.1.0-18-amd64-di est installé bien avant l'étape d'installation du système et le module "loop" est bien présent. Je n'ai pas poussé jusqu'au partitionnement du système mais j'ai pu monter le fichier squashfs en ligne de commande.
Si tu as laissé l'installateur tel quel, tu peux voir ce que donnent ces commandes dans la console Alt+F2 :
Si pas de résultat,
Quand je fais une install, le processus démarre plutôt bien puis s'arrête avec une fenêtre "Echec" et pas d'explication.
Avec l'installateur graphique ou texte ? À quelle étape ? Si tout le système n'est pas complètement planté tu peux aussi afficher les derniers logs en appuyant sur Ctrl+Al+F4.
As-tu essayé avec une image d'installation pure (netinst ou DVD-1) au lieu d'une image live, et en mode texte qui demande moins de mémoire ?
j'ai utilisé les /dev/sdxx au lieu des UID
Tu veux dire les UUID ? Lesquels ?
Où as-tu utilisé /dev/sdxx, dans quelles commandes ou fichiers ?
Le fat 32 ne stocke pas les dates de creations mais uniquement les dates de modifications.
https://fr.wikipedia.org/wiki/File_Allocation_Table dit le contraire. Les dates de création, modification et dernier accès sont enregistrées.
du coup le dossier monte après formatage n'a pas de date de modification et par consequent considere que la date du dossier est 0 secondes après l'epoch. 1970 sur les Unix like.
Objection : si tu avais raison, alors une modification du répertoire racine (en créant un fichier ou sous-répertoire) modifierait la date affichée, ce qui, après vérification n'est pas le cas.
D'autre part, qu'est-ce qui empêcherait mkdosfs d'initialiser la date de modification du répertoire racine avec la date courante lors du formatage, comme mke2fs le fait pour ext2/ext3/ext4 ?
Je pense que l'explication est que le répertoire racine d'un système de fichiers FAT est spécial et n'a pas de date de création/modification/accès (ni aucun autre attribut - FAT n'a pas d'inodes, les méta-données des fichiers sont stockées dans les entrées de répertoires parents, mais le répertoire racine n'a pas de répertoire parent), et par conséquent le noyau lui en émule une à 0 après l'epoch.
il n'y a pas d'option pour supprimer des entrées dans le bios ?
Dans la colonne "Help" de la seconde image, je lis "'Delete' deletes an unprotected device".
J'ai jamais pu faire booter le pc portable sur le NVME
Dans ce cas il fallait mettre seulement /boot sur le disque dur et tout le reste du système sur le SSD NVMe.
Tu as fait une installation en mode BIOS, peut-être que le PC ne peut booter sur NVMe qu'en mode UEFI.
Voici le retour de commande
Aucun lecteur de CD/DVD SATA n'est détecté, seulement le disque dur de 4 To.
Pour la copie d'écran, je ne pensais pas que ça pouvait avoir une importance sur le fond du souci
Transmettre du texte sous forme d'image a plusieurs inconvénients, notamment :
- le volume de données à stocker et transmettre, quelques dizaines d'octets en texte contre plusieurs dizaines de kilo-octets en image comme ici mais c'est parfois bien pire ;
- la lisibilité pour les malvoyants qui utilisent un lecteur d'écran avec synthèse vocale, l'affichage sur écran à résolution basse (où l'image apparaît trop grosse, comme chez moi) ou un écran a résolution élevée (où l'image apparaît trop petite), alors que du texte serait affiché avec la bonne taille définie par l'utilisateur.
Voici ce que j'obtiens avec la commande suivante :
/etc/default/keyboard
Ce n'est pas une commande, c'est un fichier de configuration. Ça m'étonnerait que cette "commande" ait opportunément ouvert le fichier avec nano.
Pourquoi avoir mis une copie d'écran graphique et pas une copie du texte comme pour le résultat de localectl ?
J'imagine, probablement de façon un peu simpliste, que je devrais changer le be en fr dans le fichier se trouvant dans /etc/default/keyboard
Le fichier ne se trouve pas dans /etc/default/keyboard, c'est /etc/default/keyboard.
Pour le modifier il vaut mieux passer par
que l'éditer directement, ça mettra aussi des valeurs cohérentes dans les autres paramètres. Exemple chez moi:
Windows 10 ne la détecte pas
Tu veux dire que le gestionnaire de disques ne l'affiche pas, ou bien le gestionnaire de fichiers n'affiche pas son contenu ?
Il aurait peut-être fallu lui donner le type "Microsoft basic data", mais ça m'étonne un peu.
Je ne sais pas quelle est la réelle disposition à ce moment
Tu aurais quand même pu préciser quelle est la disposition du clavier physique et quels sont les caractères obtenus en tapant sur telle ou telle touche.
la disposition clavier était différente entre l'écran de login et lorsque je suis loggé dans le système
Quelle disposition dans l'écran de login ?
Quel "écran de login" ?
Quelle disposition dans "le système" ?
Quel "système" ?
Sinon il faudra le désinstaller manuellement quand tu n'en auras plus besoin.
Et une suggestion : si le dernier noyau installé automatiquement ne fonctionne pas pour une raison X ou Y, au lieu de le désinstaller il est possible de simplement démarrer sur le précédent, soit en le sélectionnant manuellement dans le menu de GRUB à chaque démarrage, soit en le définissant par défaut dans /etc/default/grub avec
Ainsi le méta-paquet linux-image-amd64 peut rester installé et sa mise à jour tirera automatiquement le prochain noyau. Si ce dernier corrige le problème, il suffira de remettre GRUB_DEFAULT=0 pour booter dessus par défaut.
En atendant, pour être sûr que le noyau qui fonctionne ne sera pas désinstallé automatiquement, on peut le marquer installé manuellement avec
si on tente une connexion vers une machine (...) mais depuis un autre lieu (...), il faut alors utiliser l'adresse Publique. Qui ressemble à une série alpha-numérique du genre : 2a02 : 2788 : xxx : xxx : xxxx : xxxx : xxxx : xxxx
C'est de l'hexadécimal. Et il s'agit d'une adresse IPv6 alors que la précédente était une adresse IPv4. En IPv6 on ne parle pas d'adresse "publique" mais "globale". Une adresse globale est utilisable aussi bien pour communiquer sur le réseau local que par internet, donc autant l'utiliser dans tous les cas. Attention toutefois : selon sa configuration, une interface réseau peut avoir plusieurs adresses IPv6 globales dont certaines peuvent être temporaires et changer régulièrement. Pour la prise en main à distance il vaut mieux utiliser l'adresse IPv6 permanente, soit attribuée statiquement soit dérivée de l'adresse MAC de l'interface en configuration automatique (en supposant que l'adresse MAC est persistante, ce qui n'est hélas pas toujours le cas). Pour finir, toutes les adresses IPv6 ne sont pas globales ; uen interface a aussi une adresse commençant par "fe80" qui n'est valable que sur le lien local (non routable) et qu'on n'est pas censé utiliser directement, ce n'est pas un équivalent d'une adresse IP privée en IPv4.
PS: Ah, si, une autre remarque : Les adresses IPv6 ne sont hélas pas joignables depuis certains réseaux qui ne disposent que d'une connectivité IPv4. Dans ce cas il faut utiliser l'adresse IPv4 publique de la box et configurer celle-ci pour rediriger les ports utiles vers l'adresse IPv4 privée de la machine cible.
j'attendais bêtement la notification de mise à jour vers un nouveau noyau. Elle n'arrivait probablement pas je pense du fait que j'avais désinstallé le 15 ?
Si le -15 a été installé par dépendance de linux-image-amd64, alors la déinstallation du premier a entraîné la désinstallation du second. Or c'est la mise à jour de linux-image-amd64 qui entraîne l'installation du dernier noyau disponible par dépendance. Si tu veux avoir les mises à jour suivantes du noyau, il faut le réinstaller.
Ce sera un mystère la raison pour laquelle sur le 15 ça ne marchait pas
Non, la cause est connue. Si mes souvenirs sont exacts,
- le noyau -14 était prévu pour la mise à jour 12.3 de bookworm fin décembre mais avait un bug de corruption ext4
- le noyau -15 a donc été publié dans la foulée avec la mise à jour 12.4 mais il avait un bug de wifi
- le noyau -16 a donc été publié
- plus tard, le noyau -17 a été publié pour corriger des failles de sécurité
- il y a quelques jours le noyau -18 a été publié pour la mise à jour 12.5 de bookworm
À chaque fois, le paquet linux-image-amd64 est mis à jour pour dépendre de la dernière version de noyau disponible.
Le vrai mystère est donc pourquoi as-tu récupéré le -15, qui n'est plus une dépendance depuis deux mois, au lieu du -18.