Auteur Sujet: Le bug du 19 janvier 2038 à 3 h 14 min 8 s pourait impacter des trains / métros (Lu 2962 fois)

mirtouf · « **Réponse #12 le:** 09 décembre 2025 à 19:02:57 »

Sans vouloir faire dévier le sujet, NExTEO étant remisé aux calendes grecques, les Z22500 auraient pu encore rouler quelques années de plus moyennant un rafraichissement bienvenu.

vivien · « **Réponse #13 le:** 11 décembre 2025 à 11:39:25 »

Pou revenir sur le sujet :

Citation de: mirtouf le 06 décembre 2025 à 14:53:06

La RATP s’estime lésée par un problème logiciel grave qui pourrait empêcher ses voitures de circuler au-delà de 2037. Le fabricant, qui ne l’a pour l’instant pas corrigé, va devoir trouver une solution au risque de perdre gros.

Alstom a 5 ans à Alstom pour corriger le logiciel. Tout retard donnera lieu à une amende d'un million d'euros par mois.

Un état des lieux devra être fait d'ici à un an.

Alstom a annoncé faire appel de la décision.

Je ne suis pas sûr que la correction soit si couteuse à réaliser, une mise à jour logicielle pourait suffire. Ce sont par contre peut-être les certifications nécessaires qui vont être couteuses.

D'autres opérateurs pourraient demander la correction, il n'est évidemment pas limité au périmètre RATP.

Ce qui est bien c'est que s'y prendre en 2025, cela laisse plus de 11 ans pour corriger le problème, c'est royal.

mirtouf · « **Réponse #14 le:** 11 décembre 2025 à 15:25:04 »

Je pense qu'on doit trouver des systèmes embarqués temps réels pour lesquels le fabricant va sans doute répondre: le produit est EOL, aucun support même payant ne vous sera fourni, veuillez le remplacer avant 2038.
Pour les systèmes Linux, une mise à niveau vers un noyau > 5.6 sera nécessaire et devrait être possible moyennant des frais de développement surtout s'il y a des SDK employés qui ne sont plus maintenus pour être compatibles avec l'ABI qui gère time_t en 64 bits.

internetmatuer · « **Réponse #15 le:** 11 décembre 2025 à 15:46:12 »

Dans 50 ans probablement: "La fonction freinage d'urgence avant arrivé en gare si le conducteur perd connaissance était basé sur une librairie halluciné par IA"

vivien · « **Réponse #16 le:** 11 décembre 2025 à 15:58:44 »

Dans le domaine du ferroviaire, tout ce qui est sécurité est redondé, testé et re-testé. Le niveau d'exigence n'est pas si éloigné de celui de l'aérien.

Je crois que le dispositif homme mort est testé à chaque sortie de garage.

Franchement, je sais que quel que soit le niveau d'automatisation des lignes (niveau 2 pour NExTEO pour les tronçons central des RER B, D et E ou Niveau 4 pour plusieurs lignes de métro), la sécurité sera toujours assurée peu importe les événements.

Quand il y a une catastrophe, il y a une série d'erreurs humaines et des dispositifs techniques qui n'ont pas joué leur rôle qui est impressionnant.

vivien · « **Réponse #17 le:** 18 décembre 2025 à 12:48:49 »

Citation de: internetmatuer le 11 décembre 2025 à 15:46:12

Dans 50 ans probablement: "La fonction freinage d'urgence avant arrivé en gare si le conducteur perd connaissance était basé sur une librairie halluciné par IA"

J'ai trop pensé à toi sur ce nouveau problème pour Alstom (sans aucun lien avec le bug du 19 janvier 2038) : Problème sur le freinage d'urgence, qui a déjà provoqué un accident de tramway à Strasbourg :

mirtouf · « **Réponse #18 le:** **Aujourd'hui** à 19:08:27 »

Un article sur Epsiloon qui aborde le sujet et pas que pour les trains:
https://www.epsiloon.com/tous-les-numeros/n57/le_bug_de_l_an_2038/

vivien · « **Réponse #19 le:** **Aujourd'hui** à 21:31:31 »

L'article ne donne rien de concret pour savoir si un système sera affecté par le bug.

De ce que je comprends, beaucoup de systèmes d'exploitation 32 bits sont vulnérables.

Pour les systèmes 64 bits, il me semble que seul le stockage de fichier est à risque.

ext2 et ext3 : date stockée sur 32 bits
ext 4 : date stockée sur 64 bits sauf exceptions

ext4 est sable depuis Linux 2.6.28 (source: Le noyau Linux 2.6.28 est disponible), ce qui remonte à décembre 2008. Son utilisation par défaut dans Ubuntu remonte à Ubuntu 9.10 (source : Ubuntu 9.10 (« The Karmic Koala »)) sortie en octobre 2019

Pour identifier le type de système de fichier : df -hT
Dans la colonne Type, vous verrez si c'est du ext2, ext3; ext4 ou du xfs.

Pour un système de fichier ext4

Sur ext4, l'immunité au bug de l'an 2038 dépend de la taille des "inodes" (les structures de données qui décrivent les fichiers). S'ils font 128 octets, les dates sont sur 32 bits. S'ils font 256 octets ou plus, des bits supplémentaires sont alloués aux dates, repoussant la limite à l'an 2446.
sudo tune2fs -l /dev/votre_partition | grep "Inode size"

Exemple :

Code: [Sélectionner]

$ sudo tune2fs -l /dev/nvme0n1p2 | grep "Inode size"
Inode size:               256

Inode size: 256 (ou une valeur supérieure, comme 512 ou 1024) : Vous êtes à l'abri. C'est la valeur par défaut sur presque toutes les installations Linux depuis l'arrivée de l'ext4 en 2009.

Inode size: 128 : Votre système est vulnérable. Cela se produit généralement sur de très vieux systèmes de fichiers qui ont traversé les années sans jamais avoir été reformatés (il est possible de passer d'ext3 à ext4 sans formatage).

Pour un système de fichier xfs

Il y a plus de risques d'être limité au 19 janvier 2038 avec xfs : le format "bigtime" introduit dans le noyau 5.10 en 2020
La commande pour tester : sudo xfs_info /dev/votre_partition | grep bigtime

... bigtime=1 ... : la limite est repoussée à l'an 2486 (c'est le cas par défaut sur les distributions récentes).

... bigtime=0 ... : la limite est au 19 janvier 2038. La partition a été formatée avec un ancien outil.

Si la commande ne retourne aucune mention de bigtime : la limite est au 19 janvier 2038.