Reprise du message précédent :
nope, obligé de copier d'abord, puis partionner/formater, puis recopier

 
mes résultats des MAJ automatiques (unattended upgrade) dans le passé :
 
premier changement (debian 10 vers 11), changement du nom de l'interface réseau, le serveur DHCP qui démarre plus (vu qu'il était configuré pour ladite interface) et donc le réseau complet de la maison qui défaille.
 
deuxième changement (debian 11 vers 12), problème à la MAJ de python qui soudainement fait consommer 100% du CPU au serveur web, pas de bol, l'interface d'admin est en python, de même que plusieurs services (radicale par ex). Fin de la MAJ prudemment à la main.
 
Je vais donc patienter un peu.

Ce n'est pas obsolète d'utiliser cette nomenclature /dev/sdx ? (surtout que cela peut changer en fonction des démarrages/nombre de périphériques branchés). Il vaudrait mieux utiliser les UUID.

Ah mince.

C'est tout à fait vrai et j'utilise les UUID, sauf pour df pour avoir la place disponible sur le disque. Après faudrait que je regarde si df ou autre veut bien les UUID, ça pourrait m'éviter de tout copier etc... A creuser.

Edit: miracle, ça semble le faire. Allez, je modifie le script backup et basta. Merci de m'avoir donné l'idée.

dans /dev/disk/by-uuid/ ce sont de simples liens symboliques, non ? Donc ça devrait marcher à peu près partout

c'est en effet recommandé de mettre les uuid dans le fstab
également quand tu crées un volume raid avec mdadm ou zfs.

Ah ben tiens, encore un truc que je connaissais pas. Merci, ça peut servir.  
 
Et pour le fstab, mes disques ne sont pas dedans.

Le 13 va peut-être te porter chance.
 

"5.1.16. Network interface names may change"
 
merci systemd
 
voir https://www.debian.org/releases/tri [...] may-change
 
sinon, un petit net.ifnames=0 dans le grub et eth0 reste eth0.  
#MakeEth0GreatAgain

C'est le système D contre les bugs systemd?

go !

"trixie is now syncing to a mirror near you! Image torrents are up and the bandwidth graphs are looking healthy https://www.accum.se/technical/stat [...] nitordata/ "

et la derniere news qui cloture officiellement la mise en prod
 
Debian 13 "trixie" has been released, thanks to everyone involved! "trixie" images are available for download at https://www.debian.org/distrib/ or you can run apt full-upgrade as always ;-)

si tu n'as pas le /dev/sdb1 ... tu peux toujours tenter le « sudo ln -s sdb /dev/sdb1 » pour voir

hop, mon serveur chez ikoula mis à jour de debian 12 à 13, pas de souci particulier

j'ai angoissé un chouilla pendant le reboot car il mettait plus de temps que d'habitude à remonter.. mais il a repris vie, finalement.
(un check du fs au boot qui a mis un peu de temps)

 
dans le manpage:  
 

 
Trixie dans ToyStory ne fait que des conneries aussi

Upgrade de mon premier serveur ok au boulot. Un truc très pénible par contre, c'est un serveur de backup sur lequel j'ai un LVM par client, donc 26 volumes dont certains de plusieurs dizaines de Tb.
Très souvent au boot le truc timeout pendant le mount et je me retrouve avec un emergency shell    
 
A part rajouter un script qui mount les partition une fois booté, il y a qqch à faire contre ce genre de problèmes ?

ce sont des disques locaux ou un SAN ?

 
Locaux. Je crois que je vais rajouter un service au démarrage qui monte les volumes

C'est quoi qui prend du temps ? Ca fsck ? Quel type de FS ?
Parce que LVM est pas censé être lent (enfin j'ai jamais eu ce genre de lenteur à ce niveau là).

 
C'est du XFS, ça prend juste du temps au mount mais comme les partoches sont remount toutes les morts de pape, peut être qu'il faut un check

Bizarre, xfs est plutôt avare en fsck en général (de mémoire y a même pas de commande pour).

 
Je sais bien, mais les gros volumes de plus de 10Tb ont tendance à prendre un peu de temps mais pas à chaque coup.
Après, ça reboot pas souvent non plus au final donc bon...

t'as pas de log dans /var/log/fsck/ ?

 
nop

Tiens, j'ai eu un renommage de mes interfaces réseau sur une des machines
 
ens4f0 -> ens4f0np0
ens4f1 -> ens4f1np1
 
A part faire chier le monde, c'est quoi l'idée ?

selon lennart, c'est censé etre "prévisible" ..
pour l'instant, le seul qui l'est vraiment, c'est eth0

 
sont marrant avec leur doc... j'ai lu le truc et c'est pas plus clair

voila...
dans la doc de l'update, au chapitre "5.1.16. Network interface names may change" :

 
et j'arrive plus à retrouver, mais il ya une raison "officielle" de pourquoi ce suffixe en np0 est rajouté  

ha tiens, une autre bizzarerie lors de l'update debian 12 -> 13
cette fois avec mdadm

il s'agit d'un serveur sans systemd, avec 2 disques en raid1 soft (mdadm)
quand le paquet mdadm est mis à jour (version 4.4-11), ya un beau warning:

une fois le message validé, le nouveau paquet s'empresse de supprimer /etc/cron.d/mdadm, /etc/cron.daily/mdadm, /etc/init.d/mdadm
("removing obsolete file", qu'il dit)
putain..  

edit: bon. faut que je simule cette situatiion dans une vm deb12 avec  2 disques en raid1 et que je la passe en deb13, voir ce que ca donne.

Peut être que oui, peut être que non et bonne chance

cette histoire de renommage d'interface imprévisible, y'avait pas déjà le même délire à la migration précédente ? Il me semble m'être déjà fait avoir là-dessus

Absolument

Vu ce que vous dites ça doit être une belle galère encore... Et je me demande si ça introduit pas des vrais risques aussi, genre une machine (en milieu pro) avec différents réseaux séparés physiquement qui ont différents droits genre accès internet oui/non; accès à certains espaces de stockage; ... ?

c'est pas tant les droits d'accès qui vont poser souci, que la machine qui va devenir complètement inaccessible. Mais bon tout le monde a son ilo/idrac ou équivalent bien configuré et testé avant la migration donc ça devrait aller, juste un peu de temps perdu

Ah oui, machines configurés à distance, j'y pensais même pas.

 
tout est en remote de mon côté. Et encore mieux aujourd'hui en home office, update via VPN  

Bon, selon les commandes proposées ici pour lister les noms des cartes https://wiki.debian.org/NetworkInterfaceNames#migration et comme mes machines sont toutes en bonding, je modifie mon fichier de conf réseau en mettant une des interfaces en enoX et l'autre en enp103s0f2 comme ça il y en a au moins une de bonne après reboot

EDIT: bon bah ça n'a quand même pas fonctionné pour le serveur de ce soir on est tombé sur eno3np2 et eno4np3 parce que fuck you avec les conventions de nommage

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