C’est le plus sage, car modifier le BIOS ou bootloader reste une opération à risque, même en utilisant des outils supposés miracles, sans comprendre ce qui est modifié et l’origine précise du problème.
La/les partitions de boot sdaX sont bien vues, Debian Bookworm bien idientifé, donc je ne vois pas ce que fdisk apporterait pour le moment.
S’il s’agit bien de remplacer un SSD par un autre SSD compatible qui boote bien sur un autre PC, je suggère un possible problème de SecureBoot, à confirmer.
Le SecureBoot protège le démarrage du PC contre des firmwares UEFI non signé, et bloque le démarrage sur des codes inconnus.
@loicmtp
Comme l’a fait remarquer Josephtux, la commande fdisk que tu proposes ne retournera rien du tout, pas plus qu’une autre commande sh*sum que tu proposais dans un autre sujet 2 jours plus tôt. Statistiquement, ça fait beaucoup.
Comme tu fais souvent référence à ‹ Arch ›, j’ai un gros doute sur l’origine des exécutables que tu utilises, puisque tous les dérivés de Debian/Ubuntu donneront les mêmes retours de commande système.
Pour clarifier et éviter de prochaines ambiguïtés, sans offenser ta suceptibilité, peux-tu montrer le retour de ces 2 commandes sur la machine que tu utilises.
sudo fdisk -l |grep -m1 ux
apt list -i coreutils fdisk
