P'tite anecdote qu'il me faut vous narrer.    
 
Ma machine pour adulte (ryzen 5950x / radeon 6800xt) a un DD nvme dualboot Win10 / KDE Neon ... avec le Win10 aux pâquerettes : bloqué dans l'outil de réparation sans voie de sortie.
Donc, opération réinstallation ... et la création de la clé de boot d'install Win10 me gave parce qu'un simple « dd if of » ne fait pas le boulot (clé non bootable).
 
Alors, j'ai fait la manip' suivante :  

• Boot avec la KDE Neon Live
• Installation de gcc et make (pour l'installation du module virtualbox)
• Download et installation de virtualbox
• Création d'un fichier rawdevice sur le nvme pour virtualbox (vboxmanage createmedium disk ...)
• Création de la VM avec l'ISO Win10 (copié dans /dev/shm) et le rawdevice  
• Démarrage de la VM sur l'ISO Win10
• Suppression des partoches c:\ et restauration/réparation windows
• Installation des fichiers Windows sur la zone nettoyée
• Arrêt de la VM
• Montage Linux de la partoche Windows pour y déposer les pilotes de la carte réseau 10 Gbs
• Shutdown de la KDE Neon Live
• Reboot Windows pour finaliser l'installation

... et voila !  
Un Windows tout neuf sans faire de clé boot.
J'ai dû faire le même genre de manip' sur une autre machine pour des raisons de windows en vrac, mais là le Linux était sur un autre DD ce qui m'a évité le Linux Live et l'installation Virtualbox.
 

J'ai pas tout compris à défaut de connaître Virtualbox (et vu l'heure ), mais j'ai déjà installé un Linux sur une clé USB en passant par KVM. On peut en effet y assigner un disque (au sens large) physique à la place d'un fichier comme DD virtuel, mais faut surtout pas se tromper (évidemment).

Edit: Simple pensée qui me passe par la tête, on ne peut pas rendre la clé de boot (méthode dd if of) bootable avec parted ou ce genre de truc? Bon après perso W10 j'y touche pas même avec des gants, donc osef...

Pour la clé rendue bootable par gparted, je ne sais pas. Officiellement, il faut passer par l'outil MS qui ressemble beaucoup à l'USB Creator qu'on trouve dans Ubuntu.

Mais bon, le Win10, c'est juste pour le volant à retour de force.
Tout le reste sous Linux (Steam / Proton / Heroic).

En gros Virtualbox sait booter l'ISO Microsoft et accrocher un disque physique dans son entier.
La contrainte est qu'un FS standard ne peut pas être monté par 2 OS simultanément sous peine de corruption. Du coup, comme j'avais posé KDE Neon et Win10 sur le même disque, j'ai dû passer par un OS qui n'utilisait pas le disque cible.

Suite des aventures :  
la corruption du Win10 était dûe à un début de fin de vie du SSD nvme.  
 
Bref, j'espère un alignement de planètes pour faire une sauvegarde ... et voir pour la garantie (on sait jamais, sur un malentendu).  
Mais du coup, je vais impérativement ne plus monter les dualboot sur le même disque : 1 disque, 1 OS max.
 
J'vous tiens au jus.

Bonjour,
C'est étonnant que le SSD soit en début de fin de vie alors qu'il est supposément presque neuf.
Par contre le Fastboot de Windows est réputé pour la corruption de données en dual boot linux et win, même sur des SSD séparés. Il faudrait simplement le désactiver.

Merci pour l'info.  
Dans mon cas, GRUB ne gère que Linux (UEFI inside sans OS Prober) ... du coup je passe par le boot menu pour lancer le Win10.  
 
A force de chercher, j'arrive à booter proprement (et j'ai fait une sauvegarde du coup) : je passe le chipset (x570) en PCI Gen3, redémarrage, puis PCI Gen4 et redémarrage + boot OS. Chaque changement de paramètre provoque un reset complet de la carte mère. C'est à ce prix que la machine fonctionne. Ça sent le condensateur foireux.  
 
De plus, je coupe l'alim après chaque arrêt histoire de mettre toute l'électronique de la carte mère au repos.

Nouveau symptôme : compilation du noyau en ramfs ... ça plante sans erreur de compilation.  
 
Les barrettes mémoire deviennent des suspects (avec le chandelier dans la cuisine) ... un tour de memtest s'impose.  
Si ça se vérifie, changer les barrettes mémoire est moins pénible que de changer la carte mère

Les symptômes se suivent mais ne se ressemblent pas.  
Après une période avec des démarrages plus ou moins laborieux, j'ai fini par choper les messages suivants dans kern.log :  

Lors de la lecture de la littérature à ce sujet, un gars explique qu'il avait ce genre de message en O/C et/ou undervolting ... et là, l'alim BeQuiet 850W 80gold+ redevient suspecte.  
 
Bref, je viens de remettre en place l'ancienne Enermax 750W 80gold+ ... et pas un seul problème avec 4 ou 5 allumages / arrêts consécutifs
Espérons que ça tienne ... et du coup, je vais aller me faire rembourser la BeQuiet (j'espère, elle a à peine 2 mois).

Nouvelle aventure

Hier, l'upgrade 2204 > 2404 sur le PC du taf m'a chié d'dans.
Donc, je sors le SSD du PC, je le mets dans un lecteur USB C pour faire les sauvegardes avant format/install via virtualbox.
Je récupère tout les répertoires dont j'ai besoin CàD home, etc, root, quelques branches usr pour GCC 14.2 et les points de montage nfs/dislocker... et pis vala.
Ensuite je pars dans une phase de nettoyage du répertoire etc. Bien évidemment avec un tar cf|tar xf sous compte root, les uid/gid/mode ont été conservés et il me faut donc aller nettoyer sous compte root ...

D'vinez quoi ! ... j'ai gourré de répertoire. J'ai commencé à purger par ordre alphabétique le répertoire /etc de la machine
je m'en suis aperçu autour de la lettre 'h' ... sueurs froides !

Bon, on réfléchit 2 secondes et j'ai fait la manip suivante :

• backup réseau via SSH du répertoire etc d'une de mes machines Intel migrées 2 jours auparavant
• backup local de ce qu'il restait dans /etc
• Restauration dans l'ordre : archive réseau puis archive locale

J'ai rebooté ... et me voila
(je n'exclue pas quelques effets d'bord alakon dans les jours qui viennent)

Hello ici,
Pour les problèmes de clefs usb non bootable, même avec dd if etc...
-> https://etcher.balena.io/  

je suis en sueur rien qu'à lire ça