Bon, finalement, j'ai reformaté la clef
Tu peux donc jeter tout ce sujet à la poubelle (tout ça pour ça) et en ouvrir un nouveau.
/dev/sdb1 10240 71679 61440 30M Amorçage BIOS
30 Mo pour une partition BIOS boot, ce n'est pas un peu exagéré ?
La précédente table de partition contenait une partition EFI, tu as décidé de changer de mode d'amorçage ?
Je voudrais que la partition /dev/sdb8 soit cachée pour tout ce qui est firefox, mails et autres contenus de logiciels déportés du home
Pas tout compris. Il suffit de ne pas la monter, non ? Ou la monter à un endroit inaccessible aux utilisateurs normaux.
Et d'autre part le résultat suivant est-il inquiétant ?
Non, c'est la commande qui est inquiétante sur ton niveau de compréhension, pas son résultat qui est parfaitement normal. Tu veux vraiment reproduire l'erreur qui a conduit à l'ouverture de ce sujet ?]]>
Tu peux recréer la partition Linux à l'emplacement exact (sans effacer son contenu) et essayer de la monter. Ou bien monter la clé en loop avec l'offset correspondant (start sector * 512).
Sinon, il reste l'analyse forensique avec photorec ou équivalent pour récupérer des contenus de fichiers sans noms ni chemins.]]>
[ 5026.382801] usb 2-4: USB disconnect, device number 2
[ 5026.382803] usb 2-4.1: USB disconnect, device number 8
[ 5026.382890] rndis_host 2-4.1:1.0 usb0: unregister 'rndis_host' usb-0000:00:14.0-4.1, RNDIS device
[ 5026.405735] usb 2-4.3: USB disconnect, device number 6
[ 5026.413622] scsi 7:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
[ 5026.413627] scsi 7:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 09 68 00 00 00 80 00
[ 5026.413629] blk_update_request: I/O error, dev sdb, sector 616448 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0
[ 5026.413675] Buffer I/O error on dev sdb, logical block 77056, async page read
(couic répétitions)
[ 5026.438934] usb 2-4.4: USB disconnect, device number 7
[ 5026.456293] sd 8:0:0:0: [sdc] Synchronizing SCSI cache
[ 5026.456318] sd 8:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 5026.752612] usb 2-4: new high-speed USB device number 9 using xhci_hcd
[ 5026.910893] usb 2-4: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice= 6.55
[ 5026.910897] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5026.910898] usb 2-4: Product: USB2.1 Hub
[ 5026.910900] usb 2-4: Manufacturer: GenesysLogic
[ 5026.911578] hub 2-4:1.0: USB hub found
[ 5026.911846] hub 2-4:1.0: 4 ports detected
D'après ces messages il semble qu'un hub USB "GenesysLogic" (interne ou externe ?) a été déconnecté, déconnectant avec lui trois périphériques USB, deux supports de stockage et un adaptateur réseau ou mobile Huawei. S'ensuivent une rafale d'erreurs d'accès à sdb qui n'est plus accessible, puis le hub et les trois périphériques sont immédiatement reconnectés.]]>
Mais si j'exécute la commande "dd if=/dev/zero of=/dev/sdb2 bs=1024 count=1" , ne vais-je pas effacer mes données ?
Non, cette commande n'efface que les premiers 1024 octets de la partition, qui ne sont pas utilisés par ext4 car réservés à un éventuel programme d'amorce, et contiennent la signature de la table de partition GPT.
D'autre part, j'ai aussi modifié /etc/fstab lors de mes recherches
(ce qui me permet de monter /dev/sdb2)
Donc la partition peut être montée malgré les messages d'e2fsck ? C'est un progrès.
Peut-être cela a-t-il eu une influence sur la modification du menu grub de démarrage ?
En principe non, sauf si le pilote ext2 de GRUB ne peut toujours pas monter la partition. Si la partition n'est pas déjà montée lors de l'exécution d'update-grub, elle est montée temporairement avec grub-mount en utilisant le pilote ext2 de GRUB via FUSE pour être examinée. Si elle est déjà montée par le noyau, alors c'est naturellement le pilote ext4 du noyau Linux qui est utilisé.
J'ai un doute sur l'état de santé de la clé USB. Il faudrait vérifier s'il y a des messages d'erreur relatifs à sdb dans les logs du noyau avec dmesg, et lancer badblocks sur /dev/sdb pour détecter d'éventels secteurs défectueux.]]>
# e2fsck -b 32768 /dev/sdb2
e2fsck 1.46.2 (28-Feb-2021)
/dev/sdb2: recovering journal
e2fsck: unable to set superblock flags on /dev/sdb2
Avec le bon offset e2fsck détecte le système de fichiers mais je ne comprends pas le dernier message.
Déjà tu peux effacer cette table de partition GPT qui n'a rien à faire là :
Qu'est-ce que ça donne ensuite si tu répètes la commande e2fsck ?
Je ne comprends pas pourquoi une partition GPT est incompatible avec un système de fichiers ext4 ?
Les deux ne peuvent pas coexister au même endroit. C'est comme si tu voulais mettre un système de fichiers ext4 et un swap dans la même partition. L'un va écraser l'autre.
En plus on ne met pas une table de partition dans une partition, sauf cas particulier de la partition étendue DOS (qui ne contient alors rien d'autre).]]>
458 mke2fs -n /dev/sdb2
459 e2fsck -p /dev/sdb2
460 e2fsck -b 8193 /dev/sdb2
461 e2fsck -b 32768 /dev/sdb2
Qu'ont donné ces commandes ?]]>