• # /etc/apt/source.list

    Posté par  (Mastodon) . Évalué à 4 (+2/-1). Dernière modification le 17 avril 2026 à 07:43.

    EDIT : Très mauvaise idée ce que j'ai dit (cf les commentaires ci-dessous) ! Ça m'apprendra à dire des trucs que j'ai jamais testé par moi-même…

    Pas de magie dans Debian, la version de ton système est simplement celle qui est tirée par les paquets.

    Modifie le fichier /etc/apt/sources.list pour mettre trixie à chaque fois que tu vois sid (fais une sauvegarde juste avant sait-on jamais).

    Regarde aussi dans /etc/apt/sources.d/* si tu as des fichiers, et modifie-les de la même manière.

    Ensuite : apt update, apt full-upgrade et un petit reboot pour fêter ça :)

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: /etc/apt/source.list

      Posté par  (site web personnel) . Évalué à 2 (+2/-1).

      Pas certain que ce soit la réponse la plus éclairée !
      Le downgrade ne se fait pas facilement !
      Aucune procédure n'est pensée pour il me semble.

      https://wiki.debian.org/SystemDowngrade

      En gros … ce n'est pas supporté. A tes risques et péril !

      • [^] # Re: /etc/apt/source.list

        Posté par  . Évalué à 3 (+2/-1).

        Aucune procédure n'est pensée pour il me semble.

        Au cours de mes années Debian, je ne me suis jamais posé la question, je l'ai fait plusieurs fois
        https://linuxfr.org/nodes/143028/comments/2019433

        • [^] # Re: /etc/apt/source.list

          Posté par  (site web personnel) . Évalué à 1 (+1/-1).

          Jusqu'au jour où !

          Ce n'est pas parce que cela a marché chez toi que cela marchera chez les autres (même plusieurs fois). Surtout pour des installations avec des services ou des stockages non compatibles.

          Le downgrade n'a jamais été une solution facile que ce soit au niveau du système ou des logiciels.
          Très peu de logiciels fournissent de procédure pour downgrader

          Je pense à :
          - Passage de libc
          - Passage de dovecot 3 à 2
          - Modification du nommage des cartes réseaux (udev)
          - Modification du mappage des disques durs
          - Evolution du chiffrage des disques…

          Alors oui cela peut passer, surtout peu de temps après la sortie d'une stable, mais plus le temps passe plus l'écart se creuse et les problèmes s'accumulent.

          Donner ce genre de conseils n'est pas forcément aider les gens.

          C'est tellement plus simple :

          1. de faire un backup
          2. de remonter une machine vierge avec la bonne version.
          3. de repartir sur une base propre.

          • [^] # Re: /etc/apt/source.list

            Posté par  (Mastodon) . Évalué à 5 (+2/-0).

            On parle de quoi exactement? D'un serveur personnel ou d'un truc d'entreprise en production?

            Tant que t'as les données, des backups, le seul risque c'est un peu plus de downtime.

            Bon moi je réinstallerais de toute façon, c'est toujours un bon exercice qui permet toujours de tester les procédures de récupération.

    • [^] # Re: /etc/apt/source.list

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+2/-1).

      Malheureusement, ça ne suffira sûrement pas, parce que tous les logiciels installés vont changer de version.

      Il faudra donc également mettre à jour à la main chacun des fichiers de configuration.

      Et il faut que chaque logiciel soit capable de revenir en arrière. Ce n'est pas le cas si des procédures de mise à jour ont modifié la structure des données (par exemple par une mise à jour des schémas de base de donnée ou de structure de dossiers / fichiers).

    • [^] # Re: /etc/apt/source.list

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      On ne peux plus plusser (j'avais moinsser parce que la réponse était "mauvaise").

      Mais merci d'avoir ajouté la note.

  • # a voir

    Posté par  . Évalué à 5 (+4/-0).

    Hello

    Les 2 premiers resultats d'une recherche gogol sont:

    Apparemment c'est pas impossible, mais faut evidemment s'attendre a rencontrer des soucis.

    Le plus sur, s'il s'agit d'un serveur en ligne et que la disponibilite est importante, c'est sans doute de monter un nouveau serveur en stable pour basculer dessus une fois qu'il est pret.
    Apres, si la question d'interruption de service est secondaire (que ce soit un serveur en ligne ou a la maison), le mieux est probablement de reinstaller "from scratch".

    Pour ce qui est des etapes, cela va fortement dependre du contexte: le(s) service(s) fourni(s), les donnees… (probable que j'omette d'autres criteres qui pourraient jouer)

    ++
    Gi)

  • # Debian est bien pour les serveurs et la bureautique

    Posté par  (site web personnel) . Évalué à 3 (+1/-0).

    Bonjour,

    Debian Unstable est, comme son nom l'indique, pas forcément stable.
    C'est à dire que les logiciels changent souvent, et sans forcément en restant compatible avec l'existant. (rien à voir avec les destination serveur ou bureautique, donc)

    Si on veut des logiciels récents, c'est mieux de s'orienter vers Debian Stable, et, d'ajouter les backports, et éventuellement des bouts en testing ou unstable.

    Le retour arrière peut être fastidieux, comme expliqué dans d'autres commentaires.
    C'est mieux de repartir d'une base saine, en Debian Stable.

    Bon courage

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # autre piste

    Posté par  . Évalué à 2 (+0/-1).

    ce n'est pas vraiment un downgrade mais juste un arret d'utiliser la SID

    tu changes sid en stable dans les sources

    sed -i -e 's/sid/stable/g' /etc/apt/sources.list /etc/apt/sources.list.d/*

    du coup plus de mise à jour tant que stable n'a pas rattrapé sid
    ca fige donc tes versions pour quelques temps.

    bon evidemment ca ne va pas corriger un truc qui ne marcherait plus dans sid puisque les paquets de SID seront considérés comme plus recent que ceux de stable

    • [^] # Re: autre piste

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Super 1 à 2 ans sans aucune mise à jour de sécu !

      • [^] # Re: autre piste

        Posté par  . Évalué à 3 (+0/-0).

        sauf si stable rattrape le sid sur ton poste

        ex aujourd'hui
        stable logicielX, version 1.2.1.4
        sid logicielX, version 1.3.4.2

        et quand stable passera à la version 1.3.4.3,
        ton pc prendra alors la mise à jour car plus recent que le sid que tu avais jusqu'a present

        • [^] # Re: autre piste

          Posté par  (site web personnel) . Évalué à 1 (+0/-0).

          C'est justement ce qui n'arrive pas sur une Debian Stable !
          La plupart des logiciels restent stable … dans leur version pendant la durée de vie d'une version de Debian et c'en est un des intérêts.

          Seules les mises à jour de sécurité sont appliquées sur les paquets existants, pas de montée de version (sauf sur certains logiciels : spam, backport, …)

          Donc dans ton exemple 1.2.1.4 passera éventuellement à) la version 1.3.4.3 à la sortie de la prochaine stable … dans un ou deux ans selon.

          Exemple nginx :
          - trixie - https://packages.debian.org/fr/trixie/nginx (1.26)
          - sid - https://packages.debian.org/fr/sid/nginx (1.30 aujourd'hui)

          Très peu de chance qu'un jour Trixie passe à une version 1.30 !

          https://en.wikipedia.org/wiki/Debian#Branches
          et un peu de lecture pour savoir ce qu'est Debian : https://wiki.debian.org/fr/DebianSoftware

          • [^] # Re: autre piste

            Posté par  . Évalué à 1 (+0/-1).

            C'est justement ce qui n'arrive pas sur une Debian Stable !
            La plupart des logiciels restent stable

            Y compris dans leur incapacité à faire le boulot. Très sérieusement, j'ai vécu cela avec la dernière Debian (Trixie) que j'ai eu le malheur d'installer pour qqun en espérant simplifier la vie. Que nenni, des problèmes de soft périmés ou dysfonctionnants alors que leur dernière version Arch fonctionnait du premier coup. Avec Debian, impossible de faire marcher l'imprimante (vieux cups?) et mieux, Grub qui squatte le bios du PC (jamais vu ça en 27 ans de Linux), le bloque au point de ne plus pouvoir y accéder. PC/clavier complètement HS et donc, tournevis, démontage du ssd, formatage, copie de l'Arch sauvegardée, et ça repart…

            • [^] # Re: autre piste

              Posté par  . Évalué à 4 (+1/-0).

              WTF ?

              Grub qui squatte le bios du PC

              c'est pas le bios qui n'a pas de delai pour le boot,
              puis le grub qui n'a pas de delai de suggestion de boot ?

              j'ai deja eu le cas sur des systems un peu veloce,
              rien que pouvoir chopper le bios/efi demande une dexterité et un spam des boutons habituels (suppr, f2,f10…)

              et le grub reglé sur timeout=0 donc idem boot direct

              mais t'es pas un noob, j'aimerai donc savoir ce qui pouvait faire que ton grub squatte le bios :/

              • [^] # Re: autre piste

                Posté par  . Évalué à 2 (+0/-0).

                j'aimerai donc savoir ce qui pouvait faire que ton grub squatte le bios

                En tous cas, j'ai trouvé des traces flagrantes du forfait avec "grub" inscrites dans les réglages du bios (Acer), chose que je n'ai jamais vue ni constatée avec Arch.

                rien que pouvoir chopper le bios/efi demande une dexterité et un spam des boutons habituels (suppr, f2,f10…)

                Bien sûr, ça marche comme ça habituellement mais comme toutes les touches étaient "mortes", les seules actions possibles étaient d'éteindre/redémarrer le PC ou jouer du tournevis.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.