Reprise du message précédent :
Quoi de neuf dans stable ?
A pare côté sécurité ?

@v1ngcent qu'y a t il dans /etc/os-release ?
j'ai deja vu une updates un peu foirée pour laquelle ce fichier est resté le meme malgré une montée de version.

 
https://www.debian.org/releases/tri [...] ew.fr.html ?
 
Pas grand'chose de révolutionnaire, mais bon c'est Debian de toute façon.

 
St'insinuation...
 
A vous lire, on se demande ce que vous faites dans la vie.  

Pertinence de ta proposition ?
 
(Pour te paraphraser avec ton fil créé en doublon d’un qui existe déjà depuis des années)

Debian est connue pour privilégier la stabilité/continuité d'où la rareté de changements très disruptifs, j'insinus ( ) rien de plus

J'écris mes programme avec Ada sur Gnu/linux depuis trente ans ; Et je suis sur Debian depuis 27 ; Alors que j'ai passé vingt ans sur testing ; J'ai jamais eu de rupture sous entendu dans votre propos.

 
  Relisez attentivement.

https://forum.hardware.fr/hfr/Hardw [...] 8190_1.htm
 
Et le sujet que j'ai posté dans la catégorie sécurité de la section Windows à été supprimé.
 
C'est un constat de la mauvaise foi des modérateurs de cette secction de forum.hardware laquelle est sensiblement fidèle à l'imposture de celle de la section discution.

Sauf que dans mon cas...
 

 
T’avais dit quoi ?

 
Windows s'est emparé de mon MBR et à modifié le BIOS à l'occasion d'une prétendu mise à jour de sécurité.

En 1 seconde.

Laisse : c’est le dernier multi en date d’une légende du forum qui n’a pas toute sa tête. Ne te préoccupe pas de lui, c’est le mieux.

Ou plutôt qu’ils en ont marre que tu prennes ce forum pour ton journal intime personnel (il y a le Bloc-notes, Gedit, Mousepad ou tout autre éditeur de texte, pour ça), surtout pour pondre des propos incompréhensibles.

Une mise à jour du firmware UEFI, ça peut se faire par Windows Update, oui.

On fait ce qu'on pneu ; On est pas des chambre à air !  

Je disais ; C'est pas comme si les français connaissaient pas la définition d'un "troll" !

 
Effectivement pas normal une idée pour corriger le problème même si pour moi, c'est rien

réinstaller base-files
 
ou juste extraire du package le fichier /usr/lib/os-release
 
ou copier-coller ça :
 

pluzun !
d'autant que ce fichier os-release peut etre lu/parsé/sourcé par plusieurs programmes pour afficher l'info

après avoir essayé :

problème corrigé a grand coup de cat /usr/lib/os-release  > /etc/os-release
merci

En principe /etc/os-release est un softlink vers -> /usr/lib/os-release, c'est ce dernier qui se fait mettre à jour la tronche.
 
Possible que si on avait un /etc/os-release "en dur" (vrai fichier et non lien), celui-ci se fait conserver durant les mises à jour

J'ai fait la migration vers debian 13 c'est la grosse merdasse, mon menu KDE est vide y a zero applications dedans.
Je vais pas me casser la tête je vais réinstaller.
Même mes icônes en bas ont disparus elles ont été remplacées par des icônes lambda
 

Réinstaller ? C'est totalement useless.

Essaye déjà de faire un apt install kde ou quelque chose comme ça, il doit y avoir un méta package qui installe tout.
Si ça marche toujours pas, purge ta config kde dans ton home, genre .local/config/qqch/kde

Bah elles sont où les femmes nues  
 
   
 
Vous me conseillez quel tuto pour le passage de Debian 12 à 13?
 
 

La doc officielle.

Il y a moyen de faire une simulation de mise à jour d'une version majeure de Debian à une autre ? Histoire de savoir à l'avance si un souci va se produire pendant la mise à jour

Après une recherche, je suis tombé sur des réponses qui disent qu'on peut avec la commande --dry-run et d'autres qui disaient que --dry-run ne s'applique pas à ce cas

--dry-run ne servira qu'à indiquer quels paquets seront mis à jour, c'est tout.
le mieux est d'avoir une machine virtuelle sous debian12, et de la mettre à jour en 13

Sauf que si on veut un résultat plus ou moins fiable la VM doit être configurée exactement comme le système réel qu'on veut mettre à jour.
 
Dans tout le cas il faut prévoir (màj ou pas) un backup; par contre je me posais la question si des systèmes de fichiers qui permettent de faire des "volume snapshot" ou du genre permettraient un "retour en arrière" plus rapide que restaurer un backup externe si la màj foire? Ou c'est une mauvaise idée car le noyau sera mis à jour aussi?

le kernel et tous les services qui tournent en RAM qui se retrouvent avec un système de fichier contenant des anciennes versions, ça me semble compliqué à faire marcher, c'est pas juste une question de snapshot au niveau FS, c'est tout l'OS qui devrait être adapté à cette opération, je ne pense pas que ce soit le cas.

Suffit de booter avec une clé usb netinstall, mode rescue, et faire bon vieux tar du fs.
En cas de problème, même chose à l'envers, on refait le bootloader, et c'est reparti ...

Migration 12 > 13

... j'ai eu la blague du service SSH qui ne redémarre pas.

La raison : pubkeyacceptedkeytypes +ssh-dss dans sshd_config

En résumé, les contournements pour maintenir en vie les clés DSA ne fonctionnent plus.
Il vous vous mettre à jour les clés DSA qui traînent.

Logique au final, il faut virer ces vieilles clés

Il me semble que c'est dans la doc de migration aussi, mais j'ai pas regardé la partie SSH en détail vu que je ne l'utilise pas.

Après, faut pas vous pignoler hein faites l'upgrade et merci bonsoir tout se passe bien dans la plupart des cas et de toute façon vous ne pouvez rien vraiment anticiper faites une image disque si vous avez les miquettes et c'est tout

J'attire quand même votre attention sur le fait qu'il n'y a pas d'upgrade path pour RabbitMQ. Ça va être un sujet pour moi, j'ai déjà migré online mon cluster depuis une version du siècle dernier sur centos 7, donc je suis pas inquiet, je vais passer par des dockers pour les versions intermédiaire nécessaires, ou des paquets debian depuis snapshots si ils existent, a voir.

 
Perso je préfère lire la doc tranquillement avant plutôt qu'une fois l'upgrade faite et qu'un truc est pété. Et je trouve au contraire qu'on peut anticiper une partie des problèmes, la doc de migration est relativement bien faite pour ça.

Moi, ça s'est pas bien passé, comme je l'imaginais

Et comme si c'était pas assez, j'étais loin de me douter que Dovecot avait purement et simplement cassé sa compatibilité avec les fichiers de configuration de la version précédente sans prévoir un outil de migration.

Bon, au moins, j'ai tout cassé et presque tout réparé

Tu ne suis pas attentivement le topic.

Si mais j'avais zappé avec l'histoire du eno0machin
D'ailleurs, j'ai une question à poser en bas du message*

Ça s'est pas bien passé, mais c'est reviendu.

J'ai la famille Dovecot/Postfix/SASL/Sieve/RSpamD pour ma part.
J'ai sué des goûtes, parce qu'il n'y a vraiment aucun moyen de préparer les fichiers de configuration au passage à la 2.4(.1), vu qu'il n'y a aucun moyen de les vérifier au préalable.

Je dois encore comparer les fichiers et remettre (ou pas) certains paramètres (qu'il faut évidemment "convertir" ) qui étaient répartis dans au moins 10 fichiers différents (et que j'en profite pour mettre tout dans le même fichier, vu le peu de paramètres au final)

*C'est étrange mais j'ai maintenant 2 services qui gèrent le réseau, dont un qui est évidemment pas content et qui râle.
J'ai en effet systemd-networkd qui démarre avant networking.service et networking.service qui râle parce que l'adresse IP est déjà prise.
Du coup, ma question : Lequel garder et lequel virer ? Quels sont leurs avantages / inconvénients ?

Networking c'est l'ancien système (/etc/network/interfaces etc.), avec bcp de tutos dispo vu l'ancienneté, ça fonctionne encore si on a peur de casser des trucs ou pas envie de s'ennuyer à apprendre systemd, mais en cas de pépin faut lire la doc d'une multitude d'outils (wireguard, dhcp, routes...) pour piger où ça foire.
 
Systemd-networkd c'est le nouveau (/etc/systemd/networkd/*), tout est centralisé façon systemd (un seul outil pour gérer dhcp, vpn, etc.) mais ça demande de potasser la doc pour mijoter sa configuration, car moins d'aide et de tutos dispo.
 
Le résultat sera le même dans la plupart des cas.