Reprise du message précédent :
J'ai fait le ménage dans /home/.snapshots hier pour gagner un peu de place (/home n'avait pas réellement besoin d'être sous snapshot btrfs)
Aujourd'hui, je vois des messages :

dmesg me dit gentiment "BTRFS error (device sda2): '@/.snapshots' is not a valid subvolume" (essayé avec ou sans le .)
J'ai plus rien dans /.snapshots.
./.snapshots a reçu un chmod 750
btrfs-assisant n'arrive pas à trouver la config snapper, je ne peux pas en recréer une car une existe pour le même nom/volume.

fstab:

En cherchant dans /var/log/snapper.log, une ligne fait mention de /etc/default/snapper, et liste "root home" en tant que config. Hors j'ai plus home, et root semble bancal.

Autre message:
Échec de la création de la configuration (creating btrfs subvolume .snapshots failed since it already exists).

Dois-je tenter un btrfs rm /.snapshots ?
[edit] il veut pas faut démonter /.snapshots/151 avant de tenter de le supprimer.

Pour être franc, aucune idée, mais depuis que j'ai vu les graves problèmes de BTRFS au niveau gestion RAID et depuis que RedHat a viré ça de son installeur, je ne comprends pas pourquoi les gens veulent toujours utiliser ce FS

Btrfs est en train de revenir via fedora il me semble.
Et pas vu remonter de soucis sous opensuse ou c'est integré en natif.

Après perso je n'ai jamais utilisé je préfère ext4 n'ayant pas besoin de snapshot.

Le besoin initial était d'éviter d'avoir à se prendre la tête en cas de:
1) pas de temps
2) mise à jour foireuse
3) systemd qui veut pas démarrer l'os après une mise à jour.
 
btrfs+snapshot semblait la solution moins prise de tête et "rapide" pour revenir à une ancienne version, sans avoir à sortir la trousse de secours.
Mais quand ca pète, bah...trousse de secours obligatoire (et c'est rare, donc j'oublie à chaque fois entre 2 pétages )
 
Faire du dd/clonezilla nécessite un reboot et du temps "d'indisponibilité" de la machine. Vous avez une autre solution pour faire du backup régulier d'un os ?

Perso je ferme tout les logiciels et je laisse tourner BorgBackup vers HDD externe. Généralement - vu que c'est incrémental - ça prend genre 2 minutes maxi.

Et pour la restauration ?
Te faut un minimum un os qui marche, non ?
 
Faire le backup n'est pas le plus gênant, c'est plutôt les étapes qu'il faut faire pour la restauration qui me pose problème. Comme dit précédemment, si je ne note pas les commandes, j'ai tendance à oublier.

Si je dois restaurer le système complètement (arrivé une fois) j'efface le SSD, j'installe une Debian minimale juste pour GRUB et le partitionnement (on pourrait faire autrement bien sûr ), puis je démarre une Debian depuis clé USB, je branche mon HDD de backup et demande à Borg (prévoir l'exécutable sur la clé USB de secours si on a pas internet!!) de tout recopier (borg extract ou du genre).

C'est pas génial, génial mais c'est vraiment en cas de catastrophe ce qui est heureusement très rare. La seule fois dont je me souviens c'était de ma faute, mauvaise commande en tant que root...

Si c'est juste pour récupérer un/quelque fichiers il y a "borg mount", un peu comme le "mount" classique sauf que ça accède (en lecture seule) aux sauvegardes. Ca c'est vraiment pratique.

Perso je n'ai jamais eu de cas où ma machine ne boot plus suite à des maj ou des install (mes machines sont en testing) . Pareil au taf où j'ai plusieurs dizaines de machines sous debian (stable) et alma 9. Les seuls cas où une machine est devenue indisponible, c'est un ssd ou une carte mère qui claque

Pour les backups c'est des bêtes rsnapshot de / et si besoin de restaurer un système complet je boot avec une debian live. En 10 ans de boîte là, ça ne m'est arrivé qu'une fois je crois. Idem dans mon ancien taf où on avait plus de 1000 serveurs. Certes les disques étaient en raid mais ça n'empêche pas les blagues.

Bref, dans tous les cas, si un système est en rade, je m'en fiche un peu qu'il soit indispo sur le réseau ou qu'il faille le reboot

(Croisé avec le TU uname -a)
 
Apparemment, Debian a décidé d’arrêter la compilation du noyau pour la version i386 depuis deux mois, et personne n’était au courant ?
 
C’est « Tonton Fred » (Bezies) qui s’étonnait de ne pas voir arriver le 6.12.x sur sa sid installée sur son EeePC, et qui a eu comme réponse un résumé de cette annonce, concernant le noyau et d’autres paquets non précisés.
 
Donc, à moins de recompiler soi-même le noyau (via KRN ?), il est probable que l’existence de Debian et toutes ses dérivées en 32 bits prenne fin (et rende encore plus difficile le maintien de machines encore fonctionnelles et aptes à servir d’appoint, mais pas compatibles 64 bits)…

Snapshot LVM (dumpé dans un fichier, pas gardé en tant que snapshot dans LVM).

 
Ça fait des années que i386 est voué à mourir. Les cpu sont x64 depuis des lustres et garder une équipe pour maintenir des paquets 32bit pour une poignée de gens qui tournent avec des machines antiques n'a pas vraiment de sens.
Un peu comme les gens qui viennent nous voir au taf avec des disques durs IDE en train de claquer et qui nous demandent de l'aide pour récupérer leurs data...   en général je leur propose un marteau pour finir le disque dans les règles de l'art

Ils auraient pu monter la barre à i686, vu que même Linus a abandonné la prise en charge en amont du i486 pour le noyau, il y a un ou deux ans. Rester sur le i386 dans ces conditions…
 
(Blague à part, ils auraient dû nommer ça « x86-32 » au lieu de « i386 », parce que ça m’étonnerait que ces paquets « i386 » soient encore compatibles avec des CPU de la génération du 80386…)

 
Je pense que tu ne renommes pas une archi comme ça..
 
Chez Debian la branche i386 est ultra vieille (à l'époque ou le x86_64 n'existait pas encore mais le ppc oui )

Merci, c’est bien ce que je cherche à faire
 
j’ai suivi la manip, ca semble fonctionner puisque j’ai bien mon "bridge0" monté et mon PC hôte qui obtient une IP dessus et non plus sur enp4s0
 

 
J’ai mis la config pour la VM en bridge et sur bridge0... mais elle n’obtient pas d’IP alors que réglée en DHCP
une idée?
(j’ai essayé sur une VM kali et une windows, même soucis, elles ne récupèrent pas d’ip)
 

J'y connais rien , mais au pif: Bridge c'est pas comme un câble réseau virtuel direct, autrement dit le PC hôte ne s'y intéresse plus et il faut un serveur DHCP sur la VM Kali? Ou régler une IP fixe?

Avec les bridges, il faut vérifier que /proc/sys/net/ipv4/ip_forward a bien été mis à 1.

Ce qui va relier la VM aussi au réseau local/internet (en supposant que le PC hôte y est connecté) non?  Prudence selon ce qu'on fait.

j'ai essayé avec une IP fixe, sur kali et win, ça n'a pas aider

c'est déjà à 1

c'est très exactement ce que je veux faire, que cette VM soit sur le réseau au même titre que la machine hôte et qu'elles aient chacune une IP distinctes sur ce réseau

Ah ok, autant pour moi. Je ne saurais te guider, ces histoires réseau ça me prend toujours la tête...

 
  y'a besoin de l'IP forward alors que la machine ne fera pas de routage IP ?

sinon sur vbox je mets simplement "bridged adaptator" et je choisi l'interface réseau de l'hôte (y'a pas de création de pont au préalable ou quoi),
(dans avancé je prends intel 82540em + deny + une mac + connected)
et je configure le dhcp pour qu'il lui donne l'ip que je veux en fonction de la mac
et tout le monde est dans le même sous réseau local

Ben dès que tu as plusieurs interfaces réseau sur la même machine qui ne sont pas calées sur le même sous-réseau ... ip_forward est ton ami

« j'ai le même à la maison » © les inconnus ... usage quotidien pour mes VM Win sous virtualbox pour ma part.

 
mais un bridge c'est juste plusieurs interfaces physiques et (éventuellement) une seule adresse IP, il n'y a pas de routage

Ouais sur Virtual box j’y arrivais sans soucis justement... je ne comprends pas que ce soit si compliqué avec Virt Manager, mais s’il le faut je réinstallerais vbox

là mon but c’est d’avoir une seule carte physique, et plusieurs IP derrières (le pc hôte, une VM, etc...)

J'ai pas la solution à ton souci, mais pour t'aider à comprendre, tu peux lancer un tcpdump -i ${interface} sur les différents éléments pour voir ce qui se passe (ou ne se passe pas, et où) ça t'aidera à y voir plus clair.
 
A lancer :
- dans ta VM
- sur ton bridge
- sur ton interface de sortie
 
Tu sauras où ça bloque

pareil, quand j'ai ce genre de souci, j'arrive toujours à voir ou ca bloque avec tcpdump
(car en regardant sur plusieurs étapes, on voit ou les paquets passent, et à partir d'ou ça ne passe plus)
généralement, il manque une regle de forward

 
bien sûr mais au niveau de l'hôte il n'y a pas plusieurs adresses IP sur plusieurs subnets (ce qui est le use case pour ip_forward)

et +1 pour tcpdump aux différentes étapes