Reprise du message précédent :
Salut  

Depuis la MAJ de mon conteneur LXC à base de Debian vers Trixie, j'ai ce message quand je fais un apt update :

Attention : https://downloads.plex.tv/repo/deb/ [...] InRelease: Policy will reject signature within a year, see --audit for details

Une idée de comment je peux corriger ça ?
Merci par avance

La clef est dans un format qui sera bientot rejeté. Probablement SHA1.

Il faut regarder dans la doc de plex si ya pas une nouvelle clef.

tu peux essayer: curl https://downloads.plex.tv/plex-keys/PlexSign.key | sudo apt-key add -

Aussi faudrait voir la tronche du source list.

J’ai ça :

Passage à Trixie ce weekend, et plus galère que la précédente.
Reboot et pas de sessions Xorg.
Pas de message d'erreur, pas de crash, rien d'anormal dans les logs, juste TTY et login    
Aucune solution nulle part... c'est ce topic qui m'a aidé https://forums.debian.net/viewtopic.php?t=159860
 

Ce n'était pas obligatoire avant, mais si ça le devient faudrait que l'installeur installe son installation.
 
Deuxième merde, impossible de se log en root@mariadb, tout essayé... alors qu'un simple utilisateur, ça marchait très bien.
La solution pour moi a été  

Tout le reste ne marchait pas.
Genre : SET PASSWORD FOR 'root'@'localhost' = PASSWORD(''); non...  
ou : UPDATE user SET authentication_string = PASSWORD('') WHERE user = 'root'; non plus.

Pour les histoires de noms d'interfaces réseau, il y a une potentielle logique. Mon serveur qui était en eno1 eno2 etc est devenu
 

 
donc "suffit" de rajouter np0 np1 np2 etc en fin de nom

Bon, je vais attendre un peu.

En fait, sur ce serveur, je n'ai qu'une interface (eno0), que dois-je faire et dans quel ordre si je veux faire ma mise à niveau ?
 
Modifier /etc/network/interfaces et transformer tous les eno0 en eno0np0 ?
Mais du coup, dans quel ordre on doit faire ça si on veut pas perdre la main sur la machine distante ?

t'es meme pas sur que l'interface sera renommée..  
ptet ben qu'oui, ptet ben qu'non
si ça arrive, ca sera au reboot.

je reboot un serveur maintenant
j'ai upgrade le tout, j'ai modifié le fichier /etc/network/interfaces en gardant une interface en eno3 et j'ai modifié eno4 en eno4np3 (c'est du bonding) en théorie il y en aura au moins une de bonne
Dans tous les cas j'ai un bmc pour faire du remote si la machine est hors réseau

EDIT: ça n'a pas fonctionné, il a choisi de renommer eno3 en eno3np1

bref, je ne comprends pas cette convention à la con

Je vais attendre que tout le monde se vautre.

Fais un script qui :
- Detecte le nom de l'interface
- Créé le /etc/network/interfaces approprié (ou en colle un pré-ecrit au bon endroit)
- Reboot
 
Sinon je me demande si on peut pas mettre simplement tous les noms d'interface possibles dans le fichier interfaces, comme ça le moment venu, celle avec le bon nom s'y trouve et les autres n'existent pas donc pas d'interférence

Ils auraient quand-même pu faire un script de migration.

Oui ou même rien qu'un script qui prédit de façon fiable les futurs noms des interfaces, ce serait déjà ça... Vraiment bizarre.

Bon si j'ai bien compris l'affaire, il faut juste rajouter np0 np1 np2, etc sur les interfaces connectées et dans l'ordre d'apparition.

Par exemple sur ma dernière machine j'ai 4 interfaces mais seulement 2 online (eno3 eno4), les noms sont donc eno3np0 eno4np1

Donc avec une seule interface eno1, on devrait se retrouver avec eno1np0

Tu sais comment est déterminé/où est stocké l'ordre d'apparition ?

Salut  
Je ne saisi pas en quoi les renommage des interfaces peuvent poser problème.
Vous avez des scripts codés en dur sur les noms d’avant la migration ?
 
J’ai mis à jour deux hôtes pve vers trixie ainsi que plusieurs VM et LXC, j’et je n’ai pas vu de modification des interfaces.
 
Sinon sur l’un (hôte Proxmox) l’ethernet est nommé enp1s0, et sur l’autre c’est enp86s0. (Sur les deux machines je n’ai qu’un seul port réseau).
Je ne comprends pas non plus la logique de nommage des interfaces    
 
Je trouvais plus simple à comprendre les eth0 pour le premier port , eth1 pour le second , eth2 pour le 3ème etc…

 
 
Bah le problème c'est que mes machines qui sont en remote changent leur nom d'interfaces une fois rebooté et ça ne correspond plus à ce qu'il y a dans le fichier /etc/network/interfaces. Donc tu perds le réseau

 
aucune idée mais dans mon cas, elles sont deux à être connectées, eno3 et eno4 donc c'est dans cet ordre là

ha oui merde... c'est la merde    
je pensais que c'était ce qui est dans /etc/network/interfaces qui donnait le nom aux interfaces...
C'est vraiment la misère alors...
J'ai eu du bol, car j'ai MAJ à "distance" depuis mon canapé    
mais du coup, qu'est-ce qui fait que chez certains, les noms d'interfaces changent et chez d'autres non ?

Apparemment c'est un secret, justement

la machine que je viens de faire a gardé ses noms d'interfaces

Sur cet article, il est donné une commande pour vérifier si le nom de l'interface change :
https://www.linuxtricks.fr/wiki/deb [...] -trixie-13

udevadm test-builtin net_setup_link /sys/class/net/ens18

 
Bon il n'explique pas ce qui doit être fait si l'interface change de nom...

udevadm test-builtin net_setup_link /sys/class/net/ens18

 
C'est là la blague
 
Sur ma machine là
 

 
si je fais un ethtool sur les 2 noms, ça fonctionne mais par défaut elle a gardé eno1

arretez de souffrir, mettez un

dans /etc/default/grub et retrouvez eth0 qui ne change pas, lui

 
et pour cette vilaine blague qu'a fait le paquet mdadm, j'ai pu simuler la chose dans une vm, et meme comportement.
en copiant avant les fichiers qui sont supprimés, on peut rétablir le services et les cron, et ça fonctionne.
sur mon serveur, j'ai rétabli ces fichiers, et tout marche normalement.. ouf !

 
on vit avec notre temps nous monsieur
 

 
sans systemd (voir commentaire ci-dessus )

et du coup tu subis les crises d'humeur de systemd, et ses manies de tout absorber et tout changer régulièrement.
et tu stresses à chaque reboot si ceci ou cela va changer.
moi non

edit: on peut aussi avoir systemd et juste désactiver ce nommage """prédictif"""
faut avouer que l'interface réseau qui change de nom aléatoirement: c'est dangereux et complètement con

udevadm test-builtin net_setup_link /sys/class/net/ens18

 
Bah rerégler la conf de la carte si tu as des trucs spécifique (ip fixe, passerelle etc...)

 
ce qui devient compliqué si tu ne sais pas quel nom la carte va prendre après reboot

 
Ah bah oui dans ce cas là faut aller physiquement

Y'avait pas une histoire comme quoi les clés doivent être ajoutées séparément et pas comme nom de fichier dans sources.list? Donc +1 pour voir ce fichier.

Il y a un bus jusqu'à Gravelines ?

Ca fait des lustres que j'ai pas loué un serveur là bas mais ya pas une console KVM / IPMI ?

Pas sur un Kimsufi 10 ans d'âge.

Tu peux quand-même booter à distance sur une image disque "rescue", puis monter ton filesystem et corriger ...

Bon bah dernier test selon la doc debian
 
Avant et après apt upgrade, full-upgrade
 

 
me donnait comme nom "eno4"
 
je reboot et l'interface est passé en eno4np1
 
donc la commande magique de la doc debian ne sert à rien

Oui, si tant est que je reçoive le mail avec les infos de connexion, mais c'est un autre sujet.

ptet car la version actuelle udev n'est pas celle installée dans l'upgrade, et donc ne répond pas la meme chose ?
(bref c'est trompeur   )
 

 
normalement, tu dois pouvoir selectionner le rescue sans attendre d'email je crois. je sais plus, ca dépend du type de serveur
en prod j'ai des rise, et pas besoin de confirmation par mail.
mais oui, au pire, si reboot et pas de reseau, tu reboot en rescue, tu montes ton filesystem et tu peux corriger /etc/network/interfaces, fonction de ce que tu trouveras dans le dmesg ou kern.log

Y a de l'ambiance ici    
 
Bizarre j'ai rien dans /etc/default/grub, et pourtant j'ai toujours ma bonne vieille eth0.
Et oui, je suis en unstable depuis des lustres. Bon attention y a une mise à jour systemd dans le tas à faire...

Ça ne me rassure pas pour mon uphrade de proxmox sur mon dedie ovh...