Debian-facile

Merci raleur
d'avoir corrigé mon erreur (je devrais me relire attentivement),
et surtout pour ces explications fort intéressantes...

Heureusement pour moi grub présente rarement de telles évolutions car j'essaie souvent des nouvelles distributions par ce procédé (donc généralement un grub de lancement plus ancien que celui de la distribution visée) sans rencontrer de problème.

J'ai opté pour cette méthode car je ne fais que décompacter l'iso de la distribution visée, sans aucune installation et il n'y a pas de MBR : est ce que chainload fonctionnerait quand même dans ce cas ?

sinon, c'est qu'il y a une option "exotique" sur le choix du noyau au démarrage dans /etc/default/grub (GRUB_DEFAULT ?, je n'ai plus cela en mémoire, il suffira de chercher en cas de besoin)

sur le nombre de gens qui ne lisent pas suffisamment attentivement ! (dont je suis !)
Voir la discussion https://debian-facile.org/viewtopic.php?id=32789
Vérifie --- et la présence du paquet linux-image-amd64. (pas linux-image-5.10.0-20-amd64  !)
Bonnes fêtes de fin d'année à tous

Bonjour,
Je pensais que des experts réagiraient et n'en étant pas un, je me suis abstenu jusque là !...
Alors je vais tenter d'écrire ce que ce post m'a inspiré et désolé si c'est stupide : cela permettra peut-être d'avancer le sujet.

Le besoin, les critères de choix du routeur, les fonctions nécessaires ?
Quand je me suis procuré un routeur pour étendre mon réseau local filaire sur la box, mes seuls critères étaient le nombre de ports gigabit, la compatibilité de l'alimentation avec celles que j'avais déjà (en prévision d'une défaillance éventuelle) et vaguement la pratique de l'installation... Un truc à une vingtaine d'euros me donne totalement satisfaction.
Pour raccorder bêtement 2 éléments, qu'est ce qui justifie un matériel pro sophistiqué ?
Y a-t-il même besoin d'un routeur : une configuration statique avec un raccordement direct ne serait pas possible ?

un oubli : le Wifi ?
la TV et le disque n'ont jamais besoin d'accéder à internet via le smartphone même ponctuellement (MAJ de firmware, ...) ?

C'était pour faire avancer le schmilblick !

Bonjour,

super réactivité !
Merci à tous et bravo :
grâce à vous, un peu moins ignare aujourd'hui (et j'aimerais aussi : bien moins que demain, mais là c'est moins sûr !)...
J'ai réalisé  l'écart qu'il y a entre le méta-paquet "linux-image-amd64" et les paquets "linux-image-N°_version-amd64" que je confondais plutôt.

J'ai donc installé linux-image-amd64 (version 5.10.149-2) via Synaptic qui a installé aussi linux-image-5.10.0-19-amd64 (version 5.10.149-2) sans poser la moindre question.
Je note que cela n'embarque pas les paquets linux-headers-common et linux-headers-amd64 : je savais déjà qu'ils n'étaient pas nécessaires pour upgrader le noyau mais je conserverai probablement l'homogénéité de leur version pour faciliter ma gestion du système lors du nettoyage des noyaux anciens.
La commande  "uname -a" me répond maintenant : "5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux". Parfait !

L'essentiel pour moi est d'être notifié de la disponibilité d'un nouveau noyau "stable" ou "stable-sec". Je garderai de toute façon la maîtrise du moment et du contenu de la mise-à-jour.

Je pense donc que cette discussion pourra se clore en "résolue" : je le ferai à la sortie du prochain noyau (le -20 bientôt ?) qui devrait me permettre de vérifier que tout se passe comme prévu.

Merci à tous pour vos remarques.

@ubub : difficile de rester zen quand on a commis ce genre de bourde... De plus
* quand la commande "man extundelete" (je suis en version 0.2.4) répond

* quand on cherche sur le web comment fixer le dossier pour loger les fichiers récupérés et qu'il y a des divergences (les options auraient bougé dans le temps ?),
dur de pas paniquer.
Je ne connais pas TLDR, je regarderai cela plus tard. Intéressant si cela peut enrichir tous les man.
Pour le moment je me focalise sur la récupération de mes vidéos.

@raleur : cela semble être le cas mais c'est surprenant et cela mériterait un bel avertissement...
Dans cette situation, le conseil unanime est de passer en "live". Je suppose que là aussi le démontage se produirait et purgerait le journal.
Sur le web, j'ai trouvé une page qui conseille de modifier le montage de la partition en "read Only".
Me connaissant, pour le prochaine écrasement, je conserve le script suivant (/dev/sdX étant la partition dans laquelle rechercher les fichiers effacés) :

@Croutons : c'est effectivement ce vers quoi je me suis tourné. J'ai pas mal galéré pour arriver à le lancer...
Premier obstacle, il ne propose pas de rechercher les partitions sur SSD nvme. Il faut ajouter la partition ciblée en option pour qu'il la propose comme seule possibilté de recherche.

Ensuite fixer les options...
Je n'ai pas modifié sa proposition :

J'ai réussi à sélectionner des types de fichier (frapper espace coche ou décoche lors du balayage) :

Comme l'incident s'est produit à la racine et que la partition est maintenant vide, je suppose que le choix suivant n'avait pas d'importance :

Puis quelques heures de patiences (350 GB à explorer...)
pour un résultat plutôt décevant : certes beaucoup de fichier mp4 retrouvés (bien plus qu'il n'y en avait d'écrasés !), mais
* aucun nom conservé
* beaucoup de vidéos totalement illisibles
* beaucoup de vidéos démarrent bien mais deviennent vite illisibles. J'ai même retrouvé des débuts de séquences effacées depuis longtemps !. C'est malheureusement le cas de la majorité des clips que je voulais récupérer.
* quelques unes seulement sont intactes et lisibles jusqu'au bout....
Mieux que rien mais pas terrible. Décevant. Je ne vois pas quelle(s) option(s) modifier pour faire mieux (j'ai bien obtenu des mp4)

Je vais essayer aussi "foremost" mais je suis pessimiste....

Un petit point après pas mal de recherches et d'expérimentations....

Pour ne pas perturber mon sytème tout beau tout neuf, j'ai effectué mes essais sur DFL10 en live...

* sur l'idée de retrouver l'état DFL9 (merci otyugh) :
j'ai d'abord installé le paquet  murrine-themes stretch (version 0.98.11)  en vain pour réaliser ensuite que la version buster est identique (version 0.98.11) !
mais j'ai poursuivi l'idée avec gtk2-engines-murrine   (0.98.1.1-6 sur stretch / 0.98.2-2+deb10u1 sur buster ) présent nativement dans DFL10 :
suppression  (avec arc-theme et numix-gtk-theme qui en dépendent), installation via GDebi de gtk2-engines-murrine (0.98.1.1-6) https://packages.debian.org/stretch/amd … e/download
et murrine-themes  : échec, fond clair uniforme.
Je crois que otyugh a raison : c'est en aval, voire dans Thunar lui-même que ça a bougé... Sans espoir !

* J'ai aussi regardé  ce que je pouvais obtenir du look Emac... (la suggestion de --gilles-- : merci).
Toujours sur DFL10 live vu l'ampleur des modifications ...
J'ai jeté l'éponge sur l'installation de Mojave-gtk-theme.  J'ai pourtant essayé de suivre à la lettre les instructions d'installation mais pas moyen d'exécuter correctement le script install.sh, même en retouchant dedans les appels à parse-sass.sh et render-assets.sh... Il manque encore pleins d'autres élément dans des répertoires que je n'ai pas été capable d'identifier.
J'ai poursuivi en regardant des tutoriels MacBuntu, métamorphoser Ubuntu en macOS, Compiz... : ça passe toujours par l'installation de nombreux outils (je me demande si ça ne revient pas à passer à Gnome ou KDE). Trop lourd et résultat incertain. Je préfère laisser tomber.

* J'ai poussé les recherches en anglais (autre suggestion de --gilles--) et trouvé cette page "Thunar - re-enable alternating grey background lines in list view" :
L'explication : option retirée dans GTK3 rendant les thèmes inopérants !
Puis j'ai tenté d'appliquer le palliatif proposé : aucun dossier .theme dans ma machine !, par contre  4 fichiers gtk-widgets.css dont un /usr/share/themes/Blackbird/gtk-3.20/gtk-widgets.css (et justement, j'ai sélectionné blackbird dans Gestionnaire de fenêtres / Style !)
J'ai donc ajouté à la fin de ce fichier ces lignes (recopie du palliatif mais en homogénéisant strictement la syntaxe !)

Après re-démarrage, rien de changé !

Messieurs les forts en thèmes : au secours !

Bonsoir,

j'ai voulu en avoir le cœur net : sauvegarde de la configuration effectuée pour mon copain (clonezilla).
Ce qui me tarabustait : en live, lors de la préparation, je n'avais jamais eu de souci avec les repérages sda,sdb et sdc la clé, j'en étais sûr car je jonglais sans cesse de l'un à l'autre...
J'ai donc voulu refaire exactement ce que javais effectué , la même installation.
Au formatage manuel, RAS tous les repères corrects et en final redémarrage OK !
Donc non reproductible, la faute "à pas de chance" ce qui confirme vos réponses :

Juste un point que je n'avais pas vu lors de cette manipulation : en ré-installant, le swap est reformaté et change de UUID ! La restauration de clonezilla a nécessité une correction dans FSTAB (mais clonezilla l'annonce clairement au moment de la restauration).

@otyugh : aucun bug !, oui : sans doute un parasitage lors de l'établissement de la map disques.
Je serai désormais plus vigilant aux adresses, pas seulement aux partitions et à leur taille...

@Membre : effectivement, en cas de problème il vaut mieux refaire. C'est bien parce que l'interversion de disques était flagrante que j'ai tenté la correction et si ça n'avait pas fonctionné immédiatement, je n'aurais pas insisté.
J'ai testé dans la foulée l'installation simplifiée : effectivement, bien plus simple , elle évite plein de questions peu utiles.
Juste pour moi, l'option FTP pour les dépôts serait sans doute reportée à corriger en ligne.
Il faudrait aussi que je vois pour le MDP administrateur (qui est demandé en mode expert).

Merci encore et désolé d'avoir soulevé un faux problème.